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

[Michael Niedermayer]

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


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

[...]
-- 
Michael