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

[Rich Felker]

On Mon, Jan 09, 2006 at 08:56:28PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 09, 2006 at 09:18:13PM +0200, Oded Shimon wrote:
> [...]
> > > then theres the issue that players probably wont support inactivating streams
> > > which will lead to very different behaviour with what i call broken files
> > > and its also unlikly that (m)any players will support optimal seeking,
> > > mplayer at least would need to be rewritten for it to be possible as far
> > > as i can see, actually any player which uses float, double or a common
> > > ms/ns timebase for seeking cant do optimal seeking, now which players
> > > could support this without a rewrite? xine? vlc? ...
> > 
> > MPlayer's demux_nut.c will probably just use only audio and video streams 
> > as active streams.
> 
> lavf will have sub streams active too, i see no logic reason why not and if

Certainly they shouldn't be active if the user doesn't want to see subs..

> it makes seeking slow ill fork nut and fix it

It doesn't make seeking slow with our method. See pros and cons below;
with our method seeking is always fast regardless of which streams are
active.

> note, iam sure the end user _does_ care about seeing the subs after seeking
> while she probably wont care much about a little overhead or seeking to the 
> "optimal" point

Again this is optional. Usually I couldn't care less about seeing the
subs after seeking, but I know many users would like to and sometimes
I want to as well. In most formats other than NUT, it's not even
possible to show the subs immediately after seeking without an
unbounded backwards linear search, so I'm used to not seeing them.

> > > even though iam
> > > aware i will loose, rich is much better then me at convincing people
> > > i just dont want to agree to a 30-100% increase of the overhead, and 
> > > 1000% for the index without any gain for the end user
> > 
> > At least say "with little gain", it's certainely not without ANY gain...
> 
> sorry, its "with little gain"

Yes. Please don't get angry with Oded for slight inaccuracies in his
evaluation of stuff either. We've all been making mistakes.

> > The only thing that bothers me about the overhead is that it keeps growing 
> > when adding more streams.. NUT will not easily scale to hundrends of 
> > streams, but that's just insane in it's own level.
> 
> yes, noone will ever need more then 640k streams, hmm wait it was somethin else
> i think ...

Obviously you'll have high overhead if your nut file has 640k streams.
:))) However you CAN make it.

BTW in this case you'll probably want to increase max_distance, unless
all but 2 streams are subtitles. max_distance can in general be set
proportionally to the i/o speed that would be needed to play the file.
If it takes 10meg/sec reads to play a file, then max_distance might as
well be 1meg or more, and then the overhead is irrelevant.

> > as you can't start demuxing from a random spot, you 
> 
> you can as soon as you reach the next syncpoint, your div8 pos cant start
> exactly where it points either and also must first find the start of a
> syncpoint i really hate that most of your arguments against my suggestions
> apply to yours as well

Oded's point was about the index pointing to keyframes rather than
syncpoints. There's no use in pointing to keyframes because you can't
interpret the packet header without the prior syncpoint.

> > which, as Rich mentioned, is bizarre as it decreases in 
> > size when you add more streams, that's just odd and abusable behavior.
> 
> its becoming increasingly difficult to disscuss nut with you 2, your arguments
> are so idiotic, "bizzare" "odd" "abuseable" bah, why not compare the
> advatages and disadvantages for the end user?

I'm sorry you're getting irritated, but as the end user, I care about
correctness. It pisses me off when I use -ss X and end up at timestamp
X+-not_so_small_delta. Maybe other users don't care about this, but
then again they probably don't care about overhead either, especially
when it's way smaller than AVI and somewhat smaller than MKV.

Anyway advantages for the end user were not the original goal of NUT,
at least not _directly_. Many of them were things like simplicity of
the implementation (which leads to the ability to support the format
in a wide variety of tools and players, which is good for users),
correctness (correct timestamps everywhere), etc.

Here is my summary of the pros and cons of both methods:

"Full seek info" (me & Oded's method)
- moderately larger overhead but still smaller than mkv or
  anything else
- correct seeking is fast
- muxer and demuxer are easy to implement and small

"Limited seek info" (your method)
- extremely low overhead
- approximate seeking is very fast
- accurate seeking is very slow, even with index
- demuxer implementation is somewhat more complex
- muxer implementation is possibly much more complex, depending on the
  rules used for assigning timestamps to syncpoints which in turn
  affect the efficiency of seeking

If you feel that these are inaccurate or unfair, please explain. It's
not my goal to flame.

Rich