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

[Oded Shimon]

On Sat, Dec 31, 2005 at 06:11:03PM +0100, Michael Niedermayer wrote:
> On Sat, Dec 31, 2005 at 06:37:35PM +0200, Oded Shimon wrote:
> > > hmm, this is somewhat redundant, zero byte keyframes cant occur, so 
> > > zero byte keyframes could mean EOR
> > 
> > Hmm, well, not necessarily, you never know with weird codecs...
> 
> if rich says ok to this iam fine with it too, though i doubt we will ever
> see such a codec and theres some risk of contradictionary streams from brokrn
> muxers (non keyframe EOR or non zero size)

The whole idea of any contradiction is that it signifies stream corruption.

> > back_ptr's are zero because they are just not interesting, the stream is 
> > completely "irrelavent".
> 
> ok as long as seeking works with this, i mean that
> 
> syncpoint keyframe_st2 EOR_st1 syncpoint 
> and seeking to keyframe_st2 will still be able to find the previous keyframe
> for st1

Damnit, I think we totally missed that scenario. :(

OK, change of rule:

back_ptr of an EOR set stream is the real back_ptr, unless all non-EOR 
streams have a smaller back_ptr, in which case it is zero.

> > It has one big flaw IMO, it makes the muxer knowing the future manditory. 
> > Or at the very least a smart muxer-caller.
> > 
> > I decided with Rich that the API for the muxer will be that you MUST pass 
> > it the mts of a frame whenever you pass it a frame. Meaning either the 
> > caller has to be smart, or it has to use the high level reorderer, which 
> > always uses buffering.
> > MTS however is still the most correct way to store the data IMO... old dts 
> > method is wrong (depends on decode_delay), and MN rule is insufficient.
> 
> i still vote for the dts rule as i fail to see any serious problem with it

It depends on decode_delay. If you set decode_delay arbitrarily big, you'll 
end up with a "video preload", or you can even hack decode_delay to get an 
"audio preload". Both are evil/bad and need to be fixed.

A legal decode_delay is any decode_delay bigger or equal to the real 
decode_delay. Setting it too big should not affect the result.

- ods15