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

[Michael Niedermayer]

On Thu, Feb 26, 2009 at 08:10:07PM +0100, Reimar D?ffinger wrote:
> 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.

the issue it tries to fix is to select a small timebase in which frames can
be accurately represented.
what it does for your file is certaninly not ideal though,
it should at least realize that 8341/125000 can represent them exactly
a patch that runs gcd over them is welcome

also a patch that lets the user app configure its threshold of acceptance
a little would be welcome, for example
transcoding a file with 1/10000000 timebase to avi reqiures a smaller
timebase and it should select the best it can.
while transcoding the same file to nut or mov would not require a
smaller timebase so it should be very carefull.
also if the timebase is already nice like 1/30 then avi can already
handle it and it should be carefull with switching ...


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

why didnt they use 61*1094 or 12*5561 ? both these are more accurate

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090226/ef821e3b/attachment.pgp>