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

Drew Allen <bitllama@google.com> Mon, 13 March 2017 21:44 UTC

Return-Path: <bitllama@google.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599E9129477 for <codec@ietfa.amsl.com>; Mon, 13 Mar 2017 14:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEqDZ_8SyPj6 for <codec@ietfa.amsl.com>; Mon, 13 Mar 2017 14:44:32 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDC9127058 for <codec@ietf.org>; Mon, 13 Mar 2017 14:44:31 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id y193so69171414lfd.3 for <codec@ietf.org>; Mon, 13 Mar 2017 14:44:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eSwfDCW1+DQ34ed+iyz6fqGrO/MQ00uZpN68mfAqnRE=; b=oyTKQw2Gp2BvcY3DaQ2TE6K/njFcjtXsaLZyqUskkG2eZpAw57HnP0GYll4dCWX2Pb VPJ6XZTWD9NHHAv5dRFgk3d3Tj472PUtbS2B0n52uD/mit5JGo0b2EkxTgmMC5zGx8sT L58RedF6z5xXOkIzBFLzXkHDc6uT05MNJ5RXJwU5dcEmxKWVUdliqO5G9Bl9lhYPVMPv Dt1paFQTeDfsJcfRtWJQG4JFznmrA0ejjOIDmGIL4NGvJYKbVEf7fA6sOJBKOTv8Gjnz Je6+fxOTmz5hkL9OECqq/+LYuSBBHs/qbRXsQYCAjbCblNiF8QiJTRoOwnjAodnLgxJu RJJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=eSwfDCW1+DQ34ed+iyz6fqGrO/MQ00uZpN68mfAqnRE=; b=jO/1JrbzBax7nzmnaMcblXe3wLt9ikY7OekOPTH2pPo+lCZFoXoYDNAPSoYvwnNhDQ nCip0fvpvkU/56cicG3A2ay+BENkXnkAL/xm388AMxFzhN8CGq8/P2m1i0Dp8CKN3Dit lt+NU6W6JmQVr2gls4t3NyRICZaoXmN5livI4GogvZwxG1GGxUXwpmAUVsSECfBfU6Xt D/IwyZKOfpdp+++0MnSPWYpr2Gb+noLG2HSAvtJ1PQBAONNmqAcj1ZjqLDvwSnFk30DV a2ILMcdkBc+sdH4fP3v5rKK88GYsrN51XviOeaowcSgGCXR8mtlYlLALRfp0T4MoB4lZ oE8Q==
X-Gm-Message-State: AMke39lXWPsfF1ORnIexvc1MTl37MCjyN0L1bsNFucsuQv6k6ZmZI21gCkw2uwGtmdbz0XfKHExl7+N3xWnIgkTZ
X-Received: by 10.46.77.72 with SMTP id a69mr10864299ljb.104.1489441470079; Mon, 13 Mar 2017 14:44:30 -0700 (PDT)
MIME-Version: 1.0
References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <CAMdZqKGzdndiwpdXsYcHS7+r8Ega5LcQmAvcjiuHTHJgtTUwDg@mail.gmail.com> <CA+KMCSXhS2m4Dkous=4RkOibYWuoi+V_zBrhi1+anm-c+syQ1Q@mail.gmail.com> <CAMdZqKFDtD684HMkoO9bXi-c+g+8R+ay9kPdWSQOtHFDbC3ZLA@mail.gmail.com>
In-Reply-To: <CAMdZqKFDtD684HMkoO9bXi-c+g+8R+ay9kPdWSQOtHFDbC3ZLA@mail.gmail.com>
From: Drew Allen <bitllama@google.com>
Date: Mon, 13 Mar 2017 21:44:19 +0000
Message-ID: <CABQ9DcuD+Et6+rBG-rCnWX-Dk-9STZMeYs-6fQWTk1kyjigRhw@mail.gmail.com>
To: Mark Harris <mark.hsj@gmail.com>, Jan Skoglund <jks@google.com>, "codec@ietf.org" <codec@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1aba80bd20d4054aa39def"
Archived-At: <https://mailarchive.ietf.org/arch/msg/codec/wGif5qoqvDHJhI-YhlQUFE6POsE>
Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2017 21:44:34 -0000

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?

On Mon, Mar 13, 2017 at 2:41 PM Mark Harris <mark.hsj@gmail.com> wrote:

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