[MPlayer-dev-eng] NUT pts/startcode optimization proposal

D Richard Felker III dalias at aerifal.cx
Sun May 2 20:57:18 CEST 2004


>From the nut spec:

coded_timestamp
        if coded_timestamp < (1<<msb_timestamp_shift) then its a
        lsb timestamp, otherwise its a full timestamp + (1<<msb_timestamp_shift)
        lsb timestamps are converted to full timesamps by:
        mask = (1<<msb_timestamp_shift)-1;
        delta= last_timestamp - mask/2
        timestamp= ((timestamp_lsb-delta)&mask) + delta
        a full timestamp must be used if there is no reference timestamp
        available after the last frame_startcode with the current stream_id

IMO we can optimize this. If there are many streams, it's silly to
encode the full timestamp for _each_ one after a frame_startcode. So I
propose the following instead:

1. Code full timestamp for the first frame after a startcode.

2. Only code lsb timestamp for the first frame in subsequent streams,
   when possible.

When is it possible? As long as the msb timestamp of the first (fully
coded) frame, converted into the timebase of the current frame,
matches the current frame's msb timestamp. :)

The above proposal is somewhat assymetric, i.e. the first stream after
the startcode is somehow special. Perhaps a better approach would be
to store the msb timestamp in a global timebase (for example
lcm(time_base_nom[0..N])/gcd(time_base_denom[0..N]), or just usec, but
it should be configurable in global header!!) immediately after the
startcode, and then convert that to the separate time base units for
each stream to use as the initial msb timestamp.

I like this second proposal better. By having a "startcode timebase"
separate from the individual streams, you have a natural way to store
an index that points to startcodes (rather than keyframes, which are
bad to point to since there might be very many!). And instead of
wasting at least 8+3*N (N=num_streams) bytes per startcode, you're
likely to only waste 11+N or 12+N (or only 11 or 12 if some of my
other proposals on -cvslog are adopted).

Rich








More information about the MPlayer-dev-eng mailing list