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

[Rich Felker]

On Sat, Sep 17, 2005 at 09:09:15AM +0300, Oded Shimon wrote:
> Well, as most of you probably know I've been working on my own 
> implementation for NUT for the last few weeks.

Yes and it only partly sucks. :)
I'm impressed.

> 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

Hopefully we'll agree on how to add this. IMO Michael's idea is fine.

> 2. DTS method (MN rule or MTS?)

Or old dts rule with some kind of exception for 0-byte packets.

> 3. info packets... how should they be used at all

Yes.........

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

Not necessarily 512k, but 32k is definitely bad. It will result in
almost every audio frame being indexed. Maybe the indexing rules
should be changed.

> 6. possibly remove the "GPL" code in there as that seems to scare some very 
>    weird people (or just make it public domain).

Yes, some people are apparently scared of being "tainted" by reading
GPL code in the spec. IMO the spec should not contain GPL code; the
code should either be BSD/public domain, or removed, or replaced with
pseudo-code that doesn't look at all like C so people don't fear
"taint"..

> 7. Zero byte frames in the end.

Zero byte frames midfile to indicate "nothing"?
The idea is that a zero-byte frame signals the end (duration) of the
previous frame without beginning a new frame.

> 8. Anything else?

Not sure..

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

But not any AVI file, just ones without B frames. And it probably
makes invalid NUT files (silently) if you give it a file with B
frames.

> 4. It has less overhead than mkv in every test I gave it! Half the overhead 
>    really.

Excellent!

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

Only with index.

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

Yes.

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

IMO it's not really a big deal. Ideally the API should have the caller
manage the buffers and allow libnut to keep a lock on a buffer until
it's actually written to the file. A default implementation of this
buffer management could just do the wasteful malloc & memcpy.

However (!!!) probably no one cares about performance for muxing.

> 3. It seeks, but in a very braindead way, it just uses the index of the 
>    first stream disregarding all others.

The player should select which stream it wants to base its seeking on.
Also it needs to be possible to select whether you want to round up or
down when seeking (next keyframe or previous keyframe before the
destination timestamp) and whether you want a keyframe or just any
frame.

> 4. There's absoloutely zero error recovery, you can feed the demuxer 
>    /dev/urandom and it wouldn't know!

Not quite.. It will never find the main headers..

> 5. There's still no info packets stuff in the demuxer.

Because the spec isn't clear on what to do.. :(

> 6. The muxer uses a single constant frame code table...

Yes, very bad. The caller should have (at least) 4 options:
1. Let the muxer build a framecode table based ONLY on the mandatory
   information needed for muxing (number of streams, types, ..)
2. Provide additional hints to the muxer (typical frame size range,
   typical pts increments, whether each stream is all-keyframes or
   predicted, ...) and let the muxer build a reasonably good framecode
   table.
3. Provide info for all frames in advance; muxer generates a globally
   optimized framecode table.
4. Caller provides its own framecode table.

Both 2 and 3 can be considered special cases of 4, i.e. a function
that is otherwise independent of libnut can generate a framecode table
meeting conditions from option 2 or 3.

> 7. The API probably sucks, as I've never dealed with such stuff before...

Somewhat.. not too bad.

> 8. demux_nut.c for MPlayer is quirky and hackish...

:)

> 9. FIXME's, TODO's and ###'s all over the place. :)

:))

10. Drinking lots of cola. :))))))))

Rich