Survey on Video Capture API: BSD meteor(4) vs. Video for Linux 1/2

[John-Mark Gurney]

Intron is my alias on the Internet wrote this message on Thu, Oct 05, 2006 at 00:32 +0800:
> If I would code to enhance video capture support for FreeBSD, what video
> capture API do you prefer? Your choices:
> 
> 1. BSD Brooktree 848 (See bktr(4) and meteor(4))
> 
> This is *BSD-specific video capture API. So far only Brooktree
> (Conexant) 848/878 chip is supported by *BSD. Thus, actually this API
> is BT848/878-specific.

Do not use this API..  This API is not friendly for cross platform..
The meteor(4) API will not work as designed on arches like sparc64...
The problem is that the meteor API (for video overlay) requires you to
pass a physical address to the hardware..  If the user app messes up
this address it can stomp on all of memory...  Or in the case of sparc64,
getting the necessary physical address and having the iommu programmed
properly is only available if the bus_dma api is used...

For a correct way to do this, you can look at how I basicly modified
the meteor api for my zoran capture driver..  Instead of passing a
physical address, you pass a userland address of an mmap'd buffer...
This buffer can be verified to be congtiguous, and helps ensure proper
programming of the DMA engine..

> 2. Video for Linux 1/2 (See http://v4l2spec.bytesex.org/)
>     These are the video capture APIs for Linux. There are two versions:
> V4L and V4L2. Supported hardware list:
>    http://linux.bytesex.org/v4l2/drivers.html    (V4L2 mainly)
>    http://mxhaard.free.fr/spca5xx.html           (V4L)

Last I looked at the V4L family of api's, they weren't very extensible,
and only supported basic capture, and none of the more advance features
that soem capture/render cards have, such as PIP...

> MPlayer supports both kinds of API's. But to gain Linux binary
> compatibility for FreeBSD, V4L/V4L2 must be introduced to FreeBSD.

I would prefer a userland API and then have small modules that plug
into this API to do most of the work...

The code necessary to fully implement a basic API in the kernel would
be quite large and the kernel is not the best place for all the necessary
support framework for this...

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

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