From owner-freebsd-multimedia@FreeBSD.ORG Thu Sep 25 18:35:42 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 7FE031065677 for ; Thu, 25 Sep 2008 18:35:42 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from parsely.rain.com (parsely.rain.com [199.26.172.196]) by mx1.freebsd.org (Postfix) with ESMTP id C48838FC1F for ; Thu, 25 Sep 2008 18:35:37 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (uucp@localhost) by parsely.rain.com (8.11.4/8.11.4) with UUCP id m8PIZX262603 for freebsd-multimedia@freebsd.org; Thu, 25 Sep 2008 11:35:33 -0700 (PDT) (envelope-from freebsd@sopwith.solgatos.com) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id SAA00096; Thu, 25 Sep 2008 18:34:25 GMT Message-Id: <200809251834.SAA00096@sopwith.solgatos.com> To: freebsd-multimedia@freebsd.org In-reply-to: Your message of "Thu, 25 Sep 2008 09:58:25 BST." <1222333105.2443.25.camel@localhost> Date: Thu, 25 Sep 2008 11:34:25 +0100 From: Dieter 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: Thu, 25 Sep 2008 18:35:42 -0000 > > > 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 integrate > > decoder into chips, I believe. > >=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. > > 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. > > As far as I can tell, ATSC tuners do precisely the same thing. I suspect you mean MPEG-2 TS (transport stream), not MPEG-2 PS (program stream)? 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. 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 decoding, 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 VIA Chrome GPUs have open source Xv and XvMC support, does this work on *BSD? 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. Some analog tuners include hardware compression (and perhaps decompression), 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 that 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. 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 userland library as needed. This would require editing the apps, but it would be a simple edit.