[MPlayer-dev-eng] Lots of stuff for NUT

[Rich Felker]

On Sat, Dec 31, 2005 at 10:54:16PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Dec 31, 2005 at 04:30:20PM -0500, Rich Felker wrote:
> > On Sat, Dec 31, 2005 at 09:34:03PM +0100, Michael Niedermayer wrote:
> > > > > hmm, why not simply make larger decode_delay illegal?
> > 
> > Impossible; it's not known. What if I set B frame strategy to 1, and
> > the encoder decides never to use a B frame? Then my file is illegal!
> > Or, even if it does eventually use a B frame, the partly written file
> > is illegal until it gets to the B frame. Any law that can only be
> > evaluated by looking globally at the file rather than locally at all
> > parts is inherently broken.
> 
> no, thats wrong, in mpeg1/2/4 theres a flag (low_delay) in the header 
> which specifies the delay, if low_delay=0 b frames are allowed but even if
> there are none the delay is still 1 not 0, having the demuxer produce 
> dts=pts frames in this case is _wrong_
> 
> furthermore using mts ordering does not remove the need to know decode
> delay exactly as decode_delay is needed for calculating DTS

OK, I think we're thinking about things from different perspectives.
Your perspective is that dts corresponds to something outside of NUT,
and that NUT demuxer needs to provide correct dts to the codec/player.
I think this is reasonable for mpeg1/2/4, but maybe not for all codecs
in general. What if there's a hypothetical codec that's never intended
to be used with one-in-one-out delayed decoding and that has no sense
of dts? What is the correct decode_delay to use then? Or..maybe we
think all codecs should define delay. That's a view I personally tend
to agree with, but uau seems to think the opposite..

Rich