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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
