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

[Michael Niedermayer]

Hi

On Sun, Feb 26, 2006 at 02:17:22PM -0500, Rich Felker wrote:
> On Sun, Feb 26, 2006 at 06:26:16PM +0100, Alexander Strasser wrote:
> > Oded Shimon wrote:
> > > The info frames patch I just sent to nut-devel is the last withstanding 
> > > problem I know of for NUT. libnut seeking has been rather heavily tested, 
> > > even with EOR. We could still add (remove?) some fields for Info 
> > > packets/frames, but that can be done after finalizing.
> > > 
> > > libnut/nututils is far from ready for production, but I think mpcf.txt 
> > > _IS_.
> > > 
> > > Is there anything else? Is anyone displeased? (even Ivan is happy and 
> > > stopped flaming! :)
> > 
> >   WTF! Ivan, where are you when you are needed :(
> >   
> >   Anyway nice that you decide it is locked, i am looking forward to
> > my own NUT fork.
> 
> WTF, I hope you're kidding...

i thought the same when i read that "NUT is locked speak now or be silent 
forever" right after some large changes and before any of the following 
have been done
* 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
* various decode delay cases (h.264 b pyramid) tested
* 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
* 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 ...
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)
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
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


summary of MHO
there are issues left which will some time to fix and
then 1-3 month should pass before locking, that assumes no new issues are
found in that time which is unlikely

[...]

-- 
Michael