Which Userland Interface for USB Video Class Driver?

Tom Evans tevans.uk at googlemail.com
Fri Sep 26 09:14:56 UTC 2008

On Thu, 2008-09-25 at 11:34 +0100, Dieter wrote:
> > <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.

Meh, my linux devices spits out PS, not TS. At least, that's what
mplayer tells me they are.

> 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?

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.
> 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.

Possibly worth taking a look at the freebsd saa driver, which works out
of the box with mplayer and other v4l API consumers.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-multimedia/attachments/20080926/4ca8b581/attachment.pgp

More information about the freebsd-multimedia mailing list