[MPlayer-dev-eng] NUT dts proposal

Rich Felker dalias at aerifal.cx
Thu Sep 8 00:41:52 CEST 2005


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




More information about the MPlayer-dev-eng mailing list