[ogg-dev] OggPCM proposal feedback
ogg at illiminable.com
Wed Nov 9 23:44:53 PST 2005
----- Original Message -----
From: "Arc" <arc at Xiph.org>
To: <ogg-dev at Xiph.org>
Sent: Thursday, November 10, 2005 2:57 PM
Subject: Re: [ogg-dev] OggPCM proposal feedback
> On Thu, Nov 10, 2005 at 10:13:19AM +1100, Erik de Castro Lopo wrote:
>> a) There is no marker to distinguish little endian data
>> from big endian data.
> The original reason for this is because Ogg makes such a matter moot,
> since the bitpacker in libogg2 handles endian.. however, if a "chunk"
The problem i see with this, correct me if i'm wrong, but you are suggesting
you are going to get a really large chunk of pcm and feed it into libogg
word at a time, in order to have it's endianness possibly reversed ? And
then on the other end, read it out word at a time ? If as you suggest this
is primarily for interchange, then this seems a really inefficient way to
pass data around.
The reason it should allow specification for endianness is that, if it is to
be used as an interchange format, it needs to be easily copied around in a
format friendly to the host processer. Requiring the byte order flipping of
every sample seems contrary to the purpose of such a format.
> Problem with this is inflexibility. See, not ever application must
> support every possible combination of formatting - in fact, many will
> require a very small set of parameters going in, ie, "it must be float
> of 16, 24, 32, or 64 bit" or "it must be 16 or 24 bit signed".
What you are saying is that outputs will support some set of data formats,
and inputs will support some other set of data inputs. In other words, each
component only supports the types it knows how to do something with. And so,
the hypothetical situation of some new format, not in the enumeration comes
along, and of course, the components won't support it since they only
support their subset of data they know how to handle. So, a new value needs
to be added to the enumeration. The result is, existing components (which
didn't support the new format anyway), will still be in the same situation
if they come across a new file, with an enumeration value they don't
So, if a new format comes along which does require a new enumeration value,
then the components are going to have to be modified to support that anyway,
and the adding another value to the list they support is a non-issue. The
only possible way it's inflexible is if the number of values in the
enumeration exceeds the size of the field it has. Probably unlikely even
with 8 bits, almost certainly unlikely for 16.
> Implementors will never, very likely, implement 32-bit unsigned int, and
> that is not an issue. If some fool does, his data will simply not be
> accessable to any other codec or application unless he writes a
> conversion plugin, which in essence, treats the two sides (from
> OggStream's perspective) as two entirely different codecs, even if both
> are in OggPCM format.
I know you are working on OggStream, and this is the perspective you are
taking, but other implementations ie directshow, quicktime, mplayer,
gstreamer don't and maybe won't be using oggstream. So i think we need to
take a bigger picture approach what assumptions are being made here.
> I guess you could chalk this up to an inherit difference in philosophy
> and purpose between OggPCM and RIFF/WAVE (.wav).. theirs is as much an
> interchange format as a storage codec, where OggPCM isn't really
> intended for storage. FLAC (Free Lossless Audio Codec) limits to a
> certain number of formats, and all decoders can decode these formats,
> and it's well suited for storage as a /compressed/ lossless codec..
This is another issue i see as a problem, why is it only an interchange
format ? What is the rationale for that ? There are many people who want a
storage format. Are you suggesting that another raw storage format also be
I think this is the wrong approach, flac and other codecs operate on a
tighter subset, because they have to perform complex transformations on the
data, and supporting too many types increase complexity. A raw format
essentially needs no processing, it just needs copying into a buffer that
supports that type of data.
> I'd really like to prefer keeping a fixed samplesize/samplerate for all
> channels. I really doubt any Ogg audio codec is going to get that
> complicated anytime soon, and if it's really needed, a codec plugin
> /could/ be fed/provide packets from multiple OggPCM bitstreams, just
> like how a+v codecs (ie, DV) would import/export OggPCM+OggYUV.
I think this is another problem with your approach, you are assuming that
ogg is a closed format, and that only "ogg" formats are the issue here. Ogg
is a generic container format, other codecs can and will be used inside it.
Making assumptions based only on the current set of xiph codecs in my opinon
is a little narrow focussed.
More information about the ogg-dev