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

Michael Graczyk mgraczyk at google.com
Mon Jun 27 01:55:56 CEST 2016


Michael,
Thanks for your comments.

On Sat, Jun 25, 2016 at 4:28 AM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> yes, rereading this a bit
> can you explain what is the difference between the mapping familiy
> and he channel_layout we have ?

The Opus channel mapping family and FFmpeg channel layout both provide
a mapping between stream position and semantic meaning. That is, they
both answer the question "What does the channel at position k in the
stream contain?"

The two parameters are both defined by explicitly enumerating
acceptable possibilities. There are some channel mappings which are
defined by Opus but are not defined by FFmpeg. Likewise, there are
channel mappings defined by FFmpeg which are not defined by Opus.
Because of the differences, there is no unambiguous 1:1 correspondence
between Opus channel mapping family and FFmpeg channel_layout. For
example, FFmpeg has no way of specifying "channel k is an SN3D
normalized ambisonic channel kth in ACN order". Opus does (or soon
will) have a way of specifying that, namely mapping_family==2.


> if the channel_layout is not set its undefined, if its set it should
> be correct
> why do you need this additional user parameter ?

The additional parameter is necessary to disambiguate between multiple
cases which are all unknown to FFmpeg. For example, there is no way
for FFmpeg to differentiate between inputs which consist of Ambisonics
and inputs which have truly no semantic meaning. These two cases are
differentiated by Opus, with mapping_family 2 and 255 respectively.


Also the way this patch is written, mapping_family==-1 preserves
existing FFmpeg behavior while mapping_family==1 does not. Although
both values indicate the same semantic channel meanings, the latter
configures libopus to use surround masking, which is a potentially
quality-degrading change from current behavior. That is why I did not
change default behavior with this patch.

-- 

Thanks,
Michael Graczyk


More information about the ffmpeg-devel mailing list