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

[Michael Niedermayer]

Hi

On Mon, Jan 09, 2006 at 02:44:42PM -0500, Rich Felker wrote:
> 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.

disagree strongly, this is like having a single bug not break a whole html
page, you know where that lead to ...
and you also contradict yourself, you said you want to make the spec hard to
violate so why now allow a broken stream?


[...]

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

seekaility to what? audio with green video?


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

this is false the original index didnt behave that way as it didnt conatain
all keyframes, i remember that you strongly wanted that but i repeatly
rejected it, my index definitly did not behave this way


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

i have to agree here, maybe it was a bad idea


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

well IMO you dont need to understand the details to vote, its about the
effects for the end user not if the details match your philosophy of
how it should be done


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

i disagree i think the overhead is O(n) not O(log n) but that might
be proofable if you think otherwise


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

and your system has a problem too, you wont display half of the
streams after seeking (subtitle streams for example)
now most solutions to this will make per stream ptrs&pts obsolete
IMHO

[...]
-- 
Michael