[FFmpeg-devel] [PATCH] Frame rate emulation

[Luca Abeni]

Hi Michael,

Michael Niedermayer wrote:
[...]
>> (and I think v4l2 is not doing "frame rate emulation", it is just 
>> synchronizing with the real rate of the input...)
> 
> yes but IMHO no demuxer or protocol should be blocking like they do
Ok. After reading your email, I agree with you.

But I think this would be a big change in the current behaviour, and we 
need to be careful about it. For example, most of the code using 
libavformat will have to be changed (if I understand ffmpeg.c correctly, 
just returning EAGAIN if a frame is not available would not change 
anything in the current behaviour, but will cause a 100% CPU load).


>> But if I am wrong, let me know how v4l2.c should behave, and I'll try to 
>> fix it.
> 
> there should be a way to prevent demuxers & protocols from blocking if
> no data is aviailable ...
I agree. As I wrote in a previous email, I think the "really correct" 
solution from a conceptual point of view would be to provide some kind 
of "select like functionality". So, ffmpeg (or a program using 
libavformat) can sleep until one of the selected inputs can provide a 
packet.

> an example where this might be fatal is a low fps webcam or rtp and a normal
> tv capture at the same time, think of no rtp packets for a second or 2 and
> v4l(2) having to buffer 50 frames or so
I see the point (a better example would be capturing video with v4l and 
audio with an OSS driver... Video frames risk to be dropped for this 
reason :).
If I understand the current ffmpeg.c code, ffmpeg is trying to 
understand which input will be able to provide a packet first, and then 
to read from such input (so, ffmpeg is prepared to "blocking input 
formats"... If it is able to correctly guess which one unblocks first, 
then there is no problem).

If we switch AVFormats to a non-blocking behaviour, we will have to 
properly update ffmpeg.c too (and we will probably have to increase some 
version number).

Summing up: I agree with this change; I am just saying that it is a 
little bit more complex than simply returning EAGAIN :)


			Thanks,
				Luca