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

[Oded Shimon]

On Mon, Jan 09, 2006 at 07:12:09PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 09, 2006 at 04:41:54PM +0200, Oded Shimon wrote:
> > On Mon, Jan 09, 2006 at 01:11:19PM +0100, Michael Niedermayer wrote:
> > > On Mon, Jan 09, 2006 at 12:37:36PM +0100, Michael Niedermayer wrote:
> > > > On Mon, Jan 09, 2006 at 12:24:29PM +0200, Oded Shimon wrote:
> > > > > Index still needs improoving. I want this committed...
> > > > 
> > > > iam against reseting the tmp_* variables, the per stream pts in the
> > > > syncpoints and index, the removial of the index repeation possibility
> > 
> > BTW, you do notice that index repetition is not allowed anywhere in the 
> > spec? I just removed it from the goals, but as long as I've known it, the 
> > spec never allowed any kind of index repetition.
> 
> 1.61 allowed it at least

That's beyond my time. :) The earliest NUT discussion I recall was 
"distributed index" you suggested, and I wasn't even interested in NUT then 
so I didn't read it...

> > As for vote, my vote is to per stream pts and ptr in every syncpoint.
> > 
> > Pros:
> > 1. Actually adds a point for storing pts for every frame, without this you 
> > might as well do lacing like a bunch of other formats...
> > 2. Much simpler in all aspects, having all data to work with makes it easy 
> > to do things without hacks.
> > 3. Have high percision seeking in files regardless of additional streams.
> > Weird streams like subtitles, info streams and user data streams have no 
> > effect.
> 
> no effect? every ignored "no effect" stream will not be shown correctly
> either, that might be nice for you and rich and a few other hackers and 
> geeks but the normal end user doesnt disable streams at random
> if theres a single "weird" one the file is pretty much broken, per stream pts
> hides this from thouse who dont need that stream, so for example if the
> english subtitle stream is stored in a single keyframe at the begin of
> the file everyone who understands the native language will be happy
> but everyone who doesnt wont be with the per stream pts, with a single
> pts+ptr noone will be happy and the file wont spread ...

IMO That's backwards. If the idiot translator messed up the subs, that's no 
reason to ruin the entire file. Also most likely you won't even have the 
subs set as an active stream even if you were interested in them, they'd 
just reduce acruaccy of seeking wildly, but if I really want to see the 
subs always, I want the ability to turn it on.
A single stream should not break the entire file...

Also, info streams can legitimately have very rare keyframes, though I 
think they still need a bit more thought. The only thing I have left on 
TODO for NUT after this long discussion is info frames/packets.

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

And, well, design decisions should not be affected (greately) by existing 
implementations. Rich and I already discussed this, and we decided as 
MPlayer G1 is built around AVI, MPlayer G5926 (not G2, not G3...) should be 
built around NUT. :)

> > Cons:
> > 1. Not quite the additional overhead itself, but the fact that the overhead 
> > is semi-linear to amount of streams. At the very least, each additional 
> > stream adds 1 byte per syncpoint, usually 2 or 3.
> > 
> > I think it's worth it. With 20 streams NUT is still more efficient that mkv 
> > (addmittedly not as much as it could be), and anything more than 20 streams 
> > is psychotic.
> > 
> > 10kb an hour was never a realistic goal for the index IMO... (And as I've 
> > said, with max_index_distance of 32kb, index really was 100kb. Only 2 cases 
> > it was 10kb an hour, with max_index_distance of 512kb, and with collapsed 
> > syncpoint index with single back ptr)
> 
> 10kb was a realistic goal and it was what the original spec would have used

Original do you mean what we have now? The spec currently suggests using 
max_index_distance of 32kb, which gives a 100kb index with audio and video 
for a 1 hour file. Also current spec is just wrong, see below.

> > I didn't want it to be a vote. Mostly it's just Michael, Rich, and myself, 
> > and Rich and I both vote for per stream stuff...
> 
> i think all mplayer developers should be able to vote,

Ya I agree, let's hope they'll actually notice the thread though :) I'll 
ask around on IRC to say their vote...

> 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...
As for overhead, it's more like 10% increase for the usual case (2 stream 
file, additional 70kb to 0.6mb overhead), and 100% only for 10 stream 
case... For 70kb for a 700mb file, as IMO there IS a gain, I say go for it. 

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 the index is a lot bigger, but it was never small. The current index is 
completely useless, as you can't start demuxing from a random spot, you 
need last_pts context. The only hope for a small index is a collapsed 
syncpoint index, which, as Rich mentioned, is bizarre as it decreases in 
size when you add more streams, that's just odd and abusable behavior.

> > However, I am more convincable and am more concerened on NUT being 
> > finalized and implemented, regardless of how or what it has...
> 
> lets hope that rich doesnt change his goals again before that happens
> or we will have to reverse all the work again, its interresting to
> note that a early version of the spec had per stream "syncpoints"
> with their own timestamps and IIRC (dont shoot me if i remember wrong)
> rich was the one who wanted this changed to the current system

lol, I don't think Rich has been that flakey with the goals, it's more the 
problem that we kept discovering problems while I was implementing 
libnut... Which is why ofcourse I insist I finish a complete libnut before 
we close the spec.

- ods15