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

[Oded Shimon]

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.

> > and increasing the index overhead by a factor of 10 without a clear
> > advantage for the end user
> > 
> > if we cant agree maybe we should do some voting on the per stream pts
> > which are the main point of dissagreement?
> 
> or what about the idea oded had, IIRC that syncpoints have only one
> ptr & pts and the index has them per stream?

I don't really like this solution as it raises complexity, makes seeking 
with and without index wildly different. (Choosing the pts alone for the 
back_ptr prooved to be a worthy problem)

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.

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)

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

However, I am more convincable and am more concerened on NUT being 
finalized and implemented, regardless of how or what it has...

- ods15