Hi!
On 15 Feb 2002, Gerd Knorr wrote:
> > 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 API is very clear and what the driver does internally doesn't
> matter.
Nonsense. The description of VIDIOCMCAPTURE and VIDIOCSYNC in API.html is
unclear, unexact, doubtful. It leaves much more questions than answers.
Why were there so many discussions about this very issue within the
v4l-list? Again, you can't realize a working driver (and application) if
you take only the wording of API.html into consideration.
> VIDIOCMCAPTURE
> asks the driver to capture a frame to a specific buffer.
>
> VIDIOCSYNC
> waits until the data for a specific frame is available.
That's very true. But these are not statements of API.html, especially
VIDIOCSYNC.
If you have an imagination of the whole API in your mind it's fine for
you. It doesn't help authors that are dependent on accessible written
documents.
> To capture a single frame a application must call both VIDIOCMCAPTURE
> and VIDIOCSYNC.
>
>
> The point of splitting up this into two ioctls is to allow queuing
> capture requests and do double-buffering, i.e. stuff like this:
As I said.
> VIDIOCMCAPTURE(0)
> for (;;) {
> VIDIOCMCAPTURE(1)
> VIDIOCSYNC(0)
> /* process frame 0 data while DMA xfer to frame 1 is in flight */
> VIDIOCMCAPTURE(0)
> VIDIOCSYNC(1)
> /* process frame 1 data while DMA xfer to frame 0 is in flight */
> }
>
> You can do that with more that two buffers too, but in case you are
> using bttv you have to tweak the driver (gbuffers insmod option)
> because bttv (0.7.x versions) gives you only two buffers by default.
And the code of the loop will have to get much smarter if more than two
buffers shall really be utilized. To shift a 2-buffer window (one
capturing, one processing) along an n-buffer ring doesn't yield any
profits.
> With devices which don't do DMA and expect the CPU doing all the work it
> might be that VIDIOCMCAPTURE handles everything and VIDIOCSYNC is
> effectively a NOP. But for the application these driver internals don't
The application resp. its author *must* know at what moment VIDIOCMCAPTURE
returns. With a
VIDIOCMCAPTURE(0)
VIDIOCMCAPTURE(1)
sequence the second request is generally lost if it doesn't return before
the first frame has finished. Resp. only the next but one frame is
captured.
(Well, it depends on the hardware if there is only one sync signal that
has the meaning of end-of-last-frame/field *and* beginning-of-next-frame/
field. Or a separated end-of-last-frame signal that appears significantly
*before* beginning-of-next-frame.)
> matter. You simply call both ioctls and it will work. That is the
> point of the v4l API: You don't write applications for bttv. You write
> a application for the v4l API, and it should work with all v4l drivers.
...and you'll get lots of disappointment, annoyance and frustration.
Bye,
Rolf
