[FFmpeg-devel] [PATCH] Frame rate emulation

[Luca Abeni]

Hi,

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).


			Thanks,
				Luca