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

[Rich Felker]

On Wed, Jan 18, 2006 at 01:29:36PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Jan 18, 2006 at 01:36:07PM +0200, Oded Shimon wrote:
> > On Wed, Jan 18, 2006 at 03:54:34AM +0100, Michael Niedermayer wrote:
> > > On Tue, Jan 17, 2006 at 09:20:02PM -0500, Rich Felker wrote:
> > > > 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 ...
> > 
> > I'm not sure I understand this rule, but I think it comes at relatively 
> > high implementation cost in muxer...
> 
> hmm, lets see
> 1. keep track of the last keyframe of every stream (easy)
> 2. keep track of the keyframe which was the target of the last back_ptr 
>    of every stream (easy)
> 3. if last_keyframe != last_target && current_keyframe - last_target > max_dist
>         write syncpoint; 
>         last_target= last_keyframe= current_keyframe;
> 
> doesnt seem that bad ...

Agree. There may be another way to guarantee something similar..

> > I think we are back to complexity, and I want that gone... I have 2 votes:
> > 
> > 1. Per stream pts and back_ptr in syncpoints, with this syncpoint placement 
> > rule:
> > When putting a keyframe for a certain stream, if it makes back_ptr change
> > by more than T, queue a syncpoint to be written before the next keyfame for
> > this stream. If by then a syncpoint has already been written, don't bother.
> 
> well, that rule should be fine too to avoid the example problem there was with
> a single pts + per stream ptrs, though i dont know if there are others where
> this would fail

I was just telling Oded on IRC, I don't think this proposal addresses
the problem.

Rich