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

[Nico Sabbi]

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

>
> But to suggest AVI is just unreasonable - AVI is more or less
> obsolete, and for good reasons. 

avi sucks, but it doesn't seem to be so obsolete, at least judging from 
the amount
of movies sold in bookstores that I see every day

>>
>> I'm bringing up this message for discussion.
>>
>> "For instance, Vorbis can fit into AVI just fine, but unfortunately,
>> Xiph didn't define HOW exactly, so everyone has started doing it in
>> their own, mutually incompatible way."
>
>
there aren't that many possible ways to store vorbis in avi
(I won't even consider ogg in avi, as it simply obscene);
the only thing that should be explicitly specified is how to
store the 3 headers in the extradata field;
few months ago there was a proposal in vorbis-dev, but it was
completely ignored

> I have been told by people much more familiar with the details of AVI
> that this is simply not true (there are some horrendous hacks
> possible, but these don't allow you to put vorbis into AVI, they allow
> some subset of vorbis. I think I've also seen _ogg vorbis_ embedded in
> AVI).

unfortunately there are both

>
> I believe the  primary issue is that AVI permits any of:
> - constant duration, constant packet size
> - constant duration, variable packet size
> - variable duration, constant packet size
> but not variable duration, variable packet size - a core requirement
> of vorbis. I may be wrong in some details there, but it amounts
> roughly to that.


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.