[FFmpeg-devel] [RFC] Channel layouts

[Michael Niedermayer]

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.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080829/09cc3a5d/attachment.pgp>