Date: Fri, 26 Sep 2008 10:14:50 +0100 From: Tom Evans <tevans.uk@googlemail.com> To: Dieter <freebsd@sopwith.solgatos.com> Cc: freebsd-multimedia@freebsd.org Subject: Re: Which Userland Interface for USB Video Class Driver? Message-ID: <1222420490.2443.56.camel@localhost> In-Reply-To: <200809251834.SAA00096@sopwith.solgatos.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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.
Cheers
Tom
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEABECAAYFAkjcqAcACgkQlcRvFfyds/cg9QCeKhXKExOlksYhcD4V5zJRmv98
ZN8An2YhmcAx2zH0gfwXaeNbhBf4n/n7
=TG74
-----END PGP SIGNATURE-----
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1222420490.2443.56.camel>