[FFmpeg-devel] [PATCH] simplify ipmovie.c pts calculation
Fri Feb 27 14:49:50 CET 2009
On Fri, Feb 27, 2009 at 02:36:41PM +0100, Michael Niedermayer wrote:
> On Fri, Feb 27, 2009 at 02:27:06PM +0100, Reimar D?ffinger wrote:
> > On Fri, Feb 27, 2009 at 02:18:12PM +0100, Reimar D?ffinger wrote:
> > > On Fri, Feb 27, 2009 at 01:45:39PM +0100, Michael Niedermayer wrote:
> > > > On Fri, Feb 27, 2009 at 08:59:14AM +0100, Reimar D?ffinger wrote:
> > > > > On Fri, Feb 27, 2009 at 12:28:03AM +0100, Michael Niedermayer wrote:
> > >
> > > [concerning code to guess r_frame_rate in libavformat/utils.c]
> > >
> > > > > > also if you ignore the first 1-2 durations then this might fix the fps of
> > > > > > h264_acc_in_flv.flv i think
> > > > >
> > > > > I set the code to ignore the first 4, for that file it gives a frame
> > > > > rate of 22.2222... which seems not really right either, though I don't
> > > > > actually know what the right value is.
> > > >
> > > > > It does not make a difference though, since the get_std_framerate-based
> > > > > code after it overwrites it...
> > > >
> > > > fix that prevents it from increasing the frame rate is welcome ...
> > >
> > > Well, I thought the code was also there to prefer standard rates, not
> > > just reduce the frame rate.
> > > I have not extensively tested, but does attached patch fit the intended
> > > purpose of the code?
> > Sorry, here is a fixed version. The "if" looks a bit ugly though.
> ok if tested a little
Hm, this file:
is detected as
Stream #0.1(eng): Video: svq3, yuvj420p, 534x400, 14.98 tbr, 29.97 tbn, 29.97 tbc
But that seems to be related to your ticks_per_frame changes?
tb_unreliable at least is not set for this, so it can't really be any of
the code I was working on...
More information about the ffmpeg-devel