[FFmpeg-devel] [PATCH] Frame rate emulation

[Luca Abeni]

Hi Michael,

Michael Niedermayer wrote:
[...]
>> 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.
> 
> this doesnt sound like it would be easy to implement ...
I agree. If it was easy, I would have sent a patch :)

>> 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).
> 
> well what about x11 which can provide a frame at any time but this still is
> not what is wanted
I do not know... I think the current ffmpeg behaviour is to expect it to 
block according to the requested frame rate (so, ffmpeg.c can still be 
able to guess which input will unblock first).

> also some sort of priority should be given to audio if full rate capture
> of all streams becomes impossibl, droping 1 video frames is hardly noticeable
> loosing 1 audio frame is very noticeable
I agree... This would require heavy modifications to ffmpeg.c, I believe.

>> 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).
> 
> we could add a flag which enables non blockng behavior
Yes, I like this idea. I'll work on it as soon as I find some time, and 
I submit a patch introducing the new avformat flag, and updating v4l2.c


			Thanks,
				Luca