[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)
> 
> 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

and what about:

Muxed frame oder:   I0 P3 B1 B2 I100 B4 ... B99 P103 B101 B102
Current dts system: -1  0  1  2    3  4 ...  99  100  101  102
Possible new dts:    0  1  1  2    4  4 ...  99  101  101  102

here the new system "fails" too, and as loren has already said
the alternatives have issues with 1 in 1 out decoders

[...]
-- 
Michael