[FFmpeg-devel] [RFC] Channel layouts
Sun Sep 7 17:25:01 CEST 2008
Andreas ?man wrote:
> M?ns Rullg?rd wrote:
>> Don't forget that the channel layout must specify not only which
>> components are present, but also their order. Currently lavc tells
>> you neither, making it practically useless for multi-channel audio.
> The idea is that the order is the same as the CHANNEL_LAYOUT bits.
> I.e. LEFT must be the first channel if it exists, then RIGHT, etc.
> Still, this would only be mandatory for codecs (and formats) that
> specifies channel_layout.
There should still be a way for the demuxer to communicate the source
channel order. Sure, most codecs have a defined channel order, but raw
PCM does not. The demuxer should not reorder the channels, but the
user-level does need to know what that order is.
> This is IMHO no more strange than that PIX_FMT_YUV always have
> the planes in Y,U,V order. From an application perspective i find
> this much more convenient. There might be more work in the decoders
> though. Still, with float_to_int16_interleave() (that all of the
> "popular" multi-channel codecs currently use (AC3, DTS and AAC))
> this is just a matter of swizzling a few pointers at setup time.
I don't know if there is the same complexity of ordering in video as in
audio. I do see that we have different PIX_FMT's for RGB and BGR.
Here are some of my thoughts on channel order.
I think it would be a lot better from an application's perspective if
the demuxer specified order if it knows it. That way the app doesn't
have to necessarily know what the AAC default channel order is, or
whatever, and can rely on libavformat to say so if it knows. For raw
PCM it is very important to know the order since the channel order
depends on the container.
Most audio decoders would be able to set the appropriate channel order
based on information in the bitstream and/or codec defaults. PCM
decoders would have to either do nothing, which would break the desired
behavior, or would have to be told the source channel order so that they
could reorder it if necessary.
This is straightforward. The encoder would expect default FFmpeg
channel order and reorder if needed. But it would probably need to set
the new channel order to communicate it to the user/muxer. The PCM
encoder wouldn't have to reorder or change anything.
I think most of the muxers will support the default order for PCM, but
not necessarily all of them. I think AIFF puts center between left and
right. For other codecs, the muxer knowing what the order is for the
payload would be good since some of them can (or need to) set it in the
> For other codecs there might be more work involved. However,
> that day ffmpeg gets planar audio formats this is even less
> an issue.
It would certainly make it easier to do the reordering, but wouldn't
alleviate all the issues of needing to know what the order is and when
to rearrange it.
More information about the ffmpeg-devel