> > If this happens it is a bug in the driver. It might happen that one frame > > from the video source is skipped if the second VIDIOCMCAPTURE is too late. > > But if VIDIOCMCAPTURE is called twice the driver must capture two frames. > > I don't think you understand. If first VIDIOCMCAPTURE blocks until the end of > the frame, then the second VIDIOCMCAPTURE will always* be too late and a frame > will be skipped. The driver may well capture two frames, but it will have > dropped one between the two it captured. Yes, this may happen. Note that I'm not talking about _blocking_ (i.e. sleeping while the hardware works on its own) in VIDIOCMCAPTURE, but about _capturing_ in VIDIOCMCAPTURE (i.e. CPU work). > This is because it you are limited > to queue depth of 1, which isn't enough. You NEED to at least double buffer > to capture every frame without depending on luck. But for dumb hardware where the CPU has to do all the work (i.e. capture can't be done asyncronly, driven by the IRQ handler) you can't double-buffer anyway ... > * for some hardware, it might not _always_ drop the next frame, if the > application is able to start capture during the VBI interval, AND > the hardware is able to start a capture during this time. You are thinking about TV cards and stuff. There is other capture hardware that that. Some (all?) usb/parport webcams don't have a idea of the current TV norm. Maybe they don't have some fixed frame rate too, don't know exactly. That would make whining about dropped frames pointless ... Gerd -- #define ENOCLUE 125 /* userland programmer induced race condition */
