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

Ralph Giles <giles@thaumas.net> Fri, 10 August 2018 00:22 UTC

Return-Path: <giles@thaumas.net>
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 1DE93130FE6 for <codec@ietfa.amsl.com>; Thu, 9 Aug 2018 17:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thaumas-net.20150623.gappssmtp.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 X0Rc1MAB2JEl for <codec@ietfa.amsl.com>; Thu, 9 Aug 2018 17:21:57 -0700 (PDT)
Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 27CBE130FE9 for <codec@ietf.org>; Thu, 9 Aug 2018 17:21:57 -0700 (PDT)
Received: by mail-pl0-x22d.google.com with SMTP id f6-v6so3254659plo.1 for <codec@ietf.org>; Thu, 09 Aug 2018 17:21:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thaumas-net.20150623.gappssmtp.com; s=20150623; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=oh47qQaQq5GoSOkgQ1aT7WapkeVeeUtbTkAzTecJbtE=; b=kEQeHKFei2AKGCiJykB7uOWDoogTnX9rowNMiFPReN9hGOoMRIeffTQVPwlfOlPZFC MM2fLRImn96BqGSsZarNpp/ACxUXWGnv3EKzKliaJJNnoKVjYN8aKk53tLG9yX54lQQM VQggy2/aJwCdIn6MXLa3Lgpz4rYK9hGVKxYvN8uw0gZkCMAmRAUxyH535Is97DaTU3y/ xBkotv49vIDgnkXB725UKRo9O0yeD6jcrwIwDJj2G6d/0lZ2+p6dekWJh4uc7P25rtsF MPo0CRFjE8sqB0JlTtTDO21Rt6t/H+DsRqZ2wpFrLC5QB60ZMPbmhvHHAgBR4Pr2HaHV r+FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=oh47qQaQq5GoSOkgQ1aT7WapkeVeeUtbTkAzTecJbtE=; b=qE0J5W6NJgtmX60fyA3tn6bN5S66uHsggOEkAFnEtb1eb5qe7cWAEtDgFaMtTX9zVy nxt87opTFDT1i67IlYVWHGJk89E+KfNohWhrTfu/uFUG43vogogYyQmwcGb5meOlHTMy Royfdc0r871uJRltapDwzOQLSA3HpbHD/BxYsBKSnMzVh6ay7tL89e076gONcakb9H5C TdGiTIQtmQqTmUyUcAjmUTvc6pFhhySbnLt5c7oo9ob9dVSMX7GXGxU3247LoEDJ/zMp Fwx+qVDR+4cVj6Aj+Vm/+VL4u1POBrDJlYCJkw7khc9cVXwH/zBNxCAnqzJEEjzkSdII +Rlg==
X-Gm-Message-State: AOUpUlEc4jMYmAfmfSeC8m6FhaZiostsvzm1fHZQ5aWTy6df+GFPOHuw dXTxkkek7HE8gO3fmrlO9DFDwA==
X-Google-Smtp-Source: AA+uWPx9GKiuE4wxVJ+da9ykvJb4aTKdM3OLtj/B3bgN1K0WKfFmRIv63Nfxmbn/XYwBBs53JgeYvg==
X-Received: by 2002:a17:902:33c2:: with SMTP id b60-v6mr3931737plc.11.1533860516552; Thu, 09 Aug 2018 17:21:56 -0700 (PDT)
Received: from [192.168.1.215] (S0106185933484486.vc.shawcable.net. [174.7.172.49]) by smtp.gmail.com with ESMTPSA id d191-v6sm14349886pfg.172.2018.08.09.17.21.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 17:21:55 -0700 (PDT)
To: codec@ietf.org, draft-ietf-codec-ambisonics@ietf.org
Cc: Jan Skoglund <jks@google.com>, Tim Terriberry <tterriberry@mozilla.com>
From: Ralph Giles <giles@thaumas.net>
Message-ID: <a36133dd-621c-df02-a0a9-8918b1ba0f30@thaumas.net>
Date: Thu, 9 Aug 2018 17:21:42 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/codec/ns_xa_KQWs7IdS0VjwDCPIMQZWk>
Subject: [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, 10 Aug 2018 00:22:01 -0000

Hi,

I was asked to look at the ambisonics draft as a designated expert for 
the Opus Channel Mapping Families IANA registry.

First, thanks for writing this up. It's exciting to see ambisonic 
support for the Opus codec!

Channel mapping family 2 looks good to me. The change is documented in a 
proposed RFC. It defines the allowed number of channels, re-uses the 
channel mapping table from Ogg Opus RFC 7845, so I don't see 
interoperability issues. The draft explains how to map decoded channels 
to the correct ambisonic order and degree. I believe that fulfills the 
specification requirement.

The actual definition of the spherical harmonic expansion of the sound 
field is a conference paper. The paper appears to be publicly available. 
But, since this is a normative reference, it might be nice to reproduce 
at least a sketch of the relevant functions within the draft in case 
that reference becomes harder to obtain. It also wasn't clear to me, as 
someone without specific ambisonic knowledge what the annotations on the 
definition in the reference meant. Of course it can be painful to 
include complex equations in an RFC.


For mapping family 3, I'm concerned by the way the matrix is signaled.

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.

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.

As you noted in your response to Eric Rescorla's comments, replacing the 
RFC 7845 channel mapping table with the mixing matrix entries means that 
a decoder based solely on that RFC could either produce a random mix of 
of the ambisonic channels, or reject the header as invalid, depending on 
how the mixing coefficients match up with the available decoded streams 
when interpreted as bytes.

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?

Such a table could be all 255 values, to indicate no output, but 
probably SHOULD consist of a 1:1 mapping, with values 0,1,..,C-1. That 
way something like Digital Audio Workstation software written just 
against RFC 7845 could still load the coded tracks, even if the mix and 
interpretation as ambisonic signals is lost. That kind of compatibility 
was the intent of Section 5.1.1.3 of RFC 7845.

Decoders still MAY reject the stream because they don't recognize the 
channel mapping family field, or because they think the id header is too 
large. Players still SHOULD NOT play it based just on an unrecognized 
mapping family field.

If you want to completely block incompatible decoders, you could also 
bump the 'version' field in the id header.


Reserving mapping family values 240...254 for experimental use seems 
reasonable to me. I don't foresee much pressure on namespace allocation, 
and the number of reserved entries is appropriate.

You could reference the "experimental use" policy in Section 4.1 of RFC 
5226 here.


I don't see an Implementation Status section (as recommended by RFC 
6982). Are there multiple implementations of this draft? Test vectors?


I hope this review is helpful,
Ralph