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 <mark....@gmail.com
> <mailto:mark....@gmail.com>> wrote:
> 
>     On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund <j...@google.com
>     <mailto:j...@google.com>> wrote:
>     > Hey,
>     >
>     > Thanks for your comments
>     >
>     > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris <mark....@gmail.com
>     <mailto:mark....@gmail.com>> wrote:
>     >>
>     >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin
>     <jmva...@jmvalin.ca <mailto:jmva...@jmvalin.ca>>
>     >> 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
>     codec@ietf.org <mailto:codec@ietf.org>
>     https://www.ietf.org/mailman/listinfo/codec
> 
> 
> 
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
> 

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

Reply via email to