[FFmpeg-devel] [PATCH] libopusenc: Add channel mapping family argument

Michael Graczyk mgraczyk at google.com
Tue Jun 14 22:49:50 CEST 2016

Has anybody had a chance to look at this patch? Any thoughts or ways I can
make it easier to look over?

On Fri, Jun 10, 2016 at 10:39 PM, Michael Graczyk <mgraczyk at google.com>

> The libopus encoder has a parameter called "channel mapping family" which
> is used to specify inter-channel relationships for the purpose of encoding.
> I have added a new command line argument which makes it possible to forward
> the mapping family parameter along to libopus.
> With this parameter, it is possible to choose between encoding
> multichannel audio streams as surround sound (with interchannel masking and
> channel coupling) versus independent channels (no interchannel masking nor
> channel coupling).
> Example usage:
> $ wget https://samples.ffmpeg.org/A-codecs/wavpcm/8_Channel_ID.wav -O
> in.wav
> # Use the old behavior. Header contains layout, but no masking
> $ ./ffmpeg -y -i in.wav -c:a opus -mapping_family -1 out.ogg
> # Use libopus surround mode. Masking + automatic channel coupling
> $ ./ffmpeg -y -i in.wav -c:a opus -mapping_family 1 out.ogg
> # Use libopus with independent channels. No header info, no masking, no
> coupling
> $ ./ffmpeg -y -i in.wav -c:a opus -mapping_family 255 out.ogg
> This patch also makes it possible to encode up to 254 channels with opus
> using channel mapping family 255.
> $ head -c 1728000 /dev/urandom > noise.raw
> $ ./ffmpeg -y -f s16le -ar 48000 -ac 18 -i noise.raw -c:a opus
> -mapping_family 255 out.opus
> Questions:
> 1. I had to remove .channel_layouts form ff_libopus_encoder to allow the
> encoder to accept streams with more than 8 channels. Is that the right way
> to extend the encoder? Based on a discussion on #ffmpeg it seemed like
> removing the .channel_layouts field would be the only way to allow more
> than 16 channels.
> 2. Am I using AVFrame.data correctly? I recall reading somewhere that
> channels after the eighth would be stored in extended_data, but from the
> documentation it seems like that is only the case for planar data.
> Thanks for reading,
> Michael Graczyk


Michael Graczyk

More information about the ffmpeg-devel mailing list