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

[Oded Shimon]

On Mon, Jan 02, 2006 at 12:57:30PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 02, 2006 at 06:42:19AM +0200, Oded Shimon wrote:
> > 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 ...

The precise goal Rich set:
When wanting to seek to pts P, caller will get from demuxer the absoloute 
last position in the file that fullfills being able to decode all ACTIVE 
streams for pts P.
This means for an Intra only active stream, the seeker will give the last 
frame that has pts <= P.
This means for a non Intra only active stream, the seeker will give the 
last keyframe that has pts <= P.

This means that having more streams in the file when they are inactive 
should not affect results whatsoever.
So, an interleaved audio-video file where the audio is Intar only and the 
video isn't, if the only active stream is audio, seeking will be PRECISE.


I generally agree with all of these goals. However, if we find that there 
is simply no good solution, I personally am willing to give up the "give 
last possible position for this" part, as in, rewinding too far back is OK. 
I've not given up yet.

The small addition I have to the goals:
If there is an index, promise that no more than a single file seek are 
necessary for seeking to pts.

I will not give up this goal.

> > 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'm pretty lost by what you have said here?...

A single back pointer CAN work, but only if you linear search the ENTIRE 
region it is pointing to, which can be 2 or even 10mb. And to fullfill my 
index promise, you'll also need to CACHE that, which is additionally 
insane. The basic problem with a single back pointer is that there is no 
way to avoid it sending you too far back.

I'm 99.9% sure that my "pts AND back_ptr per stream in syncpoints" idea
fullfills ALL the goals, with small muxer and demuxer complexity. It comes 
with the obvious price of overhead. However, I'm not really sure if the 
overhead really will be that bad. I even have a feeling it will be similar 
overhead to what we have now if it is designed right, however only for the 
simple 2 stream case. With this idea, low overhead for large amounts of 
streams is hopeless.

Do you have any brilliant ideas for low overhead coding for this idea?

- ods15