[FFmpeg-devel] [RFC] Channel layouts

[Justin Ruggles]

Michael Niedermayer wrote:
> On Fri, Aug 29, 2008 at 04:57:52PM +0200, Michael Niedermayer wrote:
>> On Fri, Aug 29, 2008 at 04:00:44PM +0200, Benjamin Larsson wrote:
>>> 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.
>> I think that alternative implementations should be discussed and considered
>> only then can we say what is good and what is not.
>>
> 
>> As simple example instead of am int bitmask, an array of flags could be used,
>> thus avoiding the first problem.
> 
> Of course we could also use int64 now and switch to array with a major version
> bump in case we do need more than 64

I agree that we need more than what is provided by the wav bitmask.  We
at least need 64 bits, but that is still limiting.  For example, SMPTE
428M (D-Cinema) defines 23 channels, and a good many of them are not in
the Microsoft list.  I think CoreAudio has 40 or so channel definitions.

-Justin