[FFmpeg-devel] [PATCH] simplify ipmovie.c pts calculation

[Reimar Döffinger]

On Fri, Feb 27, 2009 at 03:02:54PM +0100, Michael Niedermayer wrote:
> On Fri, Feb 27, 2009 at 02:49:50PM +0100, Reimar D?ffinger wrote:
> > 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:
> > http://download.theforce.net/theater/shortfilms/sinsofthejedi/SinsOfTheJedi_Part1.mov
> > 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...
> 
> should be fixed

And I applied my patch, hopefully my samples were representative
enough...

> PS: a SVQ3 regerssion test would be very welcome, i broke SVQ3 so often
>     already with h264 changes ...

Is Mike listening? ;-)