[MPlayer-dev-eng] NUT, what's left

[Oded Shimon]

Well, as most of you probably know I've been working on my own 
implementation for NUT for the last few weeks.

Well, it umm, works, but it's obviously not as good as it can be.
First of all, I'd like to address what's left regarding the spec, when you 
guys finally friggin finalize the spec, I can make a release.

1. backwards pointers in syncpoints
2. DTS method (MN rule or MTS?)
3. info packets... how should they be used at all
4. subtitles, i want a more strict definition for them.. (they require info 
   packet?)
5. what should max_index_distance be, Rich says 32k is too small and should 
   be 512k.
6. possibly remove the "GPL" code in there as that seems to scare some very 
   weird people (or just make it public domain).
7. Zero byte frames in the end.
8. Anything else?

Now, some happy news regarding my implementation:

1. It actually muxes! Given valid input, it creates a valid NUT file.
2. It actually demuxes! Given a valid NUT file, it gives perfect frames.
3. It actually creates NUT files! The nutmerge util takes an AVI and 
   creates a real NUT file.
4. It has less overhead than mkv in every test I gave it! Half the overhead 
   really.
5. It actually plays! With demuxt_nut.c, you can use libnut in MPlayer, 
   quite flawlessly too.
6. It actually seeks! I can actually seek back and forth in the file with 
   MPlayer.

However, it sucks in quite a few places. In order of importance:

1. The "nutmerge" util is very very bad, it generates invalid nut files.
   It doesn't consider B frames at all, and it doesn't work with PCM audio.
   Obviously, it only supports AVI...
2. The write_frame_reorder wrapper which reorders frames to conform to dts 
   rule is extremely wasteful, memcpy's and mallocing every chunk it gets.
3. It seeks, but in a very braindead way, it just uses the index of the 
   first stream disregarding all others.
4. There's absoloutely zero error recovery, you can feed the demuxer 
   /dev/urandom and it wouldn't know!
5. There's still no info packets stuff in the demuxer.
6. The muxer uses a single constant frame code table...
7. The API probably sucks, as I've never dealed with such stuff before...
8. demux_nut.c for MPlayer is quirky and hackish...
9. FIXME's, TODO's and ###'s all over the place. :)

- ods15