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