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

[Michael Niedermayer]

On Sun, Jun 26, 2016 at 04:55:56PM -0700, Michael Graczyk wrote:
> 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.

patches applied

thanks

[...]
-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160702/2cd83893/attachment.sig>