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

[Luca Barbato]

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

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

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

Better keep just a window for incremental changes

> * testing support for various codecs 

see Rich comment about framing methods for peculiar codecs

> * publish all test-results

I'd say create a testcase

> 
> 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 need an example.

> 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

> 3. index is fragile, 1 byte damaged and its completely lost, writing the index
>    in the way its currently will require 2 passes, libnut always uses 2 passes
>    IIRC, but lavf didnt, the issue is that the forward ptr must be updated
>    if packets are small like they all should have been then thats no problem
>    with a small buffer but with the huge monolithic index its no longer 
>    possible

Could be addressed before

> 4. with the "info ends at the next other packet" rule we also have a
>    issue with timebases and it violates the 
>    "damaged files can be played back with minimal data loss" goal

Implementation/tuning related or must be addressed before the first spec?

I'd rather have a miniNUT finalized now, that covers most of the issues
and that could work fine in a good number of scenarios, than a omegaNUT
undefinitely later, that covers everything including coffee making...

lu


-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero