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

[Rich Felker]

On Mon, Jan 02, 2006 at 12:57:30PM +0100, Michael Niedermayer wrote:
> > 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.
> 
> i dont see a problem, you just have a keyframe earlier then the one you wanted
> you must decode the following frames until the matching pts anyway to reach
> the ideal frame, this is always too slow in practice (~10sec for 300frame GOPs)
> i think you should _FIRST_ specify the goal of what should be possible in nut
> then think if there is a solution for the given constrains and then think of
> the details, the way its currently done is that we have a set of constraints
> which probably have no solution and by constantly droping things which fail
> one of these constraints we will never get anywhere, both complexity and
> overhead increase ...

I'm willing to consider changes to the requirements, but I want the
syncpoint rules to be such that the result of a seek is independent of
the placement of syncpoints as long as the syncpoint placement is
legal.

Seeking to the latest point such that all streams will be synchronized
by the time demuxing reaches the requested timestamp is the most
natural constraint for this, but if people have other suggestions I'm
willing to listen.

However, IMO it's extremely bad if you seek back a whole gop further
than you need to, because gops are so damn long! In a player (or
editor) that implements frame-exact seeking via seek-and-decode, it
will at least double the time taken by the decode portion, and could
increase it by over 400 times in the worst case!

> > 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:
> 
> personally iam much more liking the idea of droping multiple backpointers
> and store a single one per syncpoint, i still have great doubt about the
> advantages of multiple ones, you at least need 2 streams with large keyframe
> distances, but this already means large distance in bytes and that simply isnt
> possible on slow media, not to mention large distance might mean lots of time
> to decode to a common timestamp ...

I really think the problem is hopeless with only a single backptr.

Rich