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

[Oded Shimon]

On Mon, Jan 02, 2006 at 03:46:34AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 02, 2006 at 12:13:57AM +0200, Oded Shimon wrote:
> > On Sun, Jan 01, 2006 at 05:14:07PM +0200, Oded Shimon wrote:
> > > 1. The solution above, and simple give up giving the CLOSEST keyframe to a 
> > >    specific position, but still enough info to decode requested position.
> > > 2. The solution of chaanging back_ptr's, which is rather complicated, DOES 
> > >    indeed solve EVERYTHING, but raises complexity of muxer greately, and 
> > >    for reasons I'll not detail here, makes it possible to have 2 subsequent 
> > >    syncpoints with no frame between them.
> > > 3. Give up fullfilling the promise of "have an index, then no more than a 
> > >    single file seek to seek to position". I highly dislike this solution.
> > > 4. Something else out of the box. Maybe go back to old solutions - keyframe 
> > >    index. (If nobody remembers, the probably with keyframe index is that 
> > >    you simply cannot seek to arbitrary position in file, only to 
> > >    syncpoints, because you need "last_pts" state information)
> > > 
> > > I vote for 2. It's the "ideal" solution as it always does the right thing.
> > 
> > Sigh, wrong again, I found a situation it breaks.
> 
> elaborate please ...

I can't remember. :/ I think it was something like this:


S2 ... K1 .. S3 .. K2 ......<2mb>.... S1 .. P

P is the PTS I want, S2 is the syncpoint pointed to by S1. It is supposedly 
a very very far distance from S1 to S2, 2mb or something. S3 is the 
syncpoint immediately after S2.

S1 is pointing to S2 and not S3 because the pts of the second keyframe is 
too high. The correct keyframe to be chosen here K2, as it's the closest
such to P. (S1 < K2.pts < P)

I go to S2, linear search until S3, find a single keyframe. I have 
absoloutely no idea if there are more keyframes until requested PTS unless 
I continue linear searching... You have to linear search the entire 2mb 
region to be sure, which was exactly the situation we were trying to avoid.

You can't even stop when you reach max_distance from K1, cause by then 
you'll find K2, and then you have to keep going until you reach 
max_distance from K2, and so on. I don't see a solution for this.


This solution is overcomplicated and makes a compliant muxer harder to 
write. When I thought it was the only viable solution, I voted for it, but 
I now like the "pts per stream" idea much much better. It is much simpler, 
and I've yet to find a flaw in it except overhead, and I think it might be 
possible to reduce that. The steps to find the syncpoint you want:

1. binary search for syncpoints or search the index, find the LAST 
syncpoint, where the pts of all ACTIVE streams, is lower than your 
requested pts.
2. Pick the lowest back_ptr of the ative streams
3. linear search at most max_distance, from the keyframe, between the 
back_ptr'ed syncpoint, and the syncpoint right after it, which is at most 
max_distance*2.


Few things I'm having trouble with this idea is still the overhead, and 
deciding what to reset the pts of all streams to.


- ods15