Re: [codec] Benjamin Kaduk's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)

Jan Skoglund <> Mon, 06 August 2018 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCD1F130E5B for <>; Mon, 6 Aug 2018 10:43:48 -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 I8ivAVqIdbum for <>; Mon, 6 Aug 2018 10:43:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 576A6130E60 for <>; Mon, 6 Aug 2018 10:43:44 -0700 (PDT)
Received: by with SMTP id o11-v6so14559185wmh.2 for <>; Mon, 06 Aug 2018 10:43:44 -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=yteImpgN5MAzEO0xurEQ9OIBtpqVEoN1mW3Wh2RRrtk=; b=jrhdc0exUZLYn/SGqA3UF1yMhQQURgiKgsYp2AJQaKoeCoUyDjyWIanrlMJSVoWUGY Epa9wn4CT1NRLuEIdR2CyqvjOzw4epg43446gmjLhLLqEyW4jJ1bfe0xvTvJwtCBjgua 1gbWKJ5kIohgGf9AwLy4zAQEvmtEvLS7nntR200E1e75/7OsBLF6rJ/U+pzBk/3f2Iha mSTQh/0e7VIuCopaYTCPbuzuVzekz1V4D/rwgCxv7pnjuDurwIS/Dlpu7gQpFzfXyZbV G5VWHF7QvQcYaiB/Kugn3oY7aL1Csb/3UPvlQkN4rJZiwWunW6U76PV02tUkF0jP31ag Nfcw==
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=yteImpgN5MAzEO0xurEQ9OIBtpqVEoN1mW3Wh2RRrtk=; b=YvW3HTrDJdvnpoI/aXxVsCEmFCdAkaxXxZoyWsWIuykkADKCPm9YAGnx9A9cEW0nOB L4ccVGZSZ0nl2rXz7tMKAhclSlZJy/3bBvyK5KinlrmW+lTWp1xJvhhoh8lGCR7rk1+N ragjTUIUrmYIIoqCBBxJjwZa6KQ+J1z40iFpalrycsoFhYLkHlljn4bxsRfT3iN08EZ0 lg6d9Yj+sewo8ogM6PQ63RhpzjcYyUzqEASwfkIY/aKj8dozZHdcwG8djjw5Zz7XEwTS mYRVnyYOAlljY54csMmjPyzYf0y2zGzTATD9JTtRn+Gbh+7ybNhbiMzIiNjZPLRN6sQ1 e0sA==
X-Gm-Message-State: AOUpUlFH4urc2I3PLl5gsWvhfkWKxLPLkvcckeenVRPiJcStWNeTHFYU siPEDaS++qxwyxmu3F90NtMoGB5AsM7OEC0gnhsgoA==
X-Google-Smtp-Source: AAOMgpfndau7FSBXAEbLQ1eFIS8w1jRIRo2Mad0M22C7FdEr3Zt7ZkpML498tb3nLJ5PX/1t2wAEt+9X3cqOYc8vozU=
X-Received: by 2002:a1c:3411:: with SMTP id b17-v6mr11995958wma.85.1533577422422; Mon, 06 Aug 2018 10:43:42 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jan Skoglund <>
Date: Mon, 6 Aug 2018 19:43:30 +0200
Message-ID: <>
To: Benjamin Kaduk <>
Cc: The IESG <>,, Tim Terriberry <>,,
Content-Type: multipart/alternative; boundary="0000000000008063d00572c7d1b0"
Archived-At: <>
Subject: Re: [codec] Benjamin Kaduk's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)
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, 06 Aug 2018 17:43:49 -0000

Thanks for the comments! Our responses are inline below. A new version of
the draft has been uploaded.


> I see that Section 5.2 attempts to Update RFC 7845 to allow for the larger
> channel mapping information used by family 3, but I'm still a little
> unclear about what behavior I should expect from a pure RFC 7845
> implementation that receives a family 3 stream.  The actual mapping table
> would be "too long", but would the implementation detect that, or just note
> that it's an unrecognized family and generate silence?

This is the reason the changes below to 7845 are necessary. I.e., not
interpreting as channel mapping family 255, and instead “A
demuxer implementation encountering a 'channel mapping family'
value that it does not recognize SHOULD NOT attempt to decode the
I think that, depending on implementation, an old decoder would interpret a
Q15 value as an index and either, most likely, decide the value to be
invalid and not decode, or, if the index is lower-valued, decode the
streams according to the old rule
“If 'index' is less than 2*M, the output MUST be taken from
decoding stream ('index'/2) as stereo and selecting the left
channel if 'index' is even, and the right channel if 'index' is
odd. If 'index' is 2*M or larger, but less than 255, the output
MUST be taken from decoding stream ('index' - M) as mono. If
'index' is 255, the corresponding output channel MUST contain
pure silence”
So, it would either decode and play an unintended mixing, or not produce
audio at all.

> Section 1
> I think we want to say "by adding itesm with values 2 and 3" to the
> registry, since we add two entries and not a single superposed entry.


> Section 3.1
> While I can deduce this from the list of allowed numbers of channels,
> noting that both ends of the range (0 and 14) are allowed values probably
> would add clarity.

It is now written as ”n = 0, 1, …, 14” , which we feel that most readers
will interpret such that all integers in the given range, including 0 and
14, are valid.

> Section 3.2
> Figure 3 could perhaps make it more clear that C and K are not necessarily
> equal.
We feel it's sufficiently clear in the figure, since the endpoints of the
vectors, and the rows and columns have specifically differently named
values (C and K). Added a mention in the paragraph.

> The term "side information" is used without definition (and is not used in
> RFC 7845).  Does this clause really add anything in comparison to if we
> just say "The matrix MUST be provided in the channel mapping table portion
> of the identification header, in place of a normal channel mapping table"?

> Section 5.1
> Family 255 is specified in Section of RFC 7845, not
> (Also, the unqualified Section references should probably all be of the
> form Section N of RFC 7845, for the benefift of the HTML linkification
> tooling.)


> Section 8
> Sometimes I see a "Description" column that allows for in-registry
> visibility that a range is for experimental usage.  I suppose it would not
> be too hard to also modify the registry structure to add such a thing, if
> you want.
Perhaps, but I’m afraid I wouldn’t know how to do that:)