[MPlayer-dev-eng] More on timestamps in NUT

[D Richard Felker III]

On Mon, May 03, 2004 at 07:53:22PM +0200, Michael Niedermayer wrote:
> > > THEREFORE, I propose that we replace the type-2 startcodes with a sync
> > > point packet containing its own timestamp, specify that subsequent
> > > relative/lsb timestamps are based on the sync point timestamp, and
> > > remove the requirement that frames following a type-2 startcode fully
> > > code their timestamps.
> >
> > agree
> theres a problem with this, if we have a 32/32bit per stream timebase and a 
> 32/32bit global timebase how do we convert the 32bit? sync point timestamp?
> 32*32*32/(32*32) has a >64bit intermediate, ok, ffmpeg has some code to do 
> 64*32/32 but that isnt guranteed to be enough here and even if, its still a 
> bit complicated

IMO your estimates of 32 bits are far above the real size. For one
thing, the denominators have to be at least 4 bits smaller than the
numerators in stream time bases (just by a basic frames-per-second
argument) and in reality the numerators will never be greater than 24
bits. So in the worst case we have something like B*24*20/24/20. This
is bad if B is > 20 bits, I suppose. But in normal usage, the
numerators will only be so big if the denominator is really small
(something dumb like usec timing), and otherwise the time bases will
be at worst 17/10 (the dreaded 120000/1001 :).

If you like, you could define the conversion to take place in a
different (less precise) order: to convert t from a/b units to c/d,
use: t*a/c*d/b or something similar. I agree it's probably undesirable
to require 96- or 128-bit arithmetic... :)

Rich