[MPlayer-dev-eng] Are you NUTs?

[Rich Felker]

On Sun, Jan 15, 2006 at 05:23:43PM +0200, Ivan Kalvachev wrote:
> > > 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.

.....

We're in this together. If one of us starts just making decisions that
disregard everyone else's opinions, NUT isn't going anywhere because
only the one person who made the decision will be promoting,
advocating, and using it....

BTW when I saw "we" I'm referring to myself, Michael, Oded, Alex, and
the other people who are still actively workin on NUT, not people who
just flame us all the time without contributing anything to solving
the problems...

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

No, it just means the difference between what MPlayer does and what a
correct player does.. ;)

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

Huh? You want to make the index much larger and no more useful? The
index problem is already easily solved. It's the syncpoints that are
the difficulty.

BTW index pointing to _frames_ is useless since you cannot decode a
frame without the prior syncpoint. (Not entirely -- you could linear
search backwards for the syncpoint but this sucks...)

> 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

We did? It wasn't remotely correct before back_ptr was added..

> multiple random streams without index. And it have questionable
> benefits.

I have outlined the benefits many times. Perhaps you didn't RTFml. All
the other reasons aside, personally I think it's very stupid and
primitive for seeking to behave differently with or without index.
Index should just be an aid for improving performance, not something
essential.

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

No, it doesn't complicate things whatsoever. "Forward seek" is easy:
if seeking would put you backwards, just skip to next keyframe in the
forward direction. This has nothing to do with the container
whatsoever; it's an operation at the player level that works for all
containers. At the container levels, a "seek" should obviously be
defined as "latest seekable [keyframe] point before the requested
timestamp".

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

Nonsense; you don't have to do this with the index. Oded has worked
very hard to make sure that you never have to do more than one media
seek if you have an index. You don't seek to the syncpoint to get the
back_ptrs if you have an index; you can derive them from the index
itself!!

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

......

I think the fact that you've cited MPlayer's abysmal seeking behavior
as "good enough" pretty much nullifies the validity of any comments
you make about seeking quality.

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

Nonsense. The file may be an in-progress download or a live stream
being saved to file and played at the same time (think PVR). Warezed
movies on your ISP's warez ftp/http server are not the only purpose of
a media container format....

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

It's already done if you bothered to read rather than flame...

Rich