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

[Michael Niedermayer]

Hi

On Sun, Feb 26, 2006 at 11:58:24PM -0500, Rich Felker wrote:
[...]
> > * error recovery tested (playback, seeking with and without index, dealing 
> >   with damaged syncpoints, main header, stream header, info packets/frames, ...)
> > * systematic errors (zero or 0xFF runs) tested
> 
> Oded has been doing some of this. The extent of testing I do not know.

oded, can you post the testresults / some summary?


> 
> > * various decode delay cases (h.264 b pyramid) tested
> 
> ..? What is there to test here?

does the passing of decode_delay from encoder to muxer work? from avi-demuxer
to nut-muxer? not a an issue for the spec i agree but still has to be checked
and fixed eventually


> 
> > * extendability of all headers tested
> > * tested nut over http, ftp, cdrom
> 
> > * wait 1-3 month at least where noone finds an issue and no changes are done
> >   if some change has to be done reset the timer
> 
> This is nice in principle but no one will use a non-final spec and
> thus no testing will happen. :(

hmm, wherent there some people (matroska devels?) who implemented their own
nut (de)muxer


> 
> > * testing support for various codecs 
> > * publish all test-results
> > 
> 
> > some specific issue iam aware of
> > 1. metadata which becomes known after the time to which it applies cannot
> >    be stored in info streams, i already threatened to write a info2 
> >    extension if oded-rich info streams/packets end up with some silly
> >    limitations ...
> 
> I don't object to the existence of such data, but it's not
> stream-like. Violating the stream nature of a stream to store
> information that does not go with the pts of the frame is not a proper
> solution.

fine, maybe we should drop info streams then and go back to my original
system of storing info packets as needed, that was much simpler for both
muxer and demuxer, though it didnt conform to some arbitrary philosophical
goals, but IIRC the current system does neither?


> 
> > 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)
> 
> If you interpret the definition of frame for them as single samples,
> then yes. :) This has been discussed recently on IRC. A few ideas:

well, but that is the only senseable definition, a packet - the smallest
part which produces at least 1 output sample when feeded to the decoder


> 
> 1. PCM audio must be broken into frames smaller than 2 timebase units
>    for any timebase in the file. Naturally this is bad if some idiot
>    uses ridiculously small timebase; it may not even be possible to
>    satisfy.

this simply is making things more complex and doesnt solve anything


> 
> 2. PCM audio must be framed such that no frame entirely overlaps more
>    than 1 whole frame from any other stream.

umm, thats even more stupid, think about remuxing, you add some stream with
small frames, now you must re-frame all PCM streams .


[...]
> IMO PCM is already such a format that needs additional specification,
> since we need to specify the extradata format (or else many fourcc's)
> for all the different sample formats.

and ADPCM, mu-law, a-law, ... codecs? they all have very small packets

my suggestion:
add a packet_size field to the stream header, which is 0 if the size is
variable and add a rule like:
1 codec packet MUST be only in one NUT packer (=no splited packets)
1 NUT packet MUST contain exactly 1 codec packet if the NUT packet is larger
then 4kb or packet_size is 0

[...]

-- 
Michael