[MPlayer-dev-eng] NUT cleanup

[Michael Niedermayer]

Hi

On Mon, Sep 05, 2005 at 09:39:12PM -0400, Rich Felker wrote:
> On Mon, Sep 05, 2005 at 03:28:25PM +0200, Michael Niedermayer wrote:
> > Hi
> > 
> > On Mon, Sep 05, 2005 at 12:47:49AM -0400, Rich Felker wrote:
> > > An additional topic: after talking on #mplayerdev today, several of us
> > > realized that the current interleaving requirement is rather stupid.
> > > Right now it says that pts must be monotone for packets with pts==dts.
> > > A much cleaner requirement would be that dts be monotone for all
> > > packets (across all streams). This is also a slightly stricter
> > > condition in the presence of high decode_delay, meaning that it makes
> > > error detection from bad pts slightly more robust.
> > 
> > hmm, i thought that monotone dts where what the spec required, its what
> > it should be and how its implemented in lavf, so id say thats a "typo"
> > in the spec, feel free to fix it
> 
> Actually after talking with uau on #mplayerdev, I'm concerned that
> muxing with monotone dts and our current definition of dts may be
> nonsense when applied in some cases with dts!=pts... :(
> 
> Consider the example where we have (I know, very stupid, but he
> insists...) a subtitle codec with I/P/B frames, and the following
> timestamps:
> 
> I0 P2 B1 [period with no subs] I100 P102 B101 P104 B103 ...
> 
> Now, the dts sequence for these frames becomes:
> 
> I0 P2 B1 [period with no subs] I100 P102 B101 P104 B103 ...
> -1  0  1                          2  100  101  102  103
> 
> i.e. the subtitle that's supposed to appear at pts of 100 gets muxed
> at dts of 2, and won't be seen when it's actually time to show it.
> Also it's not useful whatsoever to have the packet available at time
> 2, as far as I can tell.
> 
> Granted this case is pathological and stupid, but do we need to treat
> it in some way?

IMHO no
to decode some part you must start at the earliest
keyframe of the streams you care about, that was always the case and doesnt
need b frames or unrealistic timestamps

[...]

-- 
Michael