[MPlayer-dev-eng] NUT dts proposal

[Uoti A Urpala]

Michael Niedermayer wrote:
> > The current system also requires unlimited buffering on the muxer side
> > when muxing live content: if one "live" stream has a gap, muxing has
> > to stop and all other streams must be buffered until the first frame
> > after the gap is available.
> 
> live content which has low delay requirements doesnt use codecs with a 
> delay furthermore the combination of delay + gap is pretty obscure on its 
> own

There's no reason why the live content would have to be SO low delay
that a codec with B frames could not be used.


I'll try to summarize the (dis)advantages of both methods:

"dts based"
Has no advantages if the player has a good decoder. Requires less
buffering if the player has a bad decoder that refuses to output
a keyframe before reading the next frame(s) after it.
Keyframes in different streams are out of order (video keyframes in
streams with decode_delay > 0 appear earlier than audio frames with
same pts (decode_delay = 0)), which requires reading more after seeking
before suitable keyframes for all streams are found.
In a stream with gaps and decode_delay > 0, loses first frames after
the gap when seeking.
Cannot be used to mux live content with long gaps and decode_delay > 0.


"mts based"
Optimal behaviour when seeking.
If the player has a bad decoder, may require either buffering the
other streams until the decode_delay next frames in this stream are
found (buffering audio until next video frame in typical video with B
frames case), or if there's a gap that cannot be buffered, losing the
last decode_delay frames before it.