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

[Michael Niedermayer]

On Fri, Jun 10, 2016 at 10:39:23PM -0700, Michael Graczyk wrote:
> 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.

extended_data is for more than AV_NUM_DATA_POINTERS planar channels,
yes

it seems this patch moves some code around, can that be split into
a seperate patch so its more clearly vissible what is changed.

Also iam not sure people will like the aprouch taken by this patch
or prefer the mapping_family to be passed through API like side data
and be preserved from input to output

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160615/62425cbb/attachment.sig>