[Vorbis-dev] "Any who has ever written an Ogg (de)muxer curses it's name frequently" (sic)

[Michael Smith]

On 2/28/07, Nico Sabbi <nsabbi at email.it> wrote:
> Michael Smith wrote:
>
> >
> > I'm not going to defend Ogg here - writing Ogg code turns out to be
> > very difficult, as it works fundamentally differently from essentially
> > every other container format in widespread use, and requires a much
> > tighter coupling between codec and container.
>
> and this aspect alone is horrendous, IMO; perfect separation between
> container
> and its content should be a target for every container

As I said, I'm not defending Ogg on that point...

> but the current implementations of vorbis permits only 3 possible
> block sizes, that have a least common multiple that can be used as the
> constant
> increment step. Since Avi permits to store null frames to emulate a variable
> frame rate, storing vorbis in avi becomes straightforward - although ugly.
> In ffmpeg there's a native vorbis encoder (very new and not particularly
> tuned,
> but decent) that uses a constant framesize, so storing it in avi is
> particularly easy.

The vorbis specification allows blocksizes from 64 to 8096; you
wouldn't want to store the number of neccesary null frames to make
that work. We're not very interested in creating a way to embed "the
current output of one particular encoder" in vorbis. There's a
complete specification for a reason - players are expected to
implement it.

There are a large number of container formats that permit this with no
particular problems - really, the only major issue is packing the N
header packets into a single buffer for the various containers that
only allow a single 'extradata' field. Yes, we should define one. No,
AVI is not an interesting case - it's too limited, and there are
plenty of other very widespread formats without those particular
limitations.

Mike