[MPlayer-dev-eng] Re: rethinking nut!

[John Cannon]

First off...please don't start bashing...it's getting old.

D Richard Felker III wrote:
> I got to thinking some more about NUT (formerly known as MPCF, i.e.
> MPlayer Container Format), and well, I think we might want to make
> some major design changes.
> 
> Why? Well, Alex was implementing NUT support in ffmpeg/libavformat,
> and one of the main reasons he slacked off was that it was too painful
> to do the audio subpacket buffering stuff right with libavformat's
> design. Yes, maybe this means lavf sucks...but IMO it also means NUT
> is overcomplicated.

I wouldn't say it's really overly complicated though i haven't done any 
subpacket handling in my code yet.  One thing I found very aggravating 
though is the inconsistency in packet structure.  All packets except the 
frame packets have the packet header immediately following the startcode 
(if there is a startcode).  The frame packets however have that one byt 
between them which IMO should be moved to the packet body.  Is there a 
real reason why this belongs before the header?  It just makes my C 
muxer code have unnecessary if's in it.

> IMO the solution is to greatly cut down the headers. Current spec
> calls for:
> 
> 1 byte of flags
> 1+ byte forward pointer (vlc)
> 1+ byte backward pointer (vlc)
> 1+ byte stream id (vlc)
> 1+ byte timestamp (vlc)
> some other optional stuff
> 
> Without subpackets, this means at least 5% overhead for 128kbit mp3
> audio, and probably worse for typical vorbis. Very bad. How could we
> improve the situation:
> 
> 1. Store stream id in with flags. It should be a 3-bit field, with the
>    special value of 111 meaning there's a separate vlc field in the
>    entry afterwards storing the stream id (used only when there are
>    more than 7 streams).

You can also change this so that lower id streams are coded with just 
the three bits and then use these for your small packet streams like audio.

> 2. Make flags a vlc field, with the essentials at the beginning, and
>    video-specific stuff later (so we don't waste space on those fields
>    for audio/subtitle packets).

This sounds hackish to me.

> 3. Make timestamp optional, with a default timestamp-delta in the
>    stream header. Optionally have a 2-bit timestamp selector field,
>    with 11=full timestamp in its own vlc field, and 00,01,10 being 3
>    predefined deltas from the stream header (useful for vorbis audio
>    and post-ivtc mixed-fps material :).

Sounds nice...in matroska we use default durations for blocks.

> Alex, Michael, and others interested in container formats: please post
> your thoughts on the matter. But remember: IMO it's better to design
> something simple that we'll actually implement, rather than bloatware
> specs like Matroska that would require hundreds of KB of code to
> use... (which we're too lazy to write!)

NUT certainly has code size going for it.  My whole nut muxer is about 
600 lines of C code including the I/O abstraction layer.

Spyder