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

Jan Skoglund <jks@google.com> Mon, 13 March 2017 23:39 UTC

Return-Path: <jks@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 EA8FF129C14 for <codec@ietfa.amsl.com>; Mon, 13 Mar 2017 16:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: 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 QGmC9ZpFtPTE for <codec@ietfa.amsl.com>; Mon, 13 Mar 2017 16:39:19 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 65CEE129673 for <codec@ietf.org>; Mon, 13 Mar 2017 16:39:19 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id i34so44426662qtc.0 for <codec@ietf.org>; Mon, 13 Mar 2017 16:39:19 -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=7uzmxfKS4WBesmaPUiVt199yq+hE/45KWWZZmOLsipY=; b=d7j5l6+FVAfxaF61rNCcjf8bfFp6wO/yAPCcTkT+Dgd3GrZa+p1vAIyc15hxpl3Qls VFOQSElx2At0P17OG0gTn7X4UMnFsi11FQTHGLdV4kvyi1oaOOKcgCrSBi/wnuB5MDl5 JO9xNWzS2+SNjCISkBr+5O0p4pZAYX50UfhUpFVs8JL2rxpFoLNTN4L6Gp9Npi2UYxIZ civKRimDII08uHr3CwFbf50mK8UJSQ9szbN2BfvfZ9/9CsvY2206vDGQrediKlm6El22 HX73kQOxCuoluFukPK+ZRBB8JJe9rOKcLZVHyLJKEHhK7nIeFMZYVvYXEMdEQ43cwriW evNg==
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=7uzmxfKS4WBesmaPUiVt199yq+hE/45KWWZZmOLsipY=; b=RctmkUAJAOyL9In7C/NAlHCjbVshgg4rWvB2Z28Td0a6OlkVyeLVe8n/QLJdzt+V4Q XY7vBpyp7lNvriJs4kHwPZUokcVgvG4szQQxcKLF9a1UoJBQg/mOH3OAAS0ZdB6GRKy5 hBP0cqYYm1G6/XSP2xOPA7T65T07/2MvefMeiJQH7g8bayJlpkASvKqltVHgvj+zZyqW 95cB6FOXcGW7RimgSKx52wCLqHAg11EQBhLmEzaxPQwfvs4kEX6rRNCjW+sQvi9k+yhz s23wACOokFEhZqNyxBeWHRJVg49tjxdvhPgURCnSa2WZLP7yWjqfex5quVUONmlPqHNS YDOQ==
X-Gm-Message-State: AMke39mh4suj1SksEavZBCMdEcBNbpxHPUBVgFJodUD+oSKa7d6RICkBIpD4HFC408aIvcHAiQWXIw4mdvsPts/x
X-Received: by 10.237.57.164 with SMTP id m33mr37098754qte.293.1489448358361; Mon, 13 Mar 2017 16:39:18 -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> <CABQ9DcuD+Et6+rBG-rCnWX-Dk-9STZMeYs-6fQWTk1kyjigRhw@mail.gmail.com> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> <CABQ9Dcu0JVuAFvThSOgiBzxa+QOD4-1zpLzX6i-RKG7SRJnkNg@mail.gmail.com> <CABQ9Dct0d4id7wnzyu4sQHU=HZFVjCOXHCTO_F5RHcfE7HdH1Q@mail.gmail.com> <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> <CA+KMCSVPHoav7QzdnvV5_TB2wFidkML0Z2+kp4VpJCU16N1+5Q@mail.gmail.com> <ebae7987-a8c2-befc-0d95-9f2b131916a6@jmvalin.ca> <CA+KMCSVdAG=q_LDhFg7OcKqBbN+6Dbaz-1Bjv6tRji9+d_PktA@mail.gmail.com> <2480dd55-eaef-9376-c88a-d764d777dfad@mozilla.com> <58C7260F.6030506@xiph.org>
In-Reply-To: <58C7260F.6030506@xiph.org>
From: Jan Skoglund <jks@google.com>
Date: Mon, 13 Mar 2017 23:39:07 +0000
Message-ID: <CA+KMCSWC4cJuWkDOqzFuVY5hL+Ewe_QtAWaM9TjAmC7XOJOSMA@mail.gmail.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>, Jean-Marc Valin <jmvalin@mozilla.com>, Jean-Marc Valin <jmvalin@jmvalin.ca>, Drew Allen <bitllama@google.com>, Mark Harris <mark.hsj@gmail.com>, "codec@ietf.org" <codec@ietf.org>
Content-Type: multipart/alternative; boundary=001a11410306501867054aa538a9
Archived-At: <https://mailarchive.ietf.org/arch/msg/codec/-8hC2yxllLwsSupDduamvbO1dTc>
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 23:39:24 -0000

Thanks Mark, Jean-Marc, and Tim,

It makes sense to use the table already defined in RFC 7845, which then
automatically allows mixed order also for family 2. We'll remove the
"channel numbering table" for family 3.

Cheers,
Jan



On Mon, Mar 13, 2017 at 4:06 PM Timothy B. Terriberry <tterribe@xiph.org>
wrote:

> Jean-Marc Valin wrote:
> > For family 3, if you already have a Cx(N+M) weight matrix, then the
> > mapping table becomes completely redundant.
>
> I think the issue boils down to whether it's worth it to have a table of
> size C to allow a matrix of size Kx(N+M) instead of Cx(N+M) in the
> headers where D is some number smaller than C (probably D=N+M). If more
> than 80% of your matrix is filled with zeros (100 out of 121 rows for
> 10th order with only horizontal channels), that could be seen as a
> little wasteful.
>
> That said, we very intentionally chose the direction of the channel
> mapping table for RFC 7845: one value per output channel that says which
> decoded channel to use. That makes it impossible to send multiple
> decoded channels (mixed channels after multiplying by the weight matrix
> in this draft) to the same speaker (ACN number in this draft). As Mark
> Harris points out, this is a failure case the current draft doesn't
> specify how to deal with. By doing the mapping in the same direction as
> RFC 7845, the worst failure case is that someone specifies a channel
> index larger than what's actually available, but that's easily
> detectable (i.e., you can tell without having to look at any other
> values in the mapping table). You also don't need to handle the diegetic
> channels separately. There is a special case for silent channels, but as
> a benefit it become easy (O(1)) to tell if a channel isn't used.
>
> Having the mapping work in this direction would also be more consistent
> with Channel Mapping Family 2.
>
>