[FFmpeg-devel] [PATCH] Frame rate emulation
Mon Jun 18 17:04:49 CEST 2007
Ramiro Ribeiro Polla wrote:
>>> Now I wonder... Why is waiting not a problem in v4l2.c? Around line
>>> 334, it whiles around if the error is EAGAIN. Isn't that also
>>> blocking FFmpeg?
>> if v4l2.c does that its broken too
> Luca, if you're reading this thread, can you take a look at this? It
> should be ok to make it return EAGAIN as soon this patch is reviewed
> into acceptance and applied.
Ok, I can try to fix it, but I doubt it is as simple as returning
EAGAIN... In my opinion, it will just change a sleeping wait into a
busywait, with the effect of having ffmpeg.c consuming a lot of CPU time
while waiting a video frame.
Or is the patch cited above going to change this? If yes, how can such
patch ensure that the v4l2_read_packet() function is called at the
correct time? We risk to call v4l2_read_packet() some times in a
non-blocking way before being able to read a video frame... Or to call
it alway "too late", increasing the latency when capturing video frames.
In my opinion, what we would really need is some kind support for a
"select() like" functionality between different AVFormats (something
like "block until there is some data available from one of the inputs -
listed in an array of AVFormats). But this is much more complex...
Again, if current v4l2 behaviour really is a bug, I am more than willing
to fix it (but I doubt that returning EAGAIN is the correct fix - at
least for the current ffmpeg.c).
More information about the ffmpeg-devel