Re: [codec] IANA Opus mapping comments on draft-ietf-codec-ambisonics-08

Jan Skoglund <> Mon, 13 August 2018 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 030A9130E43 for <>; Mon, 13 Aug 2018 10:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D1344J90Rk-f for <>; Mon, 13 Aug 2018 10:53:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE4CA130E08 for <>; Mon, 13 Aug 2018 10:53:43 -0700 (PDT)
Received: by with SMTP id j5-v6so14988835wrr.8 for <>; Mon, 13 Aug 2018 10:53:43 -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 :cc; bh=ih9ykLv73O8gxPlXHdUOkk+WwSScuvCoAGY1pzwM7dQ=; b=Wek+qKR651pAd7WWostmbe0OAVOqQXxzH14lVJS1H3KElZmdD5nJk2ZUucrdKFL/vp c9Q2HWlyIUDAlaHkN85xOi9Xj/KVm3yQ4JHXPHlps8JIpdsjHjayT3maobzfPrI7Ysyl vCu/F5PU165f+BwHrFJ2iTT1CyIITd36dsbJckgwx6YvJT1DLUpJWY3DH8T1oKJY2b0D Yi9ZKZStc+kVwrPZXKHIahweVudFDKTQSUsKj2CskwcHRbnJUgiM1P+KEK4P15/vKEc2 +JbkoZw4FXn02rH9VFy6n2YT5yp2wZxbpUMLZRiJhgR8AxbqGpOWUcCW7UXgoEcbxkPX 52eA==
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:cc; bh=ih9ykLv73O8gxPlXHdUOkk+WwSScuvCoAGY1pzwM7dQ=; b=S418Ofc1oTe6kRLK0f6D6w/c9n2GQVlaLfYIo8CQ5O4AkDFf7YYbAN6OGx+LAdKT+0 w9pdivBlnQK7YXtE3bloK2SDXcsN9IFnVuP173Lll/PB+KCFXjkBZhar34qeDOAJ39ze G0QTeQdbCgipKJ7YJzaz9BU7qSw0lVyTxlDMtZ1aecgKPZETDzgtB4xonu7PEs6jn48q /FQBp0PVlvv5DPD7jyygKQYLtY8ga4RxanmVgVI2+B3aX4m7/zKZK5o8t8IFPpqGAB3C VY6sV2T8k3+RiR4JZBvH8WWRG2b1ZBQY94K7iQ1Rr1WNhcPLOP4FcO+yYhSpwJavZcsf x17g==
X-Gm-Message-State: AOUpUlHR+kPUrWhHe9tuvnTh5f9PUJHjTI9L+6zBQA2qo7KPxyXA18LE WNfriS2ISDPsiJ7FNcfI8hd/bRfusyLMwkqtdtGM9ddr6uU=
X-Google-Smtp-Source: AA+uWPzEEuF6wMw3PALoaRKU6V+Zqbf9TIV1vRsGep2y80AgAu/cKXQOvSoLgsSK9qkR7smQramtuXxhcJ/tTSmIb78=
X-Received: by 2002:adf:b786:: with SMTP id s6-v6mr11455504wre.247.1534182821807; Mon, 13 Aug 2018 10:53:41 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jan Skoglund <>
Date: Mon, 13 Aug 2018 10:53:29 -0700
Message-ID: <>
Cc: IETF - CoDec <>,, Tim Terriberry <>
Content-Type: multipart/alternative; boundary="0000000000001da387057354c64b"
Archived-At: <>
Subject: Re: [codec] IANA Opus mapping comments on draft-ietf-codec-ambisonics-08
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Aug 2018 17:53:47 -0000


Thanks for the comments!

> You say the mixing matrix is "stored column-wise." I assume this means
> the order of the coefficients in the file is D11, D21, ..., DC1, D12,
> D22, ..., D1K, D2K, ..., DCK. Is that correct? Since matrix
> representation conventions vary, I suggest being more explicit here,
> perhaps by listing a few coefficients in figure 4.

Changed to the more prevalent notion "column-major order"

As you note at the end of section 3.2, the identification header must
> fit within a single page as described the Ogg Opus RFC 7845. This is
> also in the Ogg Format RFC 3533 (section 4, third paragraph). Violating
> this constraint will definitely cause interoperability problems. I'd
> like to see the language about this strengthened to a MUST limit on the
> packet size and some guidance given about maximum order and channel
> indexes for common configurations. Section 3.3 should be updated to
> mention this as well. It would be an easy thing for implementors to
> overlook.

Section 3,2 changed to MUST for 12th order, if full order is used. This is
also repeated in Section 3.3.

> However, the RFC 7845 channel mapping table is only 'C' octets long, the
> length of half a row of the mixing matrix. It seems to me encoders could
> insert a compatibility table before the matrix coefficients without
> adding much to the encapsulation overhead or limiting the mixing options
> much. Was this considered by the working group?

This has not been considered. The structure proposed in the draft has been
implemented into Opus.

> I don't see an Implementation Status section (as recommended by RFC
> 6982). Are there multiple implementations of this draft? Test vectors?
This draft has been implemented and is fully available in the official Opus
repository. An experimental flag was recently removed. No specific test
vectors have been produced.