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

[Rich Felker]

On Mon, Feb 27, 2006 at 03:43:52PM +0200, Oded Shimon wrote:
> 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)

The bug is an MPlayer bug, that it doesn't immediately process a
second keystroke after the seek. If it did this before attempting to
play anything, the problem would be fine as long as you hit the second
keystroke during the seek.

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

This might be desirable in the case of an incremental download, but in
general it's probably good to cache known bad regions.

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

This sounds correct.

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

It's a known issue that remuxing from a broken container that lacks
all the critical information (pts, delay, etc.) into NUT will require
a framer. This is the price you pay for correctness. If NUT didn't
contain additional critical information that AVI lacks, we would just
shut up and use AVI...

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

I tend to agree. If one sector of the index is broken it's likely that
many are. And if the index is unusable, it's not the end of the world.
Just seek without index or rebuild the index.

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

Global (chapter_id==0) info would still be required to be with
headers, and users would have to put any other chapter info they
wanted to be globally available with the headers too. Storing it other
places would just be for streaming purposes.

However, for many streaming applications, you need the full power of a
stream to represent realtime data reasonably. So even if we allow info
packets at places other than with headers, I still want info streams.

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

:)))))

Rich