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

[Michael Niedermayer]

Hi

On Mon, Jan 02, 2006 at 06:42:19AM +0200, Oded Shimon wrote:
> 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.

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


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

[...]
-- 
Michael