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

[Michael Niedermayer]

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


> 
> 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


> 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?


[...]
-- 
Michael