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

[Michael Niedermayer]

Hi

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

hmm, if true that sucks, can any of the x264 devels confirm this? iam too
lazy to decrypt the h.264 spec ATM and maybe someone already knows the awnser

btw, mts will need 2pass too if decode delay isnt known
you cant take the minimum PTS of n packets if you dont know some value
m which is >=n well you know one the whole file (= 2pass)

[...]

-- 
Michael