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

[Oded Shimon]

On Thu, Jan 12, 2006 at 08:06:47PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Jan 11, 2006 at 08:59:25PM +0200, Oded Shimon wrote:
> [...]
> > > 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.
> 
> well choosing dts is easy, do strict dts ordering

I thought we discussed this... :)
Didn't we finally decide on loose MN rule, not strict dts?

> > 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. 
> 
> you mean K2.pts and your analysis is wrong, my algorithm does gurantee this
> its dead trivial, S3 as you say points to S1 so as we increase the timestamps
> of the current (unwritten) syncpoint we will reach the pts of K2 (remember
> dts are reordered pts so we must reach it exactly) at that point SX.ts == K2.pts
> and because S2 - S1 is over the thershold t (iam assuming T=t here) the back
> ptr change rule will force a syncpoint to be written with SX.ts == K2.pts

Yeah, I suppose ot all works thanks to dts evantually always becoming 
pts... Except when EOR...

> > 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.)
> 
> well, dts are reordered pts so i dont see how you could have anything between 
> 2 consecutive dts values assuming strict dts ordering, if you do something else
> then yes, you end up with multiple syncpoints beween frames but even that isnt
> a problem or?

The spec at the moment does not allow putting more than one syncpoint 
before a frame. However, I suppose in the rare case of EOR, you can allow 
multiple syncpoints... Basically you have to flush your dts_cache, keeping 
strict dts monoticity, and writing syncpoints as necessary. (It's as if you 
are writing frames with dts matching whats left in dts cache..)

Regarding strict dts ordering - We can go back to that, but take care of 
EOR... And uau will keep flaming how strict dts is not perfect. :/

- ods15