[MPlayer-dev-eng] Lots of stuff for NUT
Michael Niedermayer
michaelni at gmx.at
Sat Dec 31 21:08:28 CET 2005
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
More information about the MPlayer-dev-eng
mailing list