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

[Michael Niedermayer]

Hi

On Monday 03 May 2004 14:43, Michael Niedermayer wrote:
> Hi
>
> On Monday 03 May 2004 07:01, D Richard Felker III wrote:
[...]
>
> > (As a less radical proposal, we could choose to support both
> > and strongly recommend that delta prediction NOT be used.)
> >
> > On to the next topic...
> >
> > The current draft of the spec calls for each stream to fully code the
> > timestamp in its next frame after a type-2 startcode. Depending on the
> > time base units in use, this results in an overhead of at least 8+3*N
> > bytes per startcode, where N is the number of streams (for a 1-2 hour
> > movie, you need at least 3 bytes to store a timestamp, or worse if you
> > choose/need a bad time base). For error resilience purposes, it may be
> > desirable to put startcodes fairly frequently, and at low bitrates
> > this could result in considerable overhead.
> >
> > If we have lots of streams, it seems redundant to code the full
> > timestamps for ALL of them. In fact, all the timestamps should be
> > approximately the same, due to proper interleaving. Let's take
> > advantage of that redundancy by storing a single timestamp with the
> > startcode, and calling the startcode+timestamp unit a "sync point".
> > This timestamp can be in a global time base, specified in the global
> > header.
> >
> > Having a global time base (that may, but doesn't necessarily,
> > correspond to one or more of the stream time bases) has an additional
> > advantage, in that we can use it for indexing. Our intent has been
> > that the index would point to startcodes anyway, rather than packets
> > of a particular stream, so it makes sense for the startcodes to have
> > their own timestamps. When a demuxer encounters a sync point, it would
> > convert the associated timestamp into the separate time bases of each
> > stream, and consider future delta/lsb timestamps to be relative to
> > that time.
> >
> > Note that under this system, the overhead from startcodes is reduced
> > from 8+3*N (or more) to something like 11+N. Or, in the case of a
> > naive muxer that is always coding the lsb timestamps on each frame,
> > the additional overhead for a sync point is only a constant 11 bytes
> > (or 10 or 12, depending on the time base)!
> >
> > 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

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en