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

[Jean-Marc Valin <[e-mail]>]

On 13/03/17 06:17 PM, Jan Skoglund wrote:
> Our idea was to avoid a mapping table, potentially sparse, completely
> for family 2, and replacing it with a channel numbering list for family 3.

Can you explain what you mean here by "avoid a mapping table" for family
2 and "channel numbering list" for family 3?

	Jean-Marc

> Cheers,
> Jan
> 
> On Mon, Mar 13, 2017 at 3:12 PM Jean-Marc Valin <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     On 13/03/17 06:04 PM, Drew Allen wrote:
>     > so just to be clear, if a user, say, wants to encode some mixed order
>     > ambisonics using ch253, how does the decoder know what ambisonic
>     > channels it has received and know how to render them correctly?
> 
>     Well, each line of the matrix would correspond to a channel in the
>     ambisonics channel order. If that channel isn't encoded, then the line
>     would have only zeros.
> 
>     The only way to avoid that situations would be to encode a separate D
>     value (D <= C) for the number of non-zero channels among the C
>     ambisonics channels possible. Then you'd store C values in the channel
>     mapping array (equivalent to a CxD permutation matrix), followed by a
>     Dx(M+N) weight matrix that would no longer have entire lines of zeros.
>     The result would be more compact in the case of sparse representation,
>     but IMO it'd be pretty ugly and prone to implementation errors. And if
>     you force D==C and don't code the D (which is what I'm proposing), then
>     the channel mapping permutation automatically becomes redundant.
> 
>     Cheers,
> 
>             Jean-Marc
> 
>     > On Mon, Mar 13, 2017 at 3:00 PM Drew Allen <[e-mail]
>     <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>     >
>     >     Got it. In that case, it certainly seems reasonable if I
>     understand
>     >     correctly. Thanks for clearing that up!
>     >
>     >     On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin
>     <[e-mail] <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>     >
>     >         On 13/03/17 05:44 PM, Drew Allen wrote:
>     >         > I think the issue is that the number of total channels rises
>     >         > quadratically in respect to the ambisonic order (N +
>     1)^2. If
>     >         a user
>     >         > wants to use just the horizontal channels, it is only 2
>     * N +
>     >         1. If they
>     >         > wish to code very high-order (>10th order) horizontal
>     >         channels, they
>     >         > would be artifically limited by all the zero channels being
>     >         produced,
>     >         > no? Or can this handled without actually creating all those
>     >         empty channels?
>     >
>     >         As far as I understand, the current draft already has all the
>     >         limitations you're describing. The channel mapping array is
>     >         basically
>     >         equivalent to a CxC permutation matrix that multiplies the
>     Cx(N+M)
>     >         weight matrix. The result is still a Cx(N+M) matrix, so
>     using the
>     >         resulting matrix as weights can still do everything
>     without the
>     >         need for
>     >         the channel mapping to do the permutations.
>     >
>     >         Cheers,
>     >
>     >                 Jean-Marc
>     >
>     >         > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris
>     >         <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >         > <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>> wrote:
>     >         >
>     >         >     On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund
>     >         <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >         >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>> wrote:
>     >         >     > Hey,
>     >         >     >
>     >         >     > Thanks for your comments
>     >         >     >
>     >         >     > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris
>     >         <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >         >     <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>>
>     >         wrote:
>     >         >     >>
>     >         >     >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin
>     >         >     <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >         <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[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.
>     >         >
>     >         >
>     >         >     In mapping family 2, the channel count (C) is the number
>     >         of channels
>     >         >     in the fully periphonic configuration, but it is not
>     >         necessary to
>     >         >     encode them all.  The channel mapping table can map each
>     >         ACN to a
>     >         >     specific decoded channel or to silence.  For mixed
>     order,
>     >         some of the
>     >         >     ACNs will be mapped to silence and will not be encoded.
>     >         >
>     >         >     In mapping family 3, the matrix can do everything
>     that the
>     >         channel
>     >         >     mapping table can do and more.  Why not treat C in the
>     >         same manner, as
>     >         >     the number of channels in the fully periphonic
>     >         configuration, even if
>     >         >     some are silent?
>     >         >
>     >         >      - Mark
>     >         >
>     >         >     _______________________________________________
>     >         >     codec mailing list
>     >         >     [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >         <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>     >         >     https://www.ietf.org/mailman/listinfo/codec
>     >         >
>     >         >
>     >         >
>     >         > _______________________________________________
>     >         > codec mailing list
>     >         > [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >         > https://www.ietf.org/mailman/listinfo/codec
>     >         >
>     >
> 
> 
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>