On Friday 15 February 2002 05:26 pm, Dmitri wrote: > The API, as published, is clear: the frame state before MCAPTURE is > undefined; after MCAPTURE but before SYNC it is being used, and you shall > not read the memory because it is driver-dependent at this point. After > the SYNC returns, you have your frame, and it is yours until you issue > another MCAPTURE into this frame. I have to disagree, the API as published in not at all clear. Here is exactly what it says: "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. to add:VIDIOCSYNC takes the frame number you are freeing as its argument." If you search through it, that is the ONLY instance of VIDIOCMCAPTURE in the document. In fact one could argue that the state of the entire mmap allocation after VIDIOCMCAPTURE is undefined since it doesn't state whether it captures 1 frame or as many as it can. Is that clear about the state of the frame after VIDIOCSYNC? Using something you have freed is bad. After you free a malloc'd area of memory, I don't think of it as safe to be accessed again. I wouldn't think a buffer of picture data would be safe to access after I told the driver I'm freeing it. The API says "free this frame up". But it isn't being freed up for anything. It would be natural, from the language of the doc, to assume that "VIDIOCMCAPTURE" allocates and "VIDIOCSYNC" frees. And when an application allocates something, it does so from the system resources, and when it frees something it gives it back. But this is not what is happening. VIDIOCMCAPTURE is giving something to the driver (ownership of one of the mmap frame buffers), and VIDIOCSYNC is taking it back. In essence, VIDIOCSYNC is telling the driver to free its hold on the memory. The use of "begin capturing to the memory mapped buffer" is ambiguous because the document never tells you what the argument to that ioctl is. Is it capturing one frame specified, or is it going to start stream capture to each frame in the ring? The API continues to say: "When the buffer is unmapped or all the buffers are full capture ceases." Now it is using the plural of "buffer". If you weren't sure if VIDIOCMCAPTURE took in one or many frames and you saw this, it's pretty likely that you would assume that VIDIOCMCAPTURE starts streaming and filling all the frames it can, you wouldn't think you would have to request them each. I think the doc needs the "Reading Images" section re-written. I think the hesitation is that v4l2 is coming out and v4l will be deprecated. -Joe
