[FFmpeg-devel] [PATCH] libopusenc: Add channel mapping family argument
michael at niedermayer.cc
Sun Jul 3 00:51:43 EEST 2016
On Sun, Jun 26, 2016 at 04:55:56PM -0700, Michael Graczyk wrote:
> 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.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel