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

Jan Skoglund <jks@google.com> Mon, 06 August 2018 17:33 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 7B774130E58 for <codec@ietfa.amsl.com>; Mon, 6 Aug 2018 10:33:45 -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 Ovqx8YTI4xdf for <codec@ietfa.amsl.com>; Mon, 6 Aug 2018 10:33:42 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 3A1A5130DF0 for <codec@ietf.org>; Mon, 6 Aug 2018 10:33:42 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id o18-v6so15266177wmc.0 for <codec@ietf.org>; Mon, 06 Aug 2018 10:33:42 -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=h8JDLUxNNzmYuUlMZ7IgzJe7t9q9AXYKYHUtrko5u4c=; b=RxNkvk7gHwYZB5ajF6+mK6zfd/s8RoakyeOMU/OZsM4+6EweUpaFg5ScgMjRYnq6e+ bRaWwJUKIKQt3ETTfOQb9udPoj7pS8et6snuMjKhV+cTWJFhfJUT5urFrwkSq1IpPNtA Sldlncr2Im4vzTnLn3pQmU4wj81iKf+lWUQ8o1R5AzaSb76bFI/coVwUsChdBG4FnBZS Mtkmj9VPqclwub2T6Dux6gdAFlbsQ6Fy3l2qku03pUE2sxI3Po0969LxyFjJIPBV9J2V uQbQwoFSrJkjBob6DeKZLI3mhjqUUhdB1MKidMXte3gn2/CXkLPIgtk+hcGefV/y54gG Gw9A==
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=h8JDLUxNNzmYuUlMZ7IgzJe7t9q9AXYKYHUtrko5u4c=; b=EDMskImfiNIN+8JrtxXsdKYV3pvjvGV5olKJzu0bHzZ2SZe1KaPPl/TL4PX/ZR4aXZ BEcIansOUqxv7qwMyJghuqpcKWzSf316ZWhoVHHDa9JRstmT69bkScE3CW+cwn7YVVmd gdEbClNTUWdVznuqb0lvoqkjJFarey7U9ZyQafi5FvCLaiBxe5DEmf2UfcXyWR/X18BL zWsyiz/+8o8LlmHu9qNEMSivbZnhukgZ5GoWASVWk9xKHd47Knw1UBuqBec8oCUiucuc mDhYpPr13jk334ZRirL9b5QqtJdy9OvHPxDzNw0UYqdDPdU3eR45dlht59JhVinqMZ6O TQJg==
X-Gm-Message-State: AOUpUlHS8RLNAXqUgHFzqw8DXxkKK9/qU8wz9franCJAWm2+R3nGAsWS XMIZUj/F/XH+9MNfTdhXir9RQnr5+4B3IzzPMwymVg==
X-Google-Smtp-Source: AAOMgpf/KxZYYxAXDAE0lQpXuY7Sx2YEZtkjomArPdXfT6qQqdh82LwTPwiXVk7/uJC4Q8W6huDe0EByLWJ9j3Jg9y8=
X-Received: by 2002:a1c:9bc5:: with SMTP id d188-v6mr12749982wme.33.1533576820242; Mon, 06 Aug 2018 10:33:40 -0700 (PDT)
MIME-Version: 1.0
References: <153295358610.1069.2720875646830940452.idtracker@ietfa.amsl.com>
In-Reply-To: <153295358610.1069.2720875646830940452.idtracker@ietfa.amsl.com>
From: Jan Skoglund <jks@google.com>
Date: Mon, 6 Aug 2018 19:33:28 +0200
Message-ID: <CA+KMCSWg366hoC+kit+NCLDU33YR7UBY-mv0Xyh9oXUNsM55eA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry <tterriberry@mozilla.com>, codec@ietf.org, codec-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009bd8ee0572c7addc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/codec/Vj-s5neNgIwn9OsL96GepAEekCQ>
Subject: Re: [codec] Eric Rescorla'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:33:46 -0000

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

Cheers,
Jan


> S 3.2.
> >                                                        | Stream Count  |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        | Coupled Count | Demixing Matrix                               :
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >          Figure 4: Channel Mapping Table for Channel Mapping Family 3
>
> Are you saying I MUST use family 3?
>
>
No, we say that if you use family 3 you MUST provide a matrix in the
channel mapping table.


> S 5.2.
> >         The remaining channel mapping families (2...254) are reserved.  A
> >         demuxer implementation encountering a 'channel mapping family'
> >         value that it does not recognize SHOULD NOT attempt to decode the
> >         packets and SHOULD NOT use any information except for the first
> 19
> >         octets of the ID header packet (Fig. 2) and the comment header
> >         (Fig. 10).
>
> What is the rationale for this change? Also, why are you doing it in
> this document? This seems like it's going to be extremely hard for
> implementors to find in future.
>

These paragraphs are updates to RFC 7845, which needed to be revised to
accommodate the proposed channel mapping families in this draft. The
authors of RFC 7845 and RFC 6716 suggested that the necessary updates to
RFC 7845 should be included in this draft.



> COMMENTS
> S 3.2.
> >      whether or not there is a separate non-diegetic stereo stream.  This
> >      corresponds to periphonic ambisonics from zeroth to fourteenth order
> >      plus potentially two channels of non-diegetic stereo.  Explicitly
> the
> >      allowed number of channels are 1, 3, 4, 6, 9, 11, 16, 18, 25, 27,
> 36,
> >      38, 49, 51, 64, 66, 81, 83, 100, 102, 121, 123, 144, 146, 169, 171,
> >      196, 198, 225, and 227.
>
> This seems like the same graf as in 3.1, so perhaps merge these?
>

Merged and moved to a separate sub-section.


> S 3.2.
> >
> >                 Figure 3: Demixing in Channel Mapping Family 3
> >
> >      The matrix MUST be provided as side information and MUST be stored
> in
> >      the channel mapping table part of the identification header, c.f.
> >      section 5.1.1 in [RFC7845].  The matrix replaces the need for a
>
> I don't think you want "c.f." here, b/c "cf." means "compare". I
> suspect you just want "see". Also, there's no period between c and f.
>

Changed.


>
> S 5.1.
> >      Figure 6: Stereo Downmixing Matrix for Channel Mapping Family 2 and
> 3
> >             - Ambisonic Channels Plus a Non-diegetic Stereo Stream
> >
> >   5.  Updates to RFC 7845
> >
> >   5.1.  Format of the Channel Mapping Table
>
> What are the interop implications of this? I.e., is a file formatted
> according to this document at all playable with an existing Ogg
> decoder? If not, perhaps say so
>

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.