[FFmpeg-devel] [RFC] Channel layouts

[Justin Ruggles]

Derk-Jan Hartman wrote:
> On 8 sep 2008, at 10:13, Robert Swain wrote:
>> 2008/9/8 Robert Swain <robert.swain at gmail.com>:
>>> 2008/9/7 M?ns Rullg?rd <mans at mansr.com>:
>>>> Peter Ross <pross at xvid.org> writes:
>>>>
>>>>> On Fri, Aug 29, 2008 at 10:21:28PM -0400, Justin Ruggles wrote:
>>>>>> Peter Ross wrote:
>>>>>>> +int64_t avcodec_guess_channel_layout(int nb_channels)
>>>>>>> +{
>>>>>>> +    switch(nb_channels) {
>>>>>>> +    case 1: return CHANNEL_LAYOUT_MONO;
>>>>>>> +    case 2: return CHANNEL_LAYOUT_STEREO;
>>>>>>> +    case 4: return CHANNEL_LAYOUT_QUAD;
>>>>>>> +    case 6: return CHANNEL_LAYOUT_5POINT1;
>>>>>>> +    case 8: return CHANNEL_LAYOUT_7POINT1;
>>>>>>> +    default: return 0;
>>>>>>> +    }
>>>>>>> +}
>>>>>> Why not add 3 and 5 to the list?  My vote would be for left/ 
>>>>>> right/center
>>>>>> and 5.0.
>>>> 2.1 and 4.1 are equally, if not more, likely.  I have such DVDs, but
>>>> none with x.0 where x > 2.
>>> I agree with M?ns on this one. 2.1 and 4.1 would be better choices in
>>> my opinion.
>> Actually, now I'm not so sure. I was thinking in terms of end user
>> speaker configurations rather than channel layouts in codecs. Justin's
>> point about just giving them generic names based on the numbers of
>> channels (as this is all they are...) would make more sense as there
>> is the ambiguity of 4.1 versus 5.0 for example.
> 
> Why not use names as defined by one of the standards ?
> I advise people to look into the CoreAudioTypes.h header on OSX. They  
> have a very good separation between channellabels and channellayouts.  
> They also support MPEG, ITU, DVD layout-tagnames (as well as AudioUnit  
> names).
> 
> CoreAudio can handle almost any channelordering concept and in my  
> opinion is one of the better examples when implementing things like  
> this.

The CAFF specification also has the same info. There are some good
things about it, and some that are not.  The speaker definitions and
channel layouts are completely separate from eachother, with different
methods of defining a predefined vs. arbitrary layout.  They define an
enum value for about every layout/order combination imaginable... and a
separate enum for every speaker/channel name imaginable.

I like Peter's solution better because we can still add channels, then
combine them however we want.  Something will need to be devised to
indicate channel order, but I think having it separate from they layout
which just tells which channels are present is more flexible.

Possibly some kind of solution which allows for defining a layout/order
combination would be good.  That way the actual channel information
could be inspected automatically to see what kind of
reordering/mixing/etc.. would be required for conversion instead of
having to track compatibilities between layouts by their names alone.

-Justin