[MPlayer-dev-eng] FINALIZE NUT SPEC!!

Michael Niedermayer michaelni at gmx.at
Mon Feb 27 11:51:28 CET 2006


Hi

On Mon, Feb 27, 2006 at 11:29:57AM +0100, Luca Barbato wrote:
> Michael Niedermayer wrote:
> > * error recovery tested (playback, seeking with and without index, dealing 
> >   with damaged syncpoints, main header, stream header, info packets/frames, ...)
> 
> the current spec allows you to put lots of redundancy if you really want
> to be sure, so it is within the minor improvement/implementation range

correct, we implement, find a big issue and write NUT 2.0 ...
no, we really should have a working demuxer which can handle damaged streams
if thats too hard we have made a misstake in writing the spec


> 
> > * systematic errors (zero or 0xFF runs) tested
> > * various decode delay cases (h.264 b pyramid) tested
> > * extendability of all headers tested
> > * tested nut over http, ftp, cdrom
> 
> All could be handled within the frozen spec.

fine, but then the steps should be:
1. fix known issues
2. freeze
3. test everything and goto 1 if needed
4. make NUT 1.0


[...]
> > * publish all test-results
> 
> I'd say create a testcase

reference bitstreams which test all the special cases, and types of damage
yes, IMHO every nut demuxer must be able to recover at least somehow from
a damaged stream


[...]

> > 2. PCM/ADPCM and other very small and constant sized packet codecs
> >    have huge overhead (50% or so) if stored in a spec compliant way, we 
> >    need to add something like Fixed-size lacing (AVI, MOV, MKV support that)
> 
> they have to be framed and framing specs could be outside this round

yippi, nut will need framing like shitty ogg & mpeg, ill go and use avi that
at least didnt need this mess

[...]

-- 
Michael




More information about the MPlayer-dev-eng mailing list