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

[Oded Shimon]

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

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.

Pro: simplest, most elegant, easiest to implement.
Con: obviously overhead, and theoretically it does contain redundant 
     data...

2. Go back to single back_ptr and pts. Michael said it best:
 also consider that 1ptr+1pts and per stream ptr+pts differ only if all of
 the following are true:
 1. no index
 2. there is at least one stream with a large keyframe intervall which the
    user doesnt want to seek to / decode
 3. the user wants to seek more exactly then the largest keyframe interval
    of any stream
 4. the media is slow so that the time to read the largest keyframe interval
    is significant, also keep in mind here that due to 1. we will have O(log n)
    physical seeks anyway no matter what we do

- in conclusion, there is no problem of speed of linear search, it's 
  really not bad at all...

The two cons IMO:
 1. Seeking with index and without is very different. It might be possible 
    to collapse the syncpoints into a dynamic index, I'm not sure.
 2. Behavior with large interval keyframe streams is slightly undefined 
    (info streams, userdata streams, subtitles...)

I think I'm done looking into increasingly complicated solutions and focus 
on these 2. :/

- ods15