FreeBSD Multimedia API and Google SOC2006

Danny Pansters danny at
Thu Apr 27 23:56:44 UTC 2006

On Thursday 27 April 2006 22:13, John-Mark Gurney wrote:
> Torfinn Ingolfsen wrote this message on Thu, Apr 27, 2006 at 20:59 +0200:
> > On Thu, 27 Apr 2006 15:25:05 -0300
> >
> > Mario Sergio Fujikawa Ferreira <lioux at> wrote:
> > > 	I was wondering if someone could propose a
> > > project for a basic multimedia API for FreeBSD.
> >
> > Video4bsd (V4B) perhaps?
> > Here is one candidate:
> Yeh, I think I'll mentor someone if someone is interested....
> > Also, the USB Video class (example at
> > looks interesting, I think it should be included in a multimedia API
> > for BSD.

I think it would be wise to separate cameras and TV/grabber/decoder boards 
because their APIs tend to be different enough to make (IMHO) v4l perform 
worse than could be.  

> > > 	I am not proposing V4Linux but some sort of common
> > > API abstraction.
> >
> > IMHO, if we create our own multimedia API, it should have V4L2
> > and V4L1 "faces" or "shims" that allows devices to be operated through
> > these APIs. At least V4L2, only V4L1 if it is really needed.
> > The reason for this is that it will ease porting of programs that uses
> > the V4L API's. And there are a lot of those.
> > Note: I am very much out of my waters here, I can't really tell if this
> > is feasible / practical at all.

IMHO it should tie up lower level stuff (both kernel, and hopefully mostly 
userlevel) and present it in an SDL-friendly or outright pluggable way.

> 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 (for Philips SAA based TV boards)

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

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

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

[FYI, the current version of kbtv supports both bktr and saa, and the one I'm 
working on/using now -- should become 1.0.1 -- will have pwc support with 
panning etc instead of channel switching. After a redesign around Christmas, 
I think pretty soon now I'm going to have to redesign again, so that new 
hardware/drivers are easier brought in. That will have to include doing my 
own rendering in one common viewer for all hardware, and I think the one 
thing to use is SDL, either from C, or from Python (pygame, this has less low 
level functionality than straight SDL with C has)]

Just my thoughts,


More information about the freebsd-multimedia mailing list