Baptiste Coudurier <baptiste.coudurier@smartjog.com> writes:
Hi
Oded Shimon wrote:
[...]
Ivan, vorbis doesn't expect 3 extradata according to the spec, it expect the first 3 audio packet to be the headers. I think this is insane enough that it allows us to break their spec instead of ours.
The vorbis spec states that when stored in ogg, the first three packets are headers. These three packets are passed to libvorbis using a function (vorbis_synthesis_headerin()) different from the one used for the remaining packets (vorbis_synthesis()). The vorbis spec itself treats these headers quite distinctly from the main bitstream. It was a bad move of the vorbis designers to choose three separate header formats, seeing as many container formats allow for one piece of codec extradata, and ogg doesn't have any dedicated space at all for this. Packing the three pieces of data into one would have made no difference for ogg, and would have made storing vorbis in other containers easier. Actually, ogg processing would also be simpler if you knew that the first packet was header data, rather than the first N packets.
Huh. How come a container can surpasses codec specs ? IMHO that's not acceptable.
Indeed. 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 for packing extradata can continue to pack nut extradata into that format internally, so there will be no added complexity for those. -- Måns Rullgård mru@inprovide.com