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

[Oded Shimon]

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

Very very basic tests, I just filled some parts of the file with 0x00, 
played them, and libnut skipped over (and seeked over) the damaged area 
beautifully. The only flaw was, in very big damage chunks, I was not able 
to seek back before the damage. Everytime I tried to, i ended uip right 
before the damage, and the immediately right after. (The biggest seek in 
MPlayer is -10 min, the damage was bigger)

Also I want to improove speed, everytime I seeked back the damaged region 
when reaching it again it linear searched the entire ~200mb of damage 
again...

The current libnut capabality is, simply, when it detects any kind of NUT 
error (invalid frame code, out of order dts, max distance, max pts 
distance, bad crc), stop demuxing, seek back to right after the last seen 
syncpoint (if possible), and linear search until a syncpoint is found.

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

Well, I don't see how this is relavent to spec freezing though. nutmerge is 
certainely not ready for this because it is currently very hackish and just 
barely enough to properly mux mpeg-4 asp from avi.

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

I never heard of this? The only nut de/muxers I'm aware of are libnut and 
lavf.
BTW, you said libnut uses 2 pass. It doesn't, output is even pipeable. 
(Headers are built in memory, then forward ptr is written and then headers 
are copied.)
I did just 2 days ago write a util 'nutindex', which copies the index of a 
NUT file to the begginning of the file, also modifying the index to make it 
right. (you could call this 2 pass) libnut reads the index perfectly from 
begginning of file using no seeks... The only big disadvantage is the 
"shifting" of all the 2^n main header copies so they are not perfectly 
after 2^n, but ~80k after it...


I object to index splitting because it is unnecessary complexity for very 
very rare occassion - partial damage in a 80kb chunk in a seekable stream.
Now you can copy the index anywhere, it's even more unnecessary...

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

The big problem I have with just info packets is that there's no way to 
really load them because they can be in any arbitrary location. Like we 
restricted the index being only after main headers and not any arbitrary 
location so demuxers can find it, same with info packets...


Regarding my "premature" e-mail, the intent of the mail was not saying "I'm 
locking it right now", it was "I want to lock the damn spec already after 
it's been just sitting here for years, does anybody still have issues, say 
them now". And it worked, you said some issues that still trouble you...

- ods15