Hi!
On Fri, 15 Feb 2002, Joe Burks wrote:
> Hmmm... The API says:
>
> "Whenever a buffer is "used" by the program it should called VIDIOCSYNC to
> free this frame up and continue. to add:VIDIOCSYNC takes the frame number you
> are freeing as its argument."
>
> According to that, if you call VIDIOCSYNC on a frame, you are saying to the
> driver "I'm done with this frame".
You can't write a working driver based only on the material of "API.html".
(What shall we think about coding instructions that contain a "to add:"
remark _for years_?) You have to consider existing drivers that have
proved to work well. IMHO "bttv" is one of those.
> I'd also be a little more confused because of the couple drivers I've looked
> at, VIDIOCMCAPTURE doesn't return until they've pulled in and decoded a
> frame. Also the source code to the zapping program puts the call to
> VIDIOCSYNC in a function called tveng_dequeue which isn't called until it is
> done with the buffer.
Maybe it's a consequence of the unprecise API. In bttv, VIDIOCMCAPTURE
returns immediately after executing some elementary steps. VIDIOCSYNC
calls interruptible_sleep_on() resp. schedule(), i.e. it blocks. The
waiting loop is aborted by an interrupt that for its part is triggered by
a sync signal of the Bt8x8 hardware. Only after that, the application can
be sure that the buffer is filled.
An explicit freeing step is not needed; the program must only take care
that the content of a filled buffer is completely processed before the
next VIDIOCMCAPTURE on this buffer is called.
A queueing of VIDIOCMCAPTURE calls would be impossible if they don't
return before the corresponding frames are finished.
If we would support that point of view of the sources you mentioned, i.e.
- VIDIOCMCAPTURE waits for capture completion,
- VIDIOCSYNC frees something up,
we would need a third VIDIOCxyz that requests frames and is queueable.
Bye,
Rolf
