FreeBSD Multimedia API and Google SOC2006

[John-Mark Gurney]

Danny Pansters wrote this message on Fri, Apr 28, 2006 at 01:56 +0200:
> On Thursday 27 April 2006 22:13, John-Mark Gurney wrote:
> > Personally the V4Lx API's are at the wrong level for how far computers
> > have advanaced...  Any video api should be a userland library, that
> > provides access to it...  and not a kernel interface that is of
> > limited use...  This has the advantage that updates for new tuners and
> > other stuff can happen easier and quicker... and more people are willing
> > to touch the code...
> 
> Yes. See also the saa code at purpe.com (for Philips SAA based TV boards)

Yeh, I haven't looked at the code yet...

> > My bktrau driver for the DViCO FusionHDTV5 Lite has a minimal kernel
> > presence... the userland capture program uses the GPIO defines in bktr,
> > the iic device driver for controlling the tuner and demodulator to
> > control the capture..  This means my driver is under 1k lines of code..
> 
> iic is good. But still, considering the bktr legacy, it would still require 

The bktr legacy should be shot..  it's a terible interface, it isn't
cross platform compatible, and should never EVER be used again...  The
specific interface that I'm talking about is that userland provides a
physical address for video overlay...  The userland should NEVER have
to deal with physical bus addresses, and it ensure that it will never
work on other arches like sparc64 where getting a physical address is
a little more difficult...

> something like v4l to tie together common functionality that's implemented 
> per-driver. Still, common iic routines that are wrapped into such a V4B 
> interface could benifit both the v4b umbrella driver as well as ease a driver 
> developer's job as well as ease an end user programmer's job (they may all be 
> the same person of course).

nah, v4l (an ioctl interface) is too low level...

> > > If there is need for a mechanism (sp?) to distinguish which API a
> > > certain device can be operated with, an easy way would be to use a
> > > naming convention. Example: /dev/video0 - use the V4L
> > > API, /dev/bsdvideo0 - use the V4B API. Most likely, somebody else has a
> > > better suggestion.
> 
> There's probably going to be things that go in between of whatever you think 
> up anyway (if any appear at all. It's good to see drivers and multimedia 
> initiatives popping up lately, it's been silent too long). 

Yeh, though vendor support is still week... DViCO keeps saying they'll
get me some more docs on the demodulator, but still hasn't gotten anything
to me...

> The bsdpwc (Phillips and logitec USB webcam) driver is based on the linux one 
> (it has a simple read() interface on the video0 device, which is implemented 
> as a V4L device but it has extra functions added (for example to pan and tilt 
> the camera).
> 
> > I'd suggest NOT to use a kernel interface.. they are expensive to
> > maintain, and harder to shoehorn things like USB web cams into...
> 
> The more user space the better. And the more simple read() can be used the 
> better as well (it's 2006 not 1996). It just makes it much easier to grab and 

read() is a complicated interface to handle unless the card has an on
board memory buffer...  the bt848 and bt878 cards cannot easily handle
a read interface w/o requiring large amounts of staticly allocated memory
and an extra copy...

read()'s biggest problem is the lack of multiple buffers...  It'd be
interesting to use writev to preload the next buffer, but of course,
many programs you'd normally want to use (cat and dd) would need to
be modified, which ruins the point of the read() interface...

> work with the data and use individual frames. But a common interface will 
> have to take the form of a bunch of ioctls or be in a completely higher level 
> API altogether maybe, and then I'm thinking python or ruby for which common 
> functions can be easily put into different GUIs. Multimedia apps should be 
> expected to end up in a GUI in most cases and a common API should be made 
> with that in mind as well.

This is what stalled my VideoBSD api work...  writing all the necessary
glue in C really sucks, and doing ioctl frameworks is complicated and
a good way to have buggy code and kernel crashes...  If I could write it
in Python (and know that everyone would use it), I'd of completed the
work..

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."