Date: Thu, 25 Sep 2008 11:34:25 +0100 From: Dieter <freebsd@sopwith.solgatos.com> To: freebsd-multimedia@freebsd.org Subject: Re: Which Userland Interface for USB Video Class Driver? Message-ID: <200809251834.SAA00096@sopwith.solgatos.com> In-Reply-To: Your message of "Thu, 25 Sep 2008 09:58:25 BST." <1222333105.2443.25.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
> <snip>
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809251834.SAA00096>