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

[Oded Shimon]

On Sat, Dec 31, 2005 at 09:08:28PM +0100, Michael Niedermayer wrote:
> 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?

Unofrtunately, it's non-trivial to know it in advance with an H.264 file.. 
atleast not when remuxing. You'll most likely nees 2-pass.

- ods15