[MPlayer-dev-eng] Are you NUTs?

[Ivan Kalvachev]

2006/1/13, Michael Niedermayer <michaelni at gmx.at>:
> Hi
>
> On Thu, Jan 12, 2006 at 11:04:51PM +0200, Ivan Kalvachev wrote:
> > First I would like to excuse me if I miss something, but this thread
> > is too big to loose my time reading it as whole.
> > Second, some may think that this is a flame but I assure you it is not.
> >
> > So now in short. This syncpoint stuff is madness and must be removed.
>
> syncpoints itself are needed as some start point for decoding, so i assume
> you mean the complicated pts and back ptr stuff here

I'll call them seekpoints. I guess partial index points would be more
correct but... it doesn't sound good.

>
>
> >
> > As I said in irc, you are workaround an problems you had created while
> > trading off for smaller overhead.
> >
> > There is no need for syncpoints in the stream. The nut is designed
> > that it could work and seek without index, but there is no need to be
> > precise if there is not such. In fact syncpoints form an distributed
> > index.
> > It is much more simple to have that trade off:
> >
> >  no index, imprecise seeking
> >  index, precise seeking.
>
> personally iam not strongly opposed to this, but i doubt you will convince
> rich

I don't have to. You are the one in charge. Rich and I  have no other
options that to accept your decision.


> you also must keep in mind that precisse seeking isnt the same as optimal
> seeking, optimal seeking is something even more strict which rich wants
> its advantages are somewhat questionable

Would you explain that? The difference in not so obvious for me. (I
suspect ability to seek to any non-key-frame)

> for simple exact seeking the only thing you need is a single pts and back
> ptr per syncpoint the additional complexity here is negligible IMHO
> now if you start to add lots of rules things become tricky
> rich wants that no matter how large the keyframe interval on a single
> stream is, it should be possible to seek quickly and precissely to
> any keyframe of any other stream, for that you need multiple back ptrs
> per syncpoint
> IIRC still things are not terribly complicated, the real mess starts
> when you want some gurantee that you can find the rightmost keyframe
> which is prior to a user supplied timestamp in O(1) instead of finding
> it or a slightly earlier one in O(1) / finding the rightmost in O(keyint)

Somehow I still see that you are thinking for seekpoints. All these
things are complicated only if you have partial (local) data of the
surroundings.

NUT index is list of keyframes and their offsets for streams that are
not intra only. This means that the only addition that must be done in
order to make it precise seeking, is for every (of the above)
keyframes to insert information for corresponding intra frame in
intra-only streams.

At worst case this would double the index compared to the current one,
but in practise it would be much smaller as packets are close to each
other.

One of the goals for nut was that seeking must be possible without
index. And we had it. There is no goal for precise seeking with
multiple random streams without index. And it have questionable
benefits.

It is also questionable what good are back_ptr are? Sure they will
make sure that we will start decode before the requested pts. This
complicates the forward seeking as we must workaround the case where
seeking with small margin could lead that we turn back before current
position (cur=3, seek=+10, keyint=15,  in seconds) because we don't
know when next keyframe is!

Using back_ptr instead of forward_ptr also means that we will ALWAYS
have one more seek. Have in mind that as it is now we have one seek to
find index, one seek to interpolated location and one seek few bytes
back to get the keyframe, all of them for less than 1s. Just imagine
that we didn't get it right from the first try. (final result - ban
from http/ftp server for abusive reconnections and flood)

As of now, MPlayer just seeks to next keyframe, and this behaviour is
good enough. It is guaranteed it won't take more than keyint time (in
seconds) to get watching (once we get close enough pts).

If somebody wants something better then file _must_ have index. There
is no  reason to omit index as it is very small.

KISS

Make proper seeking with index and then come back to seekpoint mess.
Please.