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
- [codec] IANA Opus mapping comments on draft-ietf-… Ralph Giles
- Re: [codec] IANA Opus mapping comments on draft-i… John Ridges
- Re: [codec] IANA Opus mapping comments on draft-i… Jan Skoglund
- Re: [codec] IANA Opus mapping comments on draft-i… Ben Campbell