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

Jan Skoglund <jks@google.com> Mon, 06 August 2018 17:43 UTC

Return-Path: <jks@google.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 CCD1F130E5B for <codec@ietfa.amsl.com>; Mon, 6 Aug 2018 10:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 I8ivAVqIdbum for <codec@ietfa.amsl.com>; Mon, 6 Aug 2018 10:43:47 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 576A6130E60 for <codec@ietf.org>; Mon, 6 Aug 2018 10:43:44 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id o11-v6so14559185wmh.2 for <codec@ietf.org>; Mon, 06 Aug 2018 10:43:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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: <153297931466.7637.15045953147147693291.idtracker@ietfa.amsl.com>
In-Reply-To: <153297931466.7637.15045953147147693291.idtracker@ietfa.amsl.com>
From: Jan Skoglund <jks@google.com>
Date: Mon, 6 Aug 2018 19:43:30 +0200
Message-ID: <CA+KMCSVVrNbZkqC_8UZr72EsGfD+9Jpt3Oan3iQ=R7B0nUJr+A@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry <tterriberry@mozilla.com>, codec-chairs@ietf.org, codec@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008063d00572c7d1b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/codec/V0p0S73EWpp1mrPuGZ2WLiBYDwM>
Subject: Re: [codec] Benjamin Kaduk's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)
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: 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.

Cheers,
Jan


> 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
packets“
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.
>

Changed.


> 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"?
>
>
Changed.


> Section 5.1
>
> Family 255 is specified in Section 5.1.1.3 of RFC 7845, not 5.1.1.4.
> (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.)
>

Changed.


> 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:)