From owner-freebsd-multimedia@FreeBSD.ORG Fri Sep 26 09:14:56 2008 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EDA6106568F for ; Fri, 26 Sep 2008 09:14:56 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.237]) by mx1.freebsd.org (Postfix) with ESMTP id 3DCA98FC14 for ; Fri, 26 Sep 2008 09:14:56 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by qb-out-0506.google.com with SMTP id f30so589586qba.35 for ; Fri, 26 Sep 2008 02:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer; bh=LN3gMqDfvLuGCdFzgJa+thboZH98mn5cX57k4jqmkrE=; b=koqJCRtvoEDhWAz2lJlVry510ozGvq1QD2B5L1T7YU3vGuXlx2LV736ekXaSw8d9Jh +8v5onyj7WuGtkG9G4IvJTcSgHfL25znRz7qp/fCnFDIy3ulM7aw+vKLyWaDu/+XpBKp nYJ1rSbJEr4nyvji3oX/0rGddXH8+07lBir/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; b=hGGGmfGAHLMV9PUULw3iiKBdKjdPQvJ3kL5XZg+PM4iSnVcCWDjLct8yMy0yBk9QGA t9q/yoRUHoxaX5/8XcmEMY9fUN/PU5cUzx2uTSUgND6YYOex71dDpYl+nwaxf7XyP8Ge O+np7XyTKbsKJRPw1L6LijjzLkb0I99C05UvQ= Received: by 10.210.49.7 with SMTP id w7mr1148793ebw.109.1222420494712; Fri, 26 Sep 2008 02:14:54 -0700 (PDT) Received: from ?127.0.0.1? ( [217.206.187.80]) by mx.google.com with ESMTPS id p10sm3119613gvf.7.2008.09.26.02.14.52 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Sep 2008 02:14:53 -0700 (PDT) From: Tom Evans To: Dieter In-Reply-To: <200809251834.SAA00096@sopwith.solgatos.com> References: <200809251834.SAA00096@sopwith.solgatos.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PCbY5EEzc3OKKbIc7SfP" Date: Fri, 26 Sep 2008 10:14:50 +0100 Message-Id: <1222420490.2443.56.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Cc: freebsd-multimedia@freebsd.org Subject: Re: Which Userland Interface for USB Video Class Driver? X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2008 09:14:56 -0000 --=-PCbY5EEzc3OKKbIc7SfP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-09-25 at 11:34 +0100, Dieter wrote: > > > > > As a driver writer, the AV encoding standard concerns me. For, > > > the driver must be able to decode compressed frame into plain bitmap > > > if the chip cannot decode frame on its own. Of course, the Chinese > > > standard is so cheap that many hardware vendors are willing to integr= ate > > > decoder into chips, I believe. > > >=3D20 > >=20 > > I'm not sure this is necessarily true anymore. From a European view > > point, the vast majority of DVB-{S,T,C} cards on the market are 'budget= ' > > cards; they simply demodulate an MPEG-2 Program Stream from the signal. > > Certainly, under linux, neither of my DVB-T tuners (pci saa based, usb > > dibcom), nor my DVB-S card (also pci saa based) can decode a single > > frame of actual video data. > >=20 > > Even when the actual video is not MPEG-2, like HD streams encoded in > > MPEG-4 AVC, it is contained in an MPEG-2 PS. All the drivers do is to > > setup and tune the device to the appropriate channel, and provide a > > device to read the PS from. It is up to whatever userland program which > > is using the device to decode the data, if that is even required. I > > certainly wouldn't like a driver to decode high bitrate MPEG-4 AVC if > > all I am trying to do is record a show to disk. > >=20 > > As far as I can tell, ATSC tuners do precisely the same thing. >=20 > I suspect you mean MPEG-2 TS (transport stream), not MPEG-2 PS > (program stream)? >=20 > Yes, ATSC is the same way, at least in the US. The "tuner" provides > a mpeg2 ts. You can write this to disk and/or decode it and view it. > You don't *want* the tuner to decode it, because the decoded video > is gigantic and would quickly fill your disks. And a PCI bus isn't > fast enough for a single stream of uncompressed HD video. The > compressed version eats enough disk space as it is. Meh, my linux devices spits out PS, not TS. At least, that's what mplayer tells me they are. >=20 > Decoding is a bit of a problem. To decode HD in real time, you need a > recent fast CPU (and PCIe), or a GPU that supports Xv and XvMC, or some > hardware decoder. As far as I know, *BSD has no support for hardware > decoders. There are Ethernet to TV bridges, but they seem to all have > significant limitations (counterexamples welcome). ATI may have released > enough documentation to allow using some models of their GPUs for decodin= g, > but no one has written the code yet. They have not released docs for the > UVD/UVD2 on the R600/R700 yet, and might never release it. Supposedly VI= A > Chrome GPUs have open source Xv and XvMC support, does this work on *BSD? >=20 In the UK, HDTV is MPEG-4 AVC, so XvMC helps not a jot. With just Xv, and a 2.4 GHz Core 2 Duo, this can be decoded in real time fairly simply. ATSC HD is MPEG-2, or so I hear, so with XvMC you can run on fairly mediocre hardware. > The bktr/v4l2/whatever interface is needed for digitized analog video > (NTSC/PAL/SECAM). The US OTA analog-to-digital transition in 2009-02-17 > isn't as complete as some people think. Many stations will not be > converting then, and are not even scheduled to convert. In addition, > many people with cable or satellite will still have analog. There are > videotapes and other media that people will want to digitize. And > other countries are not tied to the US transition. So *BSD will > need support for analog video for many years. >=20 > Some analog tuners include hardware compression (and perhaps decompressio= n), > other don't. For the ones that don't, we need an interface for apps > like mencoder, ffmpeg, xine, etc. so they can compress the video before > writing it to disk. Many of these apps already support bktr and/or > v4l2. So if device drivers support one of these, we get app support > without additional work. But some developers object to these interfaces > because they'd prefer to keep as much of the code in userland as possible= , > and bktr and v4l2 require too much code in the kernel. Jason reports tha= t > NetBSD has a "generic API", and then some sort of compatiblility layer > that looks like v4l2. I need to learn more about this, as it isn't > obvious to me how this keeps code out of the kernel. >=20 > One idea I had was to use the bktr interface, but change the system calls > to library calls, e.g. ioctl becomes uioctl. The developer writing a > device driver can then divide the code between the kernel and the userlan= d > library as needed. This would require editing the apps, but it would be = a > simple edit. Possibly worth taking a look at the freebsd saa driver, which works out of the box with mplayer and other v4l API consumers. Cheers Tom --=-PCbY5EEzc3OKKbIc7SfP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkjcqAcACgkQlcRvFfyds/cg9QCeKhXKExOlksYhcD4V5zJRmv98 ZN8An2YhmcAx2zH0gfwXaeNbhBf4n/n7 =TG74 -----END PGP SIGNATURE----- --=-PCbY5EEzc3OKKbIc7SfP--