On Mon, Jul 31, 2000 at 06:01:24PM +0200, Justin Schoeman wrote:
> Hi everybody,
>
> 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.
> ...
> bttv-v4l2 broke this spec in that successive calls to read() returned
> successive chunks of data from the same frame
> ...
> Which method should I implement in bttv2? Stick with the standard, or
> use the more convenient method?
There's really two separate issues here:
1. what should the behaviour of bttv2 be?
*please* stick to the spec. One of the best things about v4l2 is
that the behaviour is fairly consistent across drivers. If this
changes, we'll end up with ugly application code that tries/needs
to accomodate different devices, and users complaining that their
scripts break when changing capture cards.
2. what would the behaviour of read() be in a perfect API? ;)
[disclaimer: I'm an app writer, not a driver writer]
I'd also like to be able to read() less than a frame at a time. It
seems that the v4l2 spec is attempting to enforce record-at-a-time
read semantics, which feels kind of contrary to normal unix behaviour.
v4l2 already provides frame-at-a-time capture through the VIDIOC_QBUF/
VIDIOC_DQBUF ioctls. Crippling read() to also only provide these
semantics means that it is impossible to write intermediate filters and
data dumpers etc. that don't necessarily know about capture sizes.
You've mentioned the cat/vcat thing, in which a separate program had
to be written just to stream to stdout. That v4l2 provides vcat solves
the immediate problem (of wanting to cat from the video device) but
the problem is more general.
For example for sane-v4l2 I had to provide an arbitrary length read
function to SANE. Because you can only read a frame at a time from v4l2
this required maintaining an internal buffer and then passing data out
of it piece by piece, even when the capture and scan formats are
identical and just wrapping a read would have worked. The result is
simply more frame-sized buffers lying around in userspace than are
necessary.
If an application writer really wants to only know about a frame at
a time, what's wrong with using fread()? surely that's exactly the
kind of thing it's designed for (and if the speed penalty is an
issue you should probably be doing a streaming capture anyway).
(In fact, because the read() semantics are wierd and because mmaping
feels cleaner, I tend to use QBUF/DQBUF where possible even to only
capture occasional frames ...)
Anyway, all in all I still think it's important for drivers to stick
to the spec. If everyone thinks reads of less than one frame are a
good thing, it should be accomodated there rather than implemented
randomly in each driver.
Conrad.
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
