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

Michael Niedermayer michaelni
Fri Nov 24 15:56:14 CET 2006


Hi

On Fri, Nov 24, 2006 at 07:32:29AM -0700, Fred Rothganger wrote:
> 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"?  

ok


> 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.

i agree with the excption of a special case for 24000/1001, i dont think we
should add such a special case unless we fail to find another solution


> 
> 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.

as the docs say r_frame_rate is a guess, it would be needed to scan the
whole file to set it always correctly of course some optional
scan_the_whole_file mode could be added or a optional 
seek_around_randomly_to_init_stuff

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-devel mailing list