[FFmpeg-devel] [RFC] Channel layouts

[Benjamin Larsson]

Michael Niedermayer wrote:
> On Fri, Aug 29, 2008 at 04:28:00PM +1000, Peter Ross wrote:
>   
>> Hi.
>>
>> This patch adds the notion of channel layouts to libavcodec.
>>
>> Summary of new concepts:
>>
>> * Channel IDs: We give each speaker a notional bit index.
>>   e.g. CHANNEL_FRONT_LEFT=0, CHANNEL_FRONT_RIGHT=1, CHANNEL_BACK_CENTER=9
>>
>> * Channel Layout: An ORing together of Channel IDs.
>>   e.g. ((1<<CHANNEL_FRONT_LEFT)|(1<<CHANNEL_FRONT_RIGHT))
>>   The resulting layout is identical to the dwChannelMask value found in
>>   WAVEFORMATEXTENSIBLE. A channel layout of zero implies 'no statement'.
>>
>> * Chanels are stored with the FFmpeg 'samples' array according to ID order
>>   e.g. left comes before right.
>>
>> * Encoders will indicate their supported channel layouts in AVCodec, in the
>>   same way we do for pixel and sample formats.
>>
>>     
>
> This suggestion has a few problems.
> 1. it is limited to 32 (or 64) fixed channel "positions", 18 are already used
>    in this initial patch, that is more than a 1/4 of the available space
>    is alraedy used up. This reminds me a little of a famous quote of how
>    much memory will always be enough for everyone ...
> 2. It breaks down once x,y,z positions of ideal speakers are available
>    instead of "front left" vs "back center"
> 3. When audio is returned by decoders as samples of all channels interleaved,
>    like it is done currently, then a fixed order means the user app must
>    reorder unless the destination (SDL, OSS, ALSA, ...) and finally and most
>    importabtly the hardware can handle our order. This of course is irrelevant
>    for planar audio which may be what many decoders will output in the future.
>
>   

Will you object an implementation that doesn't take care of the above 
issues? As I see it these are all valid points but the suggested 
proposal is a huge step compared to what we have now and will be 
suitable for most uses of multichannel audio.

MvH
Benjamin Larsson