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

[Måns Rullgård]

Baptiste Coudurier <baptiste.coudurier at 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 at inprovide.com