[FFmpeg-devel] [PATCH] Frame rate emulation

[Ramiro Ribeiro Polla]

Michael Niedermayer wrote:
> Hi
>
> On Mon, Jun 11, 2007 at 11:01:50AM -0300, Ramiro Ribeiro Polla wrote:
>   
>> Michael Niedermayer wrote:
>>
>>     
>>> Hi
>>>
>>> On Wed, Jun 06, 2007 at 03:31:03PM -0300, Ramiro Ribeiro Polla wrote:
>>>  
>>>
>>>       
>>>> Hello,
>>>>
>>>> x11grab provides its own frame rate emulation inside its read_frame 
>>>> function. Many other grab formats will need it (GDI, VFW...), so it 
>>>> would be best to make a format level frame rate emulation in FFmpeg, and 
>>>> not each demuxer (also I believe they don't belong in the demuxers 
>>>> themselves).
>>>>
>>>> FFmpeg already provides a frame rate emulation (added for DV), but it 
>>>> works depending on a codec's demand, and not at a format level, like 
>>>> avcodec.h says:
>>>>    /**
>>>>     * Frame rate emulation. If not zero, the lower layer (i.e. format 
>>>> handler)
>>>>     * has to read frames at native frame rate.
>>>>     * - encoding: Set by user.
>>>>     * - decoding: unused
>>>>     */
>>>>
>>>> It's in Fabrice's TODO "suppress rate_emu from AVCodecContext".
>>>>
>>>> I don't know DV's needs for rate emulation, but couldn't it be passed to 
>>>> ffmpeg.c's AVOutputStream instead of AVCodecContext? It would depend on 
>>>> the format then, and not the codec.
>>>>
>>>> Also, I plan to add that to AVInputStream, right before av_read_frame, 
>>>> where it will be useful for grabbing demuxers.
>>>>
>>>> Can there be 2 places where rate emulation occurs (reading from the 
>>>> format, and writing to the codec)?
>>>> Is it ok for DV for the rate emulation to occur at writing to the output 
>>>> format, so it's checked in AVOutputStream?
>>>>    
>>>>
>>>>         
>>> first, AVInputStream / AVOutputStream are private structs of ffmpeg.c
>>> libav* is used by more than just ffmpeg.c thus moving essential 
>>> functionality into ffmpeg.c is not ok
>>>
>>>  
>>>
>>>       
>> But ffmpeg.c is currently responsible for the actual frame rate emulation.
>> Anyways, it's your decision, so I won't bother with output frame rate 
>> emulation anymore.
>> I'll just leave that in Fabrice's TODO =)
>>
>>     
>>> second, its the input formats / demuxers job to read the frames properly
>>> that includes reading them at the proper time for realtime stuff, sane
>>> capture APIs should provide the needed functionality to capture at a specific
>>> time. simply waiting in ffmpeg.c and then calling the demuxer is a incredibly
>>> inaccurate way to do it, keep in mind ffmpeg does encoding, writeing and
>>> others too, using a seperate thread would probably be needed ...
>>>
>>>  
>>>
>>>       
>> To avoid duplicating the same code in all grabbing formats that require 
>> it (only X11 for the moment, but VFW and GDI will also need it), is it 
>> ok to move the input frame rate emulation from x11grab.c to 
>> libavformat/utils.c under the name ff_rate_emu (or something similar)? 
>> Or should it be av_rate_emu?
>>     
>
> it should be moved into a new file so its not compiled if no grabing
> interface is
>
>   

Now that I looked closer and implemented it, ffmpeg.c could also benefit 
from the same code, so it's best if unconditionally compiled (= no need 
for a separate file that depends on grabbing interfaces). Being this 
way, is it acceptable to put it in utils.c? If not, where?
There are 2 different implementations of rate emulation in FFmpeg. One 
in ffmpeg.c, and the other in x11grab.c. Which one is preferred?
Attached patch uses ffmpeg.c's.
Is it possible for a codec to change time_base? I don't know if it's 
best for time_base to be passed on initialization or every call to 
av_rate_emu.

Ramiro Polla
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rate_emu.diff
Type: text/x-patch
Size: 5114 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070611/7c7577da/attachment.bin>