[MPlayer-dev-eng] NUT dts proposal

[Rich Felker]

On Thu, Sep 08, 2005 at 01:15:21AM +0300, Uoti A Urpala wrote:
> I'll try to summarize the (dis)advantages of both methods:
> 
> "dts based"
> [...]
> Cannot be used to mux live content with long gaps and decode_delay > 0.

Yes. The case to consider is where the gapped stream is 'subtitle'
stream with frequently changing content, where IPB-type codec might be
useful. For instance, drawing commentators' play diagrams on top of
the action during a live or semi-live sports cast.

While I agree it's stupid and pathological to use IPB type codec for
this, some idiot someday will probably decide to do it. :((

> "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.

IMO all such "bad" decoders have a "flush" operation to get the very
last frame(s). It seems like a player could just flush the codec if
the demuxer knows (from muxing requirements) that no prior frames
depending on the "pending" frame(s) can be demuxed.

Rich