[FFmpeg-devel] [RFC] Channel layouts

[Benjamin Larsson]

Robert Swain wrote:
> 2008/8/29 Benjamin Larsson <banan at ludd.ltu.se>:
>   
>> 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.
>>>
>>>       
>> Will this solve the channel order also ? So that transcode from 5.1 dca
>> to ac3 will work ?
>>     
>
> I assume it's insisted that the channels be order as they are in the
> channel mask and the convention is suggested by the third bullet point
> though I think it should be clarified. It sounds like the internal
> channel order is defined by channel mask reading from the least
> significant bit upwards.
>
> e.g.
>
>   

If that is correct then all decoders and encoder need a channel order 
permutation table to match the internal FFmpeg channel order. I'm not 
sure how well that would fit for most decoders. One other option would 
be to decode in codec native order and then pass a channel permutation 
table via some means. I'll look into what would work best with dca.


>>> +#define CHANNEL_LAYOUT_5POINT1  ((1<<CHANNEL_FRONT_LEFT)|(1<<CHANNEL_FRONT_RIGHT)| \
>>> +                                 (1<<CHANNEL_FRONT_CENTER)|(1<<CHANNEL_LOW_FREQUENCY)| \
>>> +                                 (1<<CHANNEL_BACK_LEFT)|(1<<CHANNEL_BACK_RIGHT))
>>>       
>
> Would be [FL][FR][C][LFE][SL][SR] in the output samples array.
>
> Is there any benefit to doing all the bit shifting of the flags or can
> we just do the usual 0x1, 0x2, 0x4, 0x8, 0x10, 0x20... that we use for
> other bit mask flags?
>   
I think we just should add the relevant channel mask instead having this 
shifting.


> Rob
>   

MvH
Benjamin Larsson