[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Tue, Sep 06, 2005 at 06:22:24PM +0200, Michael Niedermayer wrote:
> 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

The problem here is what happens if we seek to timestamp of 90 or so..
We should be able to start decoding the keyframe with pts==100, but
we'll have a very hard time finding it since it's stored way back at
dts==2. :( In fact without an index there's no way to find it without
essentially doing a linear search thru the whole file up to dts==100.

Do you have a good solution?

Rich