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

[Michael Niedermayer]

Hi

On Sat, Dec 31, 2005 at 09:15:49PM +0200, Oded Shimon wrote:
[...]
> > > 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.

hmm, why not simply make larger decode_delay illegal?

[...]
-- 
Michael