[MPlayer-dev-eng] Re: rethinking nut!
spyder at matroska.org
Sun Mar 28 19:06:47 CEST 2004
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.
More information about the MPlayer-dev-eng