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

[Rich Felker]

On Thu, Jan 05, 2006 at 04:04:17PM +0200, Oded Shimon wrote:
> 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..

I have said this many times and Oded you keep ignoring it or latching
onto the reasons that DON'T matter so much, then making me look like a
fool..

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

Strongly oppose!!!! There is no gain and seeking is broken. You
couldn't even figure out which timestamp is correct to use without
relying on mts which we've all agreed is broken!

> mostly thinking for video editors when he brought it up, and now that I 

No, I was thinking of the original reason for having pts: being able
to seek to any pts in any stream!

> think of it, they will most likely use intra only codecs anyway. As for 

This is the past. With good formats with exact seeking you're free to
use non-intra-only codecs for editing and save a damn lot of space!

> 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 

ROTFL! Exact seeking in audio means within 1/40 second, not 3 seconds!
3 seconds in a song is horribly off and it's just like ogg shit!!

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

Nonsense! This is O(keyint)!!!

Look, I've compromised on lots of stupid things I wanted at one time,
like mts, perfect interleaving, ... and I'm even willing to compromise
on the one-index rule as long as the index at eof is mandatory
whenever any index is included. However this is one thing I'm not
willing to give up in NUT. I don't want another shitty format where
you request a seek to 15 seconds and you get 17.4 seconds. We already
have that brokenness with ogg! We have a chance to do this right for
once, and I don't want to go and ruin it.

If anyone thinks the overhead is too much (and I really don't see how
it could be since it's less than the stated goal by far!) then we can
work out a more advanced way of storing the necessary info and bring
it back down. But IMO it's not worth it.

Rich