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

Jan Skoglund <> Mon, 13 March 2017 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF8D6129981 for <>; Mon, 13 Mar 2017 10:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VUzn_WLub-6y for <>; Mon, 13 Mar 2017 10:39:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8026C129979 for <>; Mon, 13 Mar 2017 10:39:06 -0700 (PDT)
Received: by with SMTP id i34so37455279qtc.0 for <>; Mon, 13 Mar 2017 10:39:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nRqjYh1HABeNwiq08c3Ei10P2OkmZziMFoLI+g+mP1Q=; b=VjTtBY+D6J/X22gHkXdB8nsyv4zis2+zEj85oDofJNwW/5gOGG278SXdyxmAX/yRRD LCZJoe604lg+uxdSwlDPI5VF9LnqhX8mgK0rYkcF0f2AwHjvf56OBEaBFqKExoQ4Ceew 6ZW9pWR/qhgDbnOVET3mLjXEhP5Jr0ns+aSDZCjMi3plkxK1yUYJXrjlf3N9x1xd0vXo c2yZd3H3pEze5UsO+tYPwITO5odV79T4ULR0C9Iz6wN7TXGluNKRXxruhrVPPeUW/qG+ vs0/Pu3RCzitIWXjukFM0mN2uCtmWPwwocWdmXeQvDASIog+Zzj+w1GKY5gAtbmBI71q +9RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nRqjYh1HABeNwiq08c3Ei10P2OkmZziMFoLI+g+mP1Q=; b=Lx9kjgB+uae1cEU1VctCrvBoR39FVJ/hKcFOZxEXG9cKRowy7TDLsM8Kgd6F5GK3lW cFAGxJzl1asGNF2VHXIVXqAG0NRFaMCllK3ySc4641Vboqs86EQqZU0l1aLj3Gez3Wwh gvMutY+sUincpj8OYkC1XFNjKQWH9dynSbidjZoCWk+RkZirL6/Hc5ZUxibTWfEwAUMQ p65FNE7QJ78UJhGee05meXQjMXfbfSjUFN3qfLuPvh4xsuR7NnP6sv0YZoFlRFxijoQh 2wdxHtMCzWf4EggTaGGvR02SbftsB0st729LhqferDHB8vfBEW1Z1CaqYRYnXfzpxlZJ zWHw==
X-Gm-Message-State: AMke39lmYpO4tCXlMFLOwczoLYyqSFssKmR5TlBGT3M+jBykH9QkRvMSKmeqEs6N2l/qHLD9twNa5rsLZkZRlsuw
X-Received: by with SMTP id m33mr35587856qte.293.1489426745430; Mon, 13 Mar 2017 10:39:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Jan Skoglund <>
Date: Mon, 13 Mar 2017 17:38:54 +0000
Message-ID: <>
To: Mark Harris <>, "" <>
Content-Type: multipart/alternative; boundary=001a1141030614ff0e054aa0307e
Archived-At: <>
Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Mar 2017 17:39:12 -0000


Thanks for your comments

On Mon, Mar 13, 2017 at 10:08 AM Mark Harris <> wrote:

> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin <>
> 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
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