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

Ben Campbell <ben@nostrum.com> Fri, 24 August 2018 20:58 UTC

Return-Path: <ben@nostrum.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 3D048130DE9; Fri, 24 Aug 2018 13:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
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 43Q2nW37biNP; Fri, 24 Aug 2018 13:58:00 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3474A130DDF; Fri, 24 Aug 2018 13:58:00 -0700 (PDT)
Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7OKvsAK079945 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 Aug 2018 15:57:55 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <1567B1F0-384A-464A-99C3-460DA8E13FE6@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6C5BCCF6-B014-4A50-A642-56F8A4BAFDFA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 24 Aug 2018 15:57:53 -0500
In-Reply-To: <CA+KMCSX1_i0XPTY01GSYjEkkBA6BEtw6GM+oiSP9ak6DwN05oA@mail.gmail.com>
Cc: Tim Terriberry <tterriberry@mozilla.com>, draft-ietf-codec-ambisonics@ietf.org, IETF - CoDec <codec@ietf.org>, Jan Skoglund <jks=40google.com@dmarc.ietf.org>
To: Ralph Giles <giles@thaumas.net>
References: <a36133dd-621c-df02-a0a9-8918b1ba0f30@thaumas.net> <CA+KMCSX1_i0XPTY01GSYjEkkBA6BEtw6GM+oiSP9ak6DwN05oA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/codec/rRpExPZ7gw-EM8UuVCG7U9wy6lw>
Subject: Re: [codec] IANA Opus mapping comments on draft-ietf-codec-ambisonics-08
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 24 Aug 2018 20:58:02 -0000

Hi Ralph,

Do the responses and updates in version 9 resolve your comments?

Thanks!

Ben.

> On Aug 13, 2018, at 12:53 PM, Jan Skoglund <jks=40google.com@dmarc.ietf.org> wrote:
> 
> Hey,
> 
> 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.
> 
> 
> Cheers,
> Jan
> 
> 
> 
> 
> 
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec