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

[Michael Niedermayer]

Hi

On Mon, Feb 27, 2006 at 01:16:52PM -0500, Rich Felker wrote:
[...]
> > > > * 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.

make reference bitstreams and specific seek commands and what needs to be
recovered at minimum and what needs to be detected and discarded at minimum
this could easily be tested by simply writing frame counts into the frames 
so that <nut framecode>00 00 01<nutframecode>00 00 02<nutframecode>00 00 03


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

AVI does NOT allow this, its only broken windows encoding apps which do it
probably mostly because LAME outputs a totally invalid randomly cut mp3
stream which must be passed through a framer before it can be muxed in 
anything except mpeg-ps/ts

the AVI docs say:
"dwSampleSize 

Specifies the size of a single sample of data. This is set to zero if the samples can vary in size. If this number is nonzero, then multiple samples of data can be grouped into a single chunk within the file. If it is zero, each sample of data (such as a video frame) must be in a separate chunk. For video streams, this number is typically zero, although it can be nonzero if all video frames are the same size. For audio streams, this number should be the same as the nBlockAlign member of the WAVEFORMATEX structure describing the audio.
"

[...]
-- 
Michael