[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Wed, Sep 07, 2005 at 08:57:54PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Sep 07, 2005 at 11:25:46AM -0400, Rich Felker wrote:
> > On Wed, Sep 07, 2005 at 01:18:02AM -0700, Loren Merritt wrote:
> > > >The problem here is what happens if we seek to timestamp of 90 or so..
> > > >We should be able to start decoding the keyframe with pts==100, but
> > > >we'll have a very hard time finding it since it's stored way back at
> > > >dts==2. :( In fact without an index there's no way to find it without
> > > >essentially doing a linear search thru the whole file up to dts==100.
> > > >
> > > >Do you have a good solution?
> > > >
> > > >Rich
> > > 
> > > The only solution I know of (good or otherwise) is:
> > > Don't require 1 coded frame -> 1 decoded frame. If you ever want to see 
> > > the last frame, the decoder must support outputting a frame without 
> > > inputting the next.
> > 
> > Of course. The decoder should always operate in "low_delay" mode, and
> > output each frame immediately. It's up to the player to time them
> > correctly using pts.
> 
> ahh we have a volunteer to rewrite all players, perfect :)

:)))))))
For most purposes, a player with broken 1-1 delayed decoding will work
just fine. However I don't think such a player can work correctly for
all types of content regardless of the container used. It's certainly
not possible to play pathological NUT files in a compliant way with
such a decoder.

Whether we should add to the semantic requirements a statement that
players need not handle pathological cases, or that they must handle
such cases to be fully conformant, is an open question.. But I don't
think it needs to be addressed immediately.

Anyway, anyone using an IPB codec for a stream with huge gaps in it
(our main pathological example so far) would presumably ensure that
the relevant decoders are aware that there might be long gaps and able
to deal with low-delay decoding.

> for the libavcodec side, just set CODEC_FLAG_LOW_DELAY and you will get the
> frames immedeatly like you want

Yes. This is necessary to support the other pathological case I know
about: a frame sequence of I0 P1 B2 where B2 depends on I0 and P1. I
know this is nonsense with regard to the MPEG specs, but there's no
technical reason it couldn't be done with a flexible container like
NUT. Again, whether the semantic requirements should forbid it is an
open question. :)

Rich