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

[Jan Skoglund <[e-mail]>]

Hey,

Thanks for your comments

On Mon, Mar 13, 2017 at 10:08 AM Mark Harris <[e-mail]> wrote:

> 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.
>

The problem is that once we allow mixed orders there is no unique way for a
receiver/decoder
to resolve the mapping to ACNs from just a number of total output channels.


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).
>

You're completely right, and there's no reason why the channel index should
start with 1.


 - Mark
>