[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