BSD video capture emulation question

[Alexander Leidinger]

On Fri, 11 Jul 2003 10:28:28 -0700
John-Mark Gurney <gurney_j at efn.org> wrote:

> For the most part, the kernel would just export many different device
> nodes, one for each part of the card.  I've started work on a design
> document.  It is VERY rough and incomplete, but I'll put it up.
> 
> http://people.FreeBSD.org/~jmg/videobsd.html

Did you looked at v4l and v4l2 (I haven't)? And at gstreamer and NMM
(http://www.networkmultimedia.org/)? I listed the former ones to decide
what they did wrong, so "our" API doesn't make the same mistakes, and
the later ones to see what's needed at the application level (what kind
of actions the API should allow). Maybe talking with some of the
developers of those userland programs/libs will help, if it is of help:
I can get in contact with the NMM people personally.

> I'm still debating on how much smarts should be put into the kernel.
> Part of me wants to do a good portion of it to prevent the user from
> doing something stupid and damaging hardware (like setting two sources
> to drive the clocks of the video bus at the same time).  But the more
> I'm thinking about it, I want to do most if not all in userland.  This
> would make it easier to support usb webcams and firewire devices easier
> w/o the user of the library even knowing there was a difference.

We don't want a malicious program to destroy the hardware, do we?

> I'm not sure if I'll go so far as Windows has with being able to stick
> n filters between the device and your output.  Adding this support
> shouldn't be hard since it's a library and we can at a later date add
> additional functions.

Think about those cards where you can put a video stream in and get a
transformed video stream out (MPEG encoder). One end can be represented
as a video sink and the other one as a video source (so you don't need a
"filter", just connect sources with sinks).

Ideally you want to e.g. connect one video source (e.g. DV format from a
via firewire connected cam) to the video sink of a MPEG encoder and the
video source of the MPEG encoder should get written to disk and at the
same time to the video sink of the TV-Out of the DVB-S card (MPEG
decoder).

The API should be able to do as much of this in the kernel as possible,
e.g. if I connect the DV video source to the MPEG video sink and I don't
have some kind of "tee" in between, then the data shouldn't leave the
kernel. And if I have a "tee" in between (as in the above example:
writting to disk an to the DVD-S card) the data transfer between in
kernel manageable entities should happen in the kernel.

Bye,
Alexander.

-- 
            Give a man a fish and you feed him for a day;
     teach him to use the Net and he won't bother you for weeks.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7