[ogg-dev] OggPCM2: channel map

[John Koleszar]

Jean-Marc Valin wrote:

>>I'm also not entirely sure that the coding chosen for the channel 
>>definitions is the best one. Typically we'd expect each type of channel 
>>map to contain all and nothing but the channel definitions typically 
>>used with that map type, in some order. For example L, C, R, Ls, Rs and 
>>LFE for 5.1. If so, all we're really trying to encode is the 
>>interleaving order.
>>
I that this is handled pretty nicely by the "simple map" that Sampo 
suggested. This is basically the same thing as the "channel map" 
described on the wiki, but with the (physical,logical) channel pair 
swapped. So, using the syntax from the wiki:
channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [OGG_CHANNEL_FRONT_LEFT] = 1
channel_map [OGG_CHANNEL_FRONT_RIGHT] = 2

This is nice because it makes it impossible for somebody to do something 
stupid like define two channels as carrying FRONT_LEFT. A player can't 
handle that situation sanely, but handling both FRONT_LEFT and 
FRONT_RIGHT mapping to channel 0 is easy. Like Sampo said, this does 
mean having to define (and assign an order to) what channels are in each 
channel type, but I don't look at that as a bad thing. The other case we 
were trying to support, of multiple logical streams at different 
bitrates is still easy:

Stream 1:
channel_type = OGG_CHANNEL_MAP_5_1
channel_map [OGG_CHANNEL_FRONT_LEFT] = 1
channel_map [OGG_CHANNEL_FRONT_CENTER] = 2
channel_map [OGG_CHANNEL_FRONT_RIGHT] = 3
channel_map [OGG_CHANNEL_FRONT_LEFT_SURROUND] = 0
channel_map [OGG_CHANNEL_FRONT_RIGHT_SURROUND] = 0
channel_map [OGG_CHANNEL_FRONT_LFE] = 0

Stream 2:
channel_map [OGG_CHANNEL_FRONT_LEFT] = 0
channel_map [OGG_CHANNEL_FRONT_CENTER] = 0
channel_map [OGG_CHANNEL_FRONT_RIGHT] = 0
channel_map [OGG_CHANNEL_FRONT_LEFT_SURROUND] = 1
channel_map [OGG_CHANNEL_FRONT_RIGHT_SURROUND] = 2
channel_map [OGG_CHANNEL_FRONT_LFE] = 3

I think the major difference between Sampo's suggestion and what we 
defined is that I think we intended only one "channel map" header and 
many conversion headers. If you allow many "maps", a player that doesn't 
implement a mixer just has to read packets until it finds a known 
channel map. Players that do implement mixers only have to read until 
they hit the first stereo "conversion header." As long as the mapping 
packets appear in "preferred" order, the player should always produce 
the best representation it can. With the packets as defined on the wiki, 
applications have to implement a mixer to play anything but their native 
format, which may not be desirable, since many formats can be remixed by 
just selecting the proper channels. Stream 1 above, for example, might 
define another map:
channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [OGG_CHANNEL_FRONT_LEFT] = 1
channel_map [OGG_CHANNEL_FRONT_RIGHT] = 3

I think Sampo's notion of calling them both packet types maps is a 
little cleaner, since both try to do the same thing, but wanted to be 
consistent with the terms we've been using. His "complex map" is the 
same as the conversion header as far as I can tell, so it looks like the 
pair ordering in the channel map is the only thing we disagree on. 
Overall, I think his solution is pretty slick.

>One idea I had for this is that there should be a default mapping for
>all channel mappings and a default channel mapping for the most used
>number of channels. For example, we would say that unless you include a
>mapping header, then a 2-channel file is stereo with left channel
>interleaved before right. I've added the idea at the bottom of
>http://wiki.xiph.org/index.php/OggPCM2 . Any thoughts on this?
>
>  
>
I think this is a good idea, but it may be wise to stop at stereo and 
not provide a preference for any of the 4+ channel formats.

John