> I would like to find the general opinion on read() support in v4l2
> drivers. The v4l2 spec requires each read() to return data from a
> different frame. If the buffer is too small, either return -EINVAL, or
> only the data that can fit into the buffer, then discard the rest of the
> frame. This means that simple stuff like cat fail, because of the
> constant 4k buffer size (there is a vcat program for v4l2 that can
> understand this though).
>
> bttv-v4l2 broke this spec in that successive calls to read() returned
> successive chunks of data from the same frame, so you could simply cat
> /dev/video > whatever . This is very convenient, but breaks the spec.
> It also makes it very easy to get out of sync with the data, so you no
> longer know where the frame starts (only within one open - future opens
> start at the beginning of a frame again).
I favor the api spec - not that I'm stuck on v4l2 specifically,
(although I like it a lot) but pretty much everything I do is dependent
on the frame analysis. Without clear boundaries of each frame, it
falls apart. I suppose that knowing the amount of data needed could
just force me to loop until I've recieved the right byte count, but I
prefer to just ask for a frame.
That said, I see where a 'cat /dev/video' is handy for some situations.
Would it be possible for there to be a small program to ship with the
bttv-v4l2 that would emulate this behaviour through a second pipe or
something? That way it would still work with the spec, but people looking
to use the driver directly through cat could use that interface?
(I'm still relatively new to this stuff, but I would think that it would
cause less confusion for app writers like myself.)
--Matt Sherer
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
