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

[Michael Niedermayer]

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


[...]

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

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


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


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


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

[...]
-- 
Michael