[NUT-devel] Re: r19110 - trunk/DOCS/tech/nut.txt

[Rich Felker]

On Tue, Jul 18, 2006 at 09:17:01AM +0100, Måns Rullgård wrote:
> The problem here is that ffmpeg, like most other apps, only handles
> passing one piece of extradata from the demuxer to the decoder (and
> from the encoder to the muxer).  This is enough for most codecs and
> formats, but falls short when a codec uses several extradata blocks
> (like vorbis).  It is also a problem when using these codecs in
> formats that only handle one extradata block.
> 
> Now we have a chance, by specifying storage of multiple extradata
> blocks, to create a container that can store *any* codec without
> resorting to hacks outside the spec.  Most apps will probably have to
> somehow pack these multiple blocks into a single block that is passed
> around inside the app, and unpack/repack it to suit whatever codec
> libs they pass it to.
> 
> The advantage over storing this single block directly in the container
> file is that there is no need to agree among apps on the format to be
> used.  Hypothetical apps that can handle multiple extradata pieces
> will need no hacks at all.
> 
> I'll state my main point again.  Allowing multiple extradata blocks in
> nut will allow any codec to be used with nut, *without* any need for
> agreements outside the codec specs.  Apps that use some common format

No it will not. All Xiph has to do is make their new
latest-and-greatest container have a hierarchical filesystem of header
blocks, or a relational database of header blocks, or whatever other
bloated crap they can come up with, and then we cannot store that
without hacks!

A codec having multiple header chunks without any in-band signalling
of their boundaries is a _pathology_. It is not the norm and it is not
something NUT should account for or that players should have to deal
with.

Rich