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

[Oded Shimon]

On Thu, Jan 05, 2006 at 02:42:09PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Thu, Jan 05, 2006 at 01:20:27PM +0100, Luca Barbato wrote:
> > Oded Shimon wrote:
> > >
> > >pure numbers:
> > >
> > 
> > [snip]
> > 
> > >
> > >with 2 subtitles streams, in the high bitrate file, you have 997386 bytes 
> > >overhead not including index. The spec says:
> > >~0.2% overhead, for normal bitrates
> > >That's 1.5mb for this file, so I'd say we're still doing better than even 
> > >our goals say. (Index will certainely not be 500kb..)
> > >
> > 
> > The demuxer works as expected? How many cycles uses for decoding, less 
> > than mkv? If yes I'd move to other questions, since the target is reached.
> 
> wait a second, the goal is 10kb/hr index not 500kb read mpcf.txt
> and neither per stream back ptrs nor pts are needed for the goals either
> they become neccessary after the new optimal seeking requirement was added
> and even then i doubt the per stream pts are really needed
> 
> what does the _end_user_ gain from that requirement in practice?
> furthermore that requirement is not part of the official nut spec i never
> agreed to it, it was never disscussed, ...

Hmm..

> furthermore we havnt thought about error resistance of these features its
> part of the goals, and being ignored entirely
> what if a the pts or back ptrs are damaged? how do we ensure recovery of
> the demuxer?
> 
> i really dont want to flame but every few month iam being confronted with a
> new set of 3-5 requirements which are absolute and undisscussable and which
> nut must conform too while everything else is not worth even mentioning
> 
> first it was 1pass no buffering, strict dts, absolute minimal overhead,
> absolute no redundancy to avoid inconsistant files, ...
> now its optimal seeking, 1pass (dunno if the strict no buffer rule was droped?)
> dts ordering and overhead doesnt matter at all anymore, ...

Well, you miss all the IRC convos where most of this takes place. :)

Looking back at it all now, I think you are right, we should go back to 
single back_ptr, "percise optimal seeking" isn't all that useful, Rich was 
mostly thinking for video editors when he brought it up, and now that I 
think of it, they will most likely use intra only codecs anyway. As for 
music videos, I found that "keyframe percision" is actually very high, 
I've never had a nut seek going more then 3 seconds off target. (with 
single back_ptr). Single back_ptr is still necessary IMO, because otherwise 
using NUT for video editing is impossible altogether. BTW, given this, the 
rule for syncpoint pts is using the max keyframe pts across all streams, 
this is the only correct way for doing it (and without global timebase at 
all, we should still use coded_pts). The index is the old syncpoint index I 
proposed - those with a common back_ptr can be removed, making a tiny 10kb 
index per hour. The nice pro to all this, I already have the demuxer fully 
implemented. :) The biggest thing I still hate with back_ptr - subtitles. 
(As in, any stream with gaps.) back_ptr will be huge and useless, and EOR 
can't really be enforced, it is merely a hint.
One semantic thing about index collapsing syncpoints with common back_ptr - 
the pts used for the collapsed syncpoint is the pts of the first syncpoint.

Those who want real percision will just have to linear search the back_ptr 
region.

I'll make a new patch to mpcf later. :)

- ods15