[FFmpeg-devel] Channel layouts for aac encoding/decoding and vorbis decoding

Andreas Öman andreas
Mon Aug 10 23:33:27 CEST 2009

Nicolas George wrote:
> Le tridi 23 thermidor, an CCXVII, Andreas ?man a ?crit :
>> I agree but I think that is better addressed with the use of planar (ie.
>> non-interleaved) audio. Than a transcoding from one codec to another
>> with ffmpeg would not require any reordering at all (just some pointer
>> swizzling). And output to Alsa, PulseAudio, whatever would just require
>> one interleaving step (just as you mention)
> As far as I know, most libraries and hardware work with interleaved content,
> and non-interleaved streams do not travel well through FIFOs. Therefore, I
> think that working with non-interleaved channels would but add more
> complexity to the problem.

Yes, but if you move the interleaving out of the codecs you have the
freedom of doing the interleaving (with an optional additional
swizzling step of the planar pointers) or not do any interleaving at

Of course it gets more complex, but flexibility often comes with
increased complexity.

>> Having said that I still think the use of a coherent channel order for
>> interleaved audio was (and still is) a good intermediate step.
> That is precisely what I do not agree with (is this sentence even correct
> English?).

Well, it certainly simplified some code in my application (though it's
still riddled with a special case for the AAC decoder). I can not just
see how it was better before when all codecs had different orders.

> For lavc native encoders and decoders, I guess the choice of the channel
> layout is neutral, and therefore adopting always the same is a good idea.
> But for the other places:
> - wrapper for external libraries,
> - data to/from libavdevice,
> - uncompressed interleaved formats,
> adopting the native layout of the library/device/format seems more logical
> and efficient, provided the data is correctly tagged to allow
> automatic conversion if needed.

Indeed. Though if you, in the "planar audio struct", also add
offset between each sample (similar to stride for video frames) you can
use it to point into any channel order of interleaved samples as well.

It will make the conversion functions more complicated but one can
write optimized cases for the "0 extra bytes of stride" case, etc.

More information about the ffmpeg-devel mailing list