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 > <mich...@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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
