[Ffmpeg-devel] [PATCH] Clarify definition of r_frame_rate
Fri Nov 24 15:56:14 CET 2006
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"?
> 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
> * 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
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