[FFmpeg-devel] [PATCH] libopusenc: Add channel mapping family argument
michael at niedermayer.cc
Wed Jun 15 02:46:04 CEST 2016
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
> 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
> $ ./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
> 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,
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel