[FFmpeg-devel] [RFC] Channel layouts

[Michael Niedermayer]

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


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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/61bfdb75/attachment.pgp>