Re: [codec] Comments on draft-ietf-codec-ambisonics-01

[Mark Harris <[e-mail]>]

On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin <[e-mail]> wrote:
> 3.2.  Channel Mapping Family 3
>
> I would suggest removing the "Output Channel Numbering" field because it
> is fully equivalent to simply permuting lines of the matrix. Also, I
> believe that the size of the matrix was meant to be "32*(N+M)*C bits"
> rather than "32*N*C bits".

To expand on this a bit, a mapping family maps M+N decoded channels
(corresponding to the actual order of the coupled and uncoupled
channels in the bitstream) to C output channels (channels with a
specific semantic meaning).  The additional "Output Channel Numbering"
table confuses things by adding an additional mapping from the output
channel numbers to a different set of numbers with actual semantic
meaning, leaving the output channel numbers with no apparent meaning.

This does have a potential benefit as a matrix compression technique,
to reduce the size of the matrix when it would contain rows that are
all zero.  However considering that the matrix occurs only once, and
mapping family 2 already offers a way to compress the matrix, this
alone does not seem worth the complexity of another level of
indirection.  If matrix compression is desired it would probably be
less confusing to describe it in those terms and keep the semantic
meaning tied to the output channels.

The description of the Output Channel Numbering also does not specify
the intended behavior if the same value appears in the table multiple
times.

Additionally, section 4.2 describes how to perform a stereo downmix of
mapping family 3, but makes assumptions about the output channel
numbering.  This seems harmful and likely to promote implementations
that make similar assumptions.  If it is necessary to apply the output
channel numbering described in section 3.2 in order to implement a
correct stereo downmix, then it would be better to simply use the
output channels from section 3 as input to the downmix, consolidating
sections 4.1 and 4.2, rather than specify new formulas that make
assumptions about the mapping.  That would also greatly simplify
section 4.

Eliminating the Output Channel Numbering table as Jean-Marc suggests
should resolve these concerns.

On another note, unless I am missing something, the formula in figure
2 does not appear to be correct.  For example, according to the
formula, k=3 (ACN 2) corresponds to order 0 degree 2, which does not
make sense.  It is also not clear why this channel index begins at 1,
when all others begin at 0.  It might also be a good idea to clarify
that this is an output channel index, as other uses of channel index
in RFC 7845 refer to decoded channel index (and also begin at 0).

 - Mark