[MPlayer-dev-eng] NUT (informal) proposal, based on discussions

[Michael Niedermayer]

Hi

On Tue, Jan 17, 2006 at 09:20:02PM -0500, Rich Felker wrote:
[...]
> > > * Binary search will put you at S13. S13's back_ptr points all the way
> > >   back to S1, which is incorrect.
> > > 
> > > * Linear search S13 to S24. Keyframe not found.
> > > 
> > > * Jump back to S24's back_ptr. This will (necessarily) point to K15.
> > > 
> > > * Win!
> > > 
> > > The main disadvantage of this method is that it cannot guarantee that
> > > you will not perform an additional media seek after the binary search.
> > > But just like the index case, I see no way to guarantee this without
> > > full per-stream pts which would be very large at the syncpoint level
> > > (since you can't code them relative to previous syncpoint).
> > 
> > what about
> > 
> > S1 K2 .....several_megs_no_K..... K15 S13 K17 ...no_K_or_S... S24
> > 
> > * Trying to seek to timestamp 16. Should get K15.
> > * Binary search will put you at S13. S13's back_ptr points all the way
> >   back to S1, which is not optimal.
> > * Linear search S13 to S24. K17 found but thats after ts=16
> > * Jump back to S24's back_ptr. This points to K17/S13 again not helpfull
> > 
> > -> K15 not found, or did i violate some rule?
> 
> yes, there are problems we've been discussing on irc too. some of the
> problems have a fix by changing the definition of the back_ptr
> appropriately, but i don't know if they all do. i'm still
> investigating. will let you know when there's an update, unless you
> come up with a brilliant idea first. :)

some rule like:
there must be no interval of max_distance in which any stream has a keyframe
but no back ptr anywhere including outside this intervall pointing to any
keyframe of that stream in the interval

in our case above both K2 and K15 would need some syncpoints pointing to
them to fullfill this ...

the rule is also easily checkable in a demuxer or "verifer"

[...]
-- 
Michael