[FFmpeg-devel] [PATCH] Frame rate emulation
Thu Jun 21 09:53:05 CEST 2007
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
> 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
More information about the ffmpeg-devel