[MPlayer-dev-eng] NUT dts proposal

[Michael Niedermayer]

Hi

On Tue, Sep 06, 2005 at 06:49:55PM -0400, Rich Felker wrote:
> After more discussion on irc, I'm convinced that the current "dts"
> (decode timestamp) spec in NUT has both some pros and cons..
> 
> Pros:
> - dts is very easy to compute.
> - no future context required.
> - for streams with a steady flow of frames, accurately represents the
> optimal time to do the actual decoding for smooth cpu utilization.
> 
> Cons:
> - in the presence of long gaps with no frames, dts requires the first
> decode_delay frames after the gap to be stored before the gap, making
> them impossible to find efficiently.
> - generally makes it difficult to search out a frame by pts, since the
> storage location of a frame might vary considerably from the location
> of frames in other streams with similar pts (mainly if framerates are
> not comparable).
> 
> Recently uau proposed on IRC, and I independently came up with
> something similar as well, for an alternate definition of dts:
> 
> frame[n].dts = min(frame[n].pts, frame[n+1].pts, ..., frame[n+d].pts)
> (where d=decode_delay)

you cant (or well you can but its not a good idea) redefine
dts, they are defined in the codec layer, it would be very confusing to
use a different definition, so mts (muxer timestamp or so should rather
be used IMHO)


> 
> Consequences:
> 
> Consider the typical IPB stream:
> 
> Muxed frame order:  I0 P3 B1 B2 P6 B4 B5 ...
> Current dts system: -1  0  1  2  3  4  5
> Possible new dts:    0  1  1  2  4  4  5
> 
> And the pathological IPB stream with huge gaps:
> 
> Muxed frame oder:   I0 P3 B1 B2 [gap] I100 P103 B101 B102
> Current dts system: -1  0  1  2          3  100  101  102
> Possible new dts:    0  1  1  2        100  101  101  102

hmm, why not weaken the interleaving rule and leave it to the muxer what to
do exactly?
one idea (warning its late&iam tired so it could be nonsense)
is that packet[i].dts <= packet[j].pts when i<j 
with the old dts definition

[...]
-- 
Michael