Date: Fri, 28 Apr 2006 01:56:07 +0200 From: Danny Pansters <danny@ricin.com> To: Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no>, freebsd-multimedia@freebsd.org Subject: Re: FreeBSD Multimedia API and Google SOC2006 Message-ID: <200604280156.07996.danny@ricin.com> In-Reply-To: <20060427201316.GJ728@funkthat.com> References: <20060427182528.35070.qmail@exxodus.fedaykin.here> <20060427205905.9ab1500f.torfinn.ingolfsen@broadpark.no> <20060427201316.GJ728@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 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, Dan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604280156.07996.danny>