[FFmpeg-devel] [PATCH] Frame rate emulation

Michael Niedermayer michaelni
Sat Aug 18 23:06:53 CEST 2007


On Sat, Aug 11, 2007 at 10:06:21PM -0300, Ramiro Ribeiro Polla wrote:
> Michael Niedermayer wrote:
>> Hi
>> On Thu, Aug 09, 2007 at 08:21:12PM -0300, Ramiro Ribeiro Polla wrote:
> [...]
>>> Updated patches introduce AVRateEmu, and use it with AVFMT_FLAG_NONBLOCK 
>>> in v4l and x11grab. Tested with r9876 reverted, and works the same with 
>>> v4l and x11grab.
>> what about moving the av rate emu loop to av_read_frame_internal()
>> that would avoid duplicating it for every grab demuxer
> Patches attached. Regression tests pass and capture works well.
> This way seems to me a little too intrusive inside libavformat though.
> I have 2 more demuxers that would use this (vfw and gdi32 capture) just 
> waiting to send in for review.

the more i see of this code the more i realize how broken it is

lets start from square 1 again

there are different kinds of video sources
1. the ones which have a fixed frame rate onto which you have no influence
(v4l, v4l2, vfw) for them no form of waiting based on the current time is
correct why you want to use the frame rate emu hacks with them is a mystery
to me
if you want to support droping every 2nd, 3rd or whatever frame to reduce
the framerate and cpu/mem work that is a seperate thing which several hardware
graber cards support directly though i dont know if v4l*/vfw makes this
if not, every 2nd or 3rd frame still can be just ignored/droped in the

2. the ones which can truely grab at any time and provide a proper API
to do so (i dont know if these exist)
here you just tell the thing from which time you want a frame

3. the ones which can truely grab at any time but provide no means except
for them a workaround like
if(current_time < time of next frame we want)
    return EAGAIN;
in the demuxer is the obvous solution

now as some have argued ffmpeg.c can not handly EAGAIN properly currently
so ive suggested to move the EAGAIN handling into av_read_frame_internal()
so the sleep and possibly retry will be done there shielding ffmpeg.c 
which people done want to fix from it
it seems my suggestion to move the code to av_read_frame_internal though
wasnt very clear ...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070818/9e718087/attachment.pgp>

More information about the ffmpeg-devel mailing list