Hi Kamil, Roy, When implementing eos support in v4l2-ctl I started wondering about the exact timings of that. There are two cases, polling and non-polling, and I'll explain how I do it now in v4l2-ctl. Polling case: I select for both read and exceptions. When the select returns I check for exceptions and call DQEVENT, which may return EOS. If there is something to read then I call DQBUF to get the frame, process it and afterwards exit the capture loop if the EOS event was seen. This procedure assumes that setting the event and making the last frame available to userspace happen atomically, otherwise you can get a race condition. Non-polling case: I select for an exception with a timeout of 0 (i.e. returns immediately), then I call DQBUF (which may block), process the frame and exit if EOS was seen. I suspect this is wrong, since when I call select the EOS may not be set yet, but it is after the DQBUF. So in the next run through the capture loop I capture one frame too many. What I think is the correct sequence is to first select for a read(), but not exceptions, then do the DQBUF, and finally do a select for exceptions with a timeout of 0. If EOS was seen, then that was the last frame. A potential problem with that might be when you want to select on other events as well. Then you would select on both read and exceptions, and we end up with a potential race condition again. The only solution I see is to open a second filehandle to the video node and subscribe to the EOS event only for that filehandle and use that to do the EOS polling. It all feels rather awkward. Kamil, Roy, any ideas/suggestions to improve this? Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
