Add support for channel transforms.

media/base/channel_layout.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "media/base/channel_layout.h"
 
 #include "base/basictypes.h"
 #include "base/logging.h"
 
 namespace media {
@@ skipping 16 matching lines @@
     8,   // CHANNEL_LAYOUT_7POINT1
     8,   // CHANNEL_LAYOUT_7POINT1_WIDE
     2};  // CHANNEL_LAYOUT_STEREO_DOWNMIX
 
 // The channel orderings for each layout as specified by FFmpeg.  Each value
 // represents the index of each channel in each layout.  Values of -1 mean the
 // channel at that index is not used for that layout.For example, the left side
 // surround sound channel in FFmpeg's 5.1 layout is in the 5th position (because
 // the order is L, R, C, LFE, LS, RS), so
 // kChannelOrderings[CHANNEL_LAYOUT_5POINT1][SIDE_LEFT] = 4;
 static const int kChannelOrderings[CHANNEL_LAYOUT_MAX][CHANNELS_MAX] = {

[scherkus (not reviewing), 2012/10/18 01:30:39]

random thought: I don't suspect we'll have to change this very often, but I
wonder if a lot of this channel map/layout/etc business could get generated by a
script

for example, my brain hurts looking at this struct but I don't think the
resulting script would be any better!

[DaleCurtis, 2012/10/18 01:56:44]

I think a better approach would be the bitmask method that ffmpeg uses now. E.g.
CHANNEL_LAYOUT_STEREO = LEFT|RIGHT, etc. Then using a compile assert to keep
these in sync with the ffmpeg ones.

   // FL | FR | FC | LFE | BL | BR | FLofC | FRofC | BC | SL | SR | StL | StR
 
   // CHANNEL_LAYOUT_NONE
   {  -1 , -1 , -1 , -1  , -1 , -1 , -1    , -1    , -1 , -1 , -1 , -1  , -1 },
 
   // CHANNEL_LAYOUT_UNSUPPORTED
   {  -1 , -1 , -1 , -1  , -1 , -1 , -1    , -1    , -1 , -1 , -1 , -1  , -1 },
 
   // CHANNEL_LAYOUT_MONO
   {  -1 , -1 , 0  , -1  , -1 , -1 , -1    , -1    , -1 , -1 , -1 , -1  , -1 },
@@ skipping 31 matching lines @@
   // CHANNEL_LAYOUT_7POINT0
   {  0  , 1  , 2  , -1  , 5  , 6  , -1    , -1    , -1 , 3  , 4  , -1  , -1 },
 
   // CHANNEL_LAYOUT_7POINT1
   {  0  , 1  , 2  , 3   , 6  , 7  , -1    , -1    , -1 , 4  , 5  , -1  , -1 },
 
   // CHANNEL_LAYOUT_7POINT1_WIDE
   {  0  , 1  , 2  , 3   , 4  , 5  , 6     , 7     , -1 , -1 , -1 , -1  , -1 },
 
   // CHANNEL_LAYOUT_STEREO_DOWNMIX
-  {  -1 , -1 , -1 , -1  , -1 , -1 , -1    , -1    , -1 , -1 , -1 , 0   , 1  },
+  {  0  , 1  , -1 , -1  , -1 , -1 , -1    , -1    , -1 , -1 , -1 , -1  , -1 },

[scherkus (not reviewing), 2012/10/18 01:30:39]

is this a bug fix that didn't happen when DOWNMIX was added?

can we document the difference between FL/FR and StL/StR on the Channels enum?

[DaleCurtis, 2012/10/18 01:56:44]

I'm not sure what those channels actually mean and no one is using them. Do you
have some historical context on this? Internally in FFmpeg's rematrixer they
just set output = STEREO when STEREO_DOWNMIX is encountered.

Barring any other information, I'll probably just delete those last two.

[scherkus (not reviewing), 2012/10/18 02:24:03]

No clue. You'll have to dig through commit logs + code reviews.

[DaleCurtis, 2012/10/18 05:22:04]

Removed. History shows they were just added because FFmpeg has them.  I couldn't
find any UMA stats using CHANNELS_MAX either, so looks okay to delete.

 
   // FL | FR | FC | LFE | BL | BR | FLofC | FRofC | BC | SL | SR | StL | StR
   };
 
 int ChannelLayoutToChannelCount(ChannelLayout layout) {
   DCHECK_LT(layout, arraysize(kLayoutToChannels));
   return kLayoutToChannels[layout];
 }
 
 int ChannelOrder(ChannelLayout layout, Channels channel) {
   DCHECK_LT(layout, arraysize(kChannelOrderings));
   DCHECK_LT(channel, arraysize(kChannelOrderings[0]));
   return kChannelOrderings[layout][channel];
 }
 
 }  // namespace media