[FFmpeg-devel] [RFC] Channel layouts
Fri Aug 29 16:00:44 CEST 2008
Michael Niedermayer wrote:
> On Fri, Aug 29, 2008 at 04:28:00PM +1000, Peter Ross wrote:
>> 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.
More information about the ffmpeg-devel