On Friday 15 February 2002 01:46 pm, Trent Piepho wrote: > 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! According to what I think Alan was saying and the API said, VIDIOCMCAPTURE does two things: 1) Returns when a grabbed frame is available. 2) Starts the driver capturing to the mmap buffer ring if it is not already doing so. (the ring could have a size of 1, in which case frames are captured on each call to VIDIOCMCAPTURE) At this point you start chasing the captured frames in a ring. The calls are not queued up by the application. Once a call to VIDIOCMCAPTURE is made the first time, the mmapped frame buffer queue starts filling. As you finish with the frames you call VIDIOCSYNC to let the driver know it can write to that frame again. If the driver ever gets so far ahead of you that none of its mmap buffers are free, it stops capturing. According to the API, it is not up to the application to double buffer. The driver will double, triple or n- buffer itself (bttv has 4 buffers). I'm a bit worried about the state of confusion over this matter. Between the API, Alan's clarification, the zapping mp1e application and the bttv driver, the answer is _NOT_ that VIDIOCMCAPTURE queues a frame to be read and VIDIOCSYNC blocks until it is available (although based on the names of the ioctl's that seems like what they would do). -Joe
