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

[Reimar Döffinger]

On Thu, Feb 26, 2009 at 07:50:47PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 26, 2009 at 07:31:04PM +0100, Reimar D?ffinger wrote:
> > On Thu, Feb 26, 2009 at 07:01:49PM +0100, Michael Niedermayer wrote:
> > > On Thu, Feb 26, 2009 at 06:47:23PM +0100, Reimar D?ffinger wrote:
> > > > On Thu, Feb 26, 2009 at 05:14:16PM +0100, Michael Niedermayer wrote:
> > > > > why does lavf fail?
> > > > > could you print the duration from the packets (i mean pts-last_pts) ?
> > > > > if they are (near) multiplies of some integer lavf should find the
> > > > > timebase, if OTOH they are random then 1/1m is maybe the best timebase
> > > > > in which these can be specified exactly
> > > > 
> > > > Can you point me to the code that does this guessing? I didn't find it.
> > > 
> > > see code calling tb_unreliable() in lavf/utils.c
> > 
> > Maybe that is just a bad name, but the time base is not unreliable, not
> > a bit, it is 100% exact. It just has no relation with the frame rate
> > (admittedly, tb_unreliable checks if the time_base would make a valid
> > frame rate).
> > Obviously, the code around line 2192 in utils.c is supposed to fix up
> > that kind of thing.
> 
> > I guess the error is in that completely unexplained and mysterious
> > calculation of the initial best_error value.
> 
> its set so that only frame rates are accepted that would generate the
> found timestamps within +-1 or so rounding errors in the timestamps.

Then that code is to fix a different issue anyway.

> btw you multiply 2 values together to get pts differences, what are these 2 values?

To quote multimedia wiki:

The normal values I've seen here are 0x2095 for the timer rate (8341),
and 8 for the timer subdivision. What this means in practice is that
every 8*8341 (=66728) microseconds, it should be ready to send out the
next frame. So... 10000000/66728 == 14.9 frames per second typically.
The exact purpose for the timer subdivision is unclear to me, but it may
be an artifact of earlier methods of timer handling, since some of the
code here appears to possibly even date back to the DOS days. 


It might originally have been a value that some timer is programmed with
and the other value would be how many timer interrupts to wait.