On Fri, 15 Feb 2002, Rolf Siebrecht wrote: > 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. You don't need to do much beyond extend that loop in the obvious manner. It's true that you will only be processing one buffer at a time, but unless you have an SMP system, that's all you can work on. For a three buffer system, when the sync call on buffer 0 returns, you will still have both buffer 1 and buffer 2 queued to the driver. While you process buffer 0, the driver can capture into buffer 1, and then if that fills before you are done processing, it can go on to buffer 2. > > 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.) A driver that blocks on VIDIOCMCAPTURE and makes VIDIOCSYNC a noop is broken. It is impossible to have a queue depth greater than 1 (one) with such a driver! And of course without double buffering (queue depth 2), you will probably drop every other frame. As you said, only if the hardware has separate signals for end of last frame/beginning of next frame, can you hope to not drop frames. And even then you have an unnecessary race condition, since you need make the VIDIOCMCAPTURE in the short delay between frames. I think it shows that the API is poorly documented, when Gerd is trying to explain how it works, and gives an impossible example of how a driver could work.
