Rolf Siebrecht wrote: > Hi! > > On 15 Feb 2002, Gerd Knorr wrote: > > 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. I'm talking about the API itself, not the text on the API.html page. Maybe I should update my Programming-FAQ (in the xawtv tarball), put it into API.html and mail Alan a diff ... > > 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. ... which is one of the reasons why the xawtv code doesn't work very well as sample code. It *is* very complex as tries to keep the buffer queue as full as possible, passes reference-counted pointers to the buffers around to avoid copying data, and buffers might get released asyncronly from other threads. Thus it isn't obvious just from reading the code what exactly is going on there ... > To shift a 2-buffer window (one > capturing, one processing) along an n-buffer ring doesn't yield any > profits. Of course it doesn'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. 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. Gerd -- #define ENOCLUE 125 /* userland programmer induced race condition */
