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

[Rich Felker]

On Sat, Dec 31, 2005 at 11:35:56PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Dec 31, 2005 at 05:12:40PM -0500, Rich Felker wrote:
> > 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..
> 
> if there is no one-one in out correspondance then pts will be gone not dts
> dts are the times at which you must feed a packet into the decoder pts
> are the times of when the packets come out if a packet has no clearly defined
> out theres no pts

pts is the time that the picture stored in the encoded frame needs to
be displayed. Deciding when to decode it in order to ensure that it
can be displayed at the correct time is the job of the player, and the
container format just needs to ensure that the player can determine
this efficiently (in time and memory usage).

Maybe you misunderstood what I said and thought I was talking about
some stupid codec with 3d dct or wavelet... Then there is an issue,
but by "one-in-one-out delayed decoding" I just meant the model of
having input and output synchronized rather then using nondelayed
output (as supported by lavc decoder) with the player having to buffer
the output frames and handle displaying them in order at the right
times.

Sorry if what I said was misleading..

Rich