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

Michael Niedermayer michaelni at gmx.at
Thu Jan 5 14:42:09 CET 2006


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

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

[...]
-- 
Michael




More information about the MPlayer-dev-eng mailing list