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

[Oded Shimon]

On Wed, Jan 11, 2006 at 04:54:37PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Jan 11, 2006 at 04:58:46PM +0200, Oded Shimon wrote:
> > On Wed, Jan 11, 2006 at 03:45:56PM +0100, Michael Niedermayer wrote:
> > > On Wed, Jan 11, 2006 at 03:21:38PM +0200, Oded Shimon wrote:
> > > > On Wed, Jan 11, 2006 at 11:53:30AM +0100, Michael Niedermayer wrote:
> > > > > what about:
> > > > > current_dts is the dts of the current frame
> > > > > S is the set of all keyframes which have pts <= current_dts
> > > > > if adding a keyframe to S causes the backptr change to be >= t then write a
> > > > > syncpoint, and assign the maximum pts from S to it
> > > > 
> > > > I'm completely confused by this explanation. Help me with an example. given 
> > > > this scenario:
> > > > 
> > > > audio:   A0  A1  A2  A3  A4  A5  A6
> > > > video: I0  P1  P2  I5  B3  B4  P6  P7
> > > DTS:     -1 0 0 1 1 2 2 3 3 4 4 5 5 6 6
> > > SP:     X0  X1      X2  X3  X4  X5  X6
> > > SP_PTRA -   0       1   2   3   4   5
> > > SP_PTRV -   0       0   0   0   2   2
> > > SP_PTS  -   0       2   3   4   5   6
> > > 
> > > ok, ive added many syncpoints to make it more clear, obviously there
> > > would be fewer in practice ...
> > > and yes probably the pts selection could be improved by adjusting it
> > > downward where possible (X2 2->1)
> > 
> > OK, this seems very similar of the old idea I had of back_ptr not pointing 
> > to NEAREST keyframe, but most correct keyframe. I remember researching this 
> > idea thoroughly, and finding at the very least, that it is complicated as 
> > hell.
> 
> whats so complicated on it? not to mention pointing to nearest is totally
> wrong

Only when using a single pts for all streams. :)

> write_sp(){
> 1. find the most recent keyframes in each stream which have pts<=current dts
> 2. find the corresponding syncpoints for these keyframes and set the back_ptrs
> 3. find the first keyframe after each of these syncpoints and set sp_pts to
> their maximum pts
> }
> 
> and when to write it:
> "if writing the next frame would cause the syncpoint distance to be >t then
> write a syncpoint before the next frame"
> together with:
> "if any back_ptr would change by >T then write a syncpoint"
> work?
> or does this fail in some silly case

I think you convinced me with "if any back_ptr would change by >T then 
write a syncpoint".

I revisited the old situation where this idea broke, and this rule solves 
it.

The idea is still complicated in the sense that it's not fully 
straightforward to write a seeker, and also that you need to remember 
several keyframes per stream (i.e., manage a buffer), not just store some 
single variables. I think you'll also need to store all/some syncpoints... 
But you needed that anyway for the index.

There's one part I still have problem with - what is "current_dts"?... 
unfortunately, dts is not monotone across streams... you can't just grab 
the dts of the last frame put in the file, because you could end up with 
non monotone syncpoint ts.

For this whole algo to work it is crucial for the syncpoint ts to be 
correct and accurate...

S1 K1 .... S2 K2 .... S3 .. S4

P is requested pts..
both K has pts smaller than P
S3 is pointing to S1.
S4 is pointing to S2.

The bounds of the linear search is from S1 to S2, because S2-S1 > t .

When looking for the syncpoint smaller than P, S4 should be chosen because 
the second K has smaller pts than P. For the algo to work:

(K2.pts == S4.ts) < P

must be satisfied. If it won't, as in, S4.ts will be bigger than K2.pts, 
your P request might pick up S3 instead of S4, even though S4 is good for 
you. (K2.pts < P < S4.ts)

This is exactly the problem I was originally having with this back_ptr 
method. With your algo, there's no garuntee that S4.ts will be identical to 
S3.pts. Actually, even if you solve all this, if I recall correctly, you'll 
end up having to put multiple syncpoints between 2 frames! (supposed the 
dts difference between those 2 frames is huge, now you have to make up for 
several keyframes which you never gave them back_ptr credit.)

Sorry, I've changed my mind half way through the mail. :/ I'm voting back 
to single pts for all decode_delay=0 streams, and pts for each of the rest 
of the streams.

No sane file will have more than a single delayed stream, so all this 
complication is saved by just adding a single pts per syncpoint...

- ods15