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

[Rich Felker]

On Mon, Jan 09, 2006 at 09:18:13PM +0200, Oded Shimon wrote:
> 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...

Agree strongly.

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

Yes..

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

Yes.

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

It's realistic in the sense that, if you _only_ want to index video
keyframes, and they come once every 3 seconds, you have 1200 keyframes
per hour and thus less then 10kb of index.

However common this case is, I don't see the value in making ugly
hacks (omitting most of the seekability) just for the sake of making
index overhead tiny in one special case. Every other case (intra-only,
audio files, etc.) will have at least 100-200kb of index.

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

I disagree. Voting is a way to get people pissed off at one another
rather than reach consensus, and I really doubt most of the developers
have even followed this or know or understand the differences. I know
one developer who will just vote whichever way he thinks will make NUT
suck, out of spite...

> > even though iam
> > aware i will loose, rich is much better then me at convincing people

I'm not going to go around twisting people's arms and trying to
convince them to vote in my favor. I'd rather not even have a vote.

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

Yes.

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

Hundreds of streams is rather stupid.. BTW, overhead already increases
as O(log n) anyway because of space needed to store stream number. IMO
the overhead for pts/backptr can be closer to O(log n) too if it's
compressed well and exploits the redundancy between streams.

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

Yes, and it will be abused, even if unintentionally.. :(

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

Exactly. No one had ever written before a proper definition of
seeking. And as I was too lame to work it out right from the
beginning, we kept discovering problems and refining it..

Rich