On Fri, 15 Feb 2002, Joe Burks wrote: > The way I read it, the application does not queue up frames to be captured. > It just reads that frame out of the mmap ring buffer. If that frame isn't > available (it has a capture pending), it blocks until it is. If you have an > mmap buffer of 4 frames (the driver determines how many mmap buffers you > have), the driver will capture at most 3 frames ahead of the currently > processed frame before stopping. As long as your application can keep up > with that no lost frames. The application needs to queue up frames to be captured, since otherwise how would the driver know that the application is done with the buffer? > That may be true. But if that is true API.html is explicitly wrong: > > Whenever a buffer is "used" by the program it should called VIDIOCSYNC to > free this frame up and continue. Wouldn't be the first time it was wrong. > MCAPTURE is called. The semantic of SYNC would seem to be "block until > you're done with this frame", but it only works once. Even though it is > still done with the frame the second time, it returns -EINVAL. But why would you want to sync on the same frame twice? The of the flag as meaning, "buffer full, owned by driver" (not yet synced) vs "buffer full, owned by application" (synced) Now, I suppose that for most drivers there really isn't a difference between these two states, and the only purpose of the flag is cause an error if the application tries to sync a buffer that is already synced. But there is a conceptual difference between these states, and I could imagine a driver that cares. For instance the "owned by driver" state could have the memory readable by the kernel, but not by userspace. The "owned by application" state would change the ownership (segment, etc.) of the memory.
