[ogg-dev] OggPCM2: channel map

[jkoleszar at on2.com]

>> True, but remember that the channel map type implied the number of
>> entries in the table, and also that in this organization you'll always
>> number the logical channels consequtively since each logical channel
>> indeed corresponds to an index into the array. If the channel map type
>> says it's a map for 5.1, there will only be 6 slots in the table no
>> matter how many channels are actually stored.
>
> Not quite, let's say the six first logical channels are the ones used
> for surround (left, right, back, ...) and you have an ambisonic file
> (left and right have no meaning) or something like that. You still have
> a much larger table than you need.

I think I understand the confusion here, but correct me if I'm wrong. What
we're proposing is to define the channel map for each supported channel
group type. The array syntax I used in my last post probably added to the
confusion - look at it again but without using the assigned values to the
OGG_CHANNEL_* text. A couple examples:

Packet 1:
channel_type = OGG_CHANNEL_MAP_5_1
channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1
channel_map [1 = OGG_CHANNEL_FRONT_CENTER] = 2
channel_map [2 = OGG_CHANNEL_FRONT_RIGHT] = 3

Packet 2:
channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1
channel_map [1 = OGG_CHANNEL_FRONT_RIGHT] = 2

Packet 3:
channel_type = OGG_CHANNEL_MAP_UHJ
channel_map [0 = OGG_CHANNEL_UHJ_SIGMA] = 1
channel_map [1 = OGG_CHANNEL_UHJ_DELTA] = 2

>From the first two examples, we see that a channel can appear at different
indexes in the mapping array. The order of channels within the array is
defined by the channel_type. Under this scheme, the channel id either has
no numerical value, or has a value defined for each different
channel_type. To make this more clear, the channels above should be
renamed:
OGG_CHANNEL_STEREO_LEFT = 0
OGG_CHANNEL_STEREO_RIGHT = 1
OGG_CHANNEL_5_1_FRONT_LEFT = 0
OGG_CHANNEL_5_1_FRONT_CENTER = 1
OGG_CHANNEL_5_1_FRONT_RIGHT = 2
OGG_CHANNEL_UHJ_SIGMA = 0
OGG_CHANNEL_UHJ_DELTA = 1

So the number of channels in the map is always equal to the number of
channels in the group type, not the number of channels in the stream.
You're right, if the channel id's had a globally unique value (as is
currently defined), then you'd have to include blank slots for all the
unused channels as you mentioned, and this wouldn't work.

Applications should search based on group types, not channel id's - ie, an
application supports CHANNEL_MAP_STEREO, not CHANNEL_FRONT_LEFT and
CHANNEL_FRONT_RIGHT. So I don't think defining the channel id's within the
scope of a group type is too bad.


> I mean that if we want to describe how to convert from 5.1 to stereo,
> then you don't want to define the conversion for both [left,right]
> stereo and for [right,left] stereo. If you have a default, then the
> conversion is always defined for the default and if you want something
> else, you can easily swap channels.

The conversion maps define conversions to logical channels, not physical
ones. To use a crude example, if you're going from 5.1 to stereo by just
extracting the FL and FR channels, you'd define a conversion map that says
stereo left is on channel 0, stereo right is on channel 2. Then if your
app wants to make (r,l) out of it instead of (l,r) it's free to do so. So
you would create a stream with Packet 1 above, and Packet 4:
Packet 4:
channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1
channel_map [1 = OGG_CHANNEL_FRONT_RIGHT] = 3

Does that help at all, or have I added to the confusion?

John