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

[Michael Niedermayer]

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
it makes seeking slow ill fork nut and fix it
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


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

original means when i added that 10k line


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


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


> 
> Yes the index is a lot bigger, but it was never small. 

false statement


> The current index is 
> completely useless, 

false statement


> 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


> need last_pts context. The only hope for a small index is a collapsed 
> syncpoint index, 

false the original index was <10kb and wasnt a collapsed syncpoint one


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

[...]
-- 
Michael