[MPlayer-dev-eng] [spyder at matroska.org: Re: rethinking nut!] NOVIRUS

[D Richard Felker III]

On Thu, Apr 01, 2004 at 09:24:56PM +0200, Moritz Bunkus wrote:
> >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

Well it required deep buffering, which I consider complicated. Think
of realtime streaming applications or a hardware muxer with low
memory.

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

I hope Michael's answer was acceptable.

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

Hmm, I think that's what I said, isn't it?

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

It's just another way of saying to have one bit that means "second
flags byte follows". Not really hackish, pretty standard. But it's
probably not needed anyway.

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

Yes, this is the whole point. A good standard should be something
people can make independent, interoperable implementations of,
including hardware implementations and implementations for embedded
systems. It should also give minimal overhead, allow perfect O(1)
seeking to any packet, provide exact rational pts for every packet,
and should support any codec without requiring new code in the
muxer/demuxer.

BTW, before we removed subpackets you would have needed a _lot_ more
code for a fully functional muxer. Now your 600 lines should be almost
complete.

Rich