[Ffmpeg-devel] [PATCH] Clarify definition of r_frame_rate

[Fred Rothganger]

Michael Niedermayer wrote:
> see avformat.h i svn
>
>     /**
>      * real base frame rate of the stream.
>      * this is the lowest framerate with which all timestamps can be
>      * represented accurately (its the least common multiple of all
>      * framerates in the stream), Note, this value is just a guess!
>      * for example if the timebase is 1/90000 and all frames have either
>      * approximately 3600 or 1800 timer ticks then r_frame_rate will be 50/1
>      */
>     AVRational r_frame_rate;
>   

Thanks for clarifying this.  The updated comment helps a lot.

I probably will need a new field for average frame rate then.  Could we 
call it "avg_frame_rate"?  It would be calculated in 
av_find_stream_info() and have the semantics I described before.  IE: an 
average based on a small sample of the start of the stream (the same 
sample used to calculate r_frame_rate), with special case to lock to 
24000/1001 fps if it appears to be present.  If you agree, I will submit 
a patch for it soon.

Here are some observations about r_frame_rate that may or may not be 
problems:

* In the past, and at least for MPEG, the code to detect a 24 fps source 
would round everything within 1/2 fps of 24000/1001 to that value.  
However, that code has now been removed.  The current code has a quantum 
of 1/12 fps, so rounding occurs within 1/24 fps of a certain level, 
making it more likely that a 24 fps source will be missed.  IE: for 
24000/1001 fps to be preferred over a 1/12 fps quantum, the actual value 
must already be quite close to 24000/1001.

* You modified the code in av_find_stream_info() to handle an issue with 
the Groundhog Day sample I uploaded.  It now delivers an r_frame_rate of 
60000/1001, even though the movie is 24000/1001.  Your change makes 
sense given the definition of r_frame_rate above.  However, the code is 
really latching onto a "glitch" at the start of the vob.  Specifically, 
I used "SmartRipper 2.41" to extract this material from the dvd, and 
used an option to split the vobs by chapter.  It probably munged the 
timestamp at the start of each chapter to fit the coded frame rate 
rather than the real frame rate.

-- Fred

BTW, the reason it took me so long to get back on this is that I've been 
spending my very limited spare time setting up an htpc.  :)  So far, 
mplayer holds better audio sync than xine on some of my dvds, but 
haven't yet got 5.1 to work right...