FreeBSD Multimedia API and Google SOC2006
danny at ricin.com
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 FreeBSD.org> wrote:
> > > I was wondering if someone could propose a
> > > project for a basic multimedia API for FreeBSD.
> > Video4bsd (V4B) perhaps?
> > Here is one candidate: http://people.freebsd.org/~jmg/videobsd.html
> Yeh, I think I'll mentor someone if someone is interested....
> > Also, the USB Video class (example at http://linux-uvc.berlios.de/)
> > 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 purpe.com (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
> 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