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> References: <200809251834.SAA00096@sopwith.solgatos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-PCbY5EEzc3OKKbIc7SfP
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
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 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1222420490.2443.56.camel>