[ogg-dev] OggPCM version / header finalization
jkoleszar at on2.com
Thu Nov 10 13:23:23 PST 2005
Silvia.Pfeiffer at csiro.au wrote:
>1) What are we trying to achieve with the "source-ID"?
>So, would each channel be in a separate OggPCM logical bitstream and interleaving would happen at the ogg level? If that is the case, then this is unnecessary since every logical bistream in Ogg framing already gets attributed a different serial number in the page header.
>Or are we trying to describe how the data of the different channels are interleaved with each other inside the one one flat logical bitstream? Then I think this one field should *not* provide an ID but rather an interleaving description. Since usually channels are just consecutively ordered (if I'm not mistaken), this information may not be necessary at all.
Basically I was trying to provide a method where a logical bitstream
could contain only a subset of the total number of channels of the
source. For instance, a 5.1 signal could be broken up into 3 logical
bitstreams (A high fidelity stereo pair, three channels of CD quality
audio, and a LFE channel, all with different sampling parameters) The
source ID would be used to remux them. This is similar to the page
serial number, I know, but I don't think that's sufficient if data from
the same source is spread across multiple logical streams, and you want
to support multiple sources in the same overall stream. A source is
considered to be a group of correlated channels, for instance a movie
player app, a music player app, or a voice chat app. This field isn't
needed if you require a stream to consist of data only from a single
source, or you rely on cooperative applications to agree on a page
serial number scheme. I'm not convinced it's needed, but the discussion
should be had.
I know that splitting a source up across multiple logical streams is
ugly, but I can't think of any clean way to provide multiple sampling
parameters within a single stream. In most cases, all channels will have
the same sample parameters, so they will all be in a single logical
stream. I really think that requiring fixed sample parameters per
logical stream is a smart constraint to make.
>2) I don't understand what the "channel block" is for?
>What is it trying to describe?
Mostly doing something useful with extra bits :) It was a way to have
more than 16 channels per source, since I'm sure some crazy person
thinks that's not enough :) I just proposed banking them, so you'd have
256 banks of 16.. Think of it as the 8 most significant bits of a 12 bit
>3) I also still don't understand why packets require an extra landmark (i.e. the data packet header).
>I don't buy into Arc's argument that this framing is necessary to keep space for potential future additional header fiels. No other uncompressed audio format requires extra framing and header information for the samples (FAIK), so I cannot see how future additional header fields would require to be added. It should be made clear in the bos page how many samples go into a packet and thus packed framing is unnecessary. This field is just complicating decoding through an unnecessary extra parsing step IMHO.
I do think it's important that there be some mechanism to put extra
pages between the page 0 header packet and the first data packet. That
could be done by adding a field indicating the number of header packets,
or as is currently proposed. These potential header packets could
contain things like the CDDB ID, ID3 tag like info, etc. It's good
Note that if an application wants to use this data like an array in
memory, it probably has to memcpy it to it's own allocated buffer before
accessing it more than a byte at a time. This is because, AFAICT, libogg
makes no guarantee about the alignment of the data pointed to by the
ogg_packet.packet member, and there are architecture specific
requirements about unaligned multibyte accesses. If you're going to have
to copy the buffer somewhere anyway, I don't think it's a huge burdon to
advance the pointer 4 bytes. Either way is fine with me though.
More information about the ogg-dev