Ben Bridgwater wrote: > > Justin Schoeman wrote: > > > > VIDIOCSPICT and VIDIOCSWIN are only used for setting up an overlay > > > window, not for memory capture. For doing memory capture the size/format > > > are passed to each VIDIOMCAPTURE call. > > > > > > If anyone is wiling to host it, I have a thin C wrapper for V4L and some > > > simple examples showing how to to streaming mmap capture displayed in an > > > X window, that might be useful to people starting out. > > > > This is a point I am not sure of. The v4l API specification explicitly > > requires that GMBUF is isued AFTER setting the size and format, while > > MCAPTURE is only allowed after GMBUF and mmap. As you can see, this > > prevents using MCAPTURE to set the size/format, and the only other ioctl > > that sets size is SWIN, so this must be the one. Looking at the v4l2 > > emulation layer for v4l1 (which is a formal v4l implementation), you can > > see that it uses SWIN to set the capture format. I therefore assume this > > is the ioctl that the API spec is referring to. > > > > NB - just because bttv accepts GMBUF without a format, doesn't mean that > > all v4l drivers have to!!! > > The V4l API documentation for mmap capture has bever been correct! > > Quoting from the API doc: > > http://roadrunner.swansea.linux.org.uk/v4lapi.shtml > > Once the mmap has been made the VIDIOCMCAPTURE ioctl sets the image size you wish to use > (which should match or be below the initial query size). Having done so it will begin > capturing to the memory mapped buffer. Whenever a buffer is "used" by the program it > should called VIDIOCSYNC to free this frame up and continue. > > *** > > This is incorrect: VIDIOCSYNC isn't used to free a buffer after it has been used, but > rather to wait for it to be filled by the driver. Actually, the API document is correct, just a little vague! CSYNC does free the buffer (in that it removes it from internal capture queues. The API spec also fails to mention that if the buffer is in use CSYNC will block until it is free (which has the side-effect of waiting until the buffer is filled by the driver). > Also, the comment about setting image > size/depth before capture appears to apply to overlay, not mmap capture... certainly for > the bttv driver it's incorrect - if you look at the bttv source (or any working > application!) you'll see that SPICT/SWIN apply to overlay only and that what's used for > mmap capture are the MCAPTURE values. Just because it works does not meen it is right - this is bttv specific (and has been adopted by some other vide drivers), and is not guaranteed to work with all v4l drivers. I have just confirmed with Alan Cox that the v4l API REQUIRES the SWIN ioctl before the GMBUF ioctl - applications which don't do this may work, but they are not v4l compliant. -justin