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

[Rich Felker]

On Mon, Feb 27, 2006 at 11:51:28AM +0100, Michael Niedermayer wrote:
> 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

Well there's only so much amount of damage you can handle. People
using very critical applications may want to put a syncpoint on every
frame, or make all framecodes except one invalid, etc. I think this is
what lu meant.

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

Oded wants to have NUT presented at LinuxTag, and I agree that this
would be highly desirable if we can do it. But I also agree that his
email was premature and that we need proper testing, and that there
are still issues and disagreements to address.

Let's try to do both and see how it goes..

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

Yes. IMO minimal level of recovery should be something like this:

For all demuxers: upon encountering damaged data, resume demuxing at
the next valid syncpoint in the bitstream (i.e. treating a valid
syncpoint as part of the corrupted region is non-compliant).

For demuxers with seek-to-time: if the data at the destination time is
damaged, seek to the latest valid syncpoint before destination time.
This is the natural behavior that falls out anyway.

For demuxers with seek-forward: if the data at the destination time is
damaged, seek to the first valid syncpoint after destination time.

Naturally with sufficiently high level of damage, all conditions are
impossible to satisfly. For instance if you only have 1 disk sector of
the original NUT file, and the rest of the file has somehow been
overwritten with sectors from another valid NUT file, there's no hope
of being able to play the 1 'noncorrupted' sector. :)

Hopefully we can find a formal way to specify under what conditions a
file should still be playable.

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

Huh? Any good container needs to have interleaved streams, and for
that you need some kind of framing. Most codecs inherently provide
frame boundaries by virtue of the smallest unit of data they can
decode. For codecs that don't have this notion, I don't see how a
supplemental spec is bad as long as it's flexible and doesn't limit
you from doing anything sane. (Storing the whole audio track in one
frame is not sane..)

As for AVI and its lack of frames, it totally sucks because you can't
even cut a file without having a framer in your cutting app to parse
the audio frames from the randomly-split AVI packets..

Rich