From nobody Mon Aug 6 10:20:15 2018 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F92130E58; Mon, 6 Aug 2018 10:20:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: codec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: codec@ietf.org Message-ID: <153357601325.26754.7892164429798148588@ietfa.amsl.com> Date: Mon, 06 Aug 2018 10:20:13 -0700 Archived-At: Subject: [codec] I-D Action: draft-ietf-codec-ambisonics-08.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:20:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec WG of the IETF. Title : Ambisonics in an Ogg Opus Container Authors : Jan Skoglund Michael Graczyk Filename : draft-ietf-codec-ambisonics-08.txt Pages : 10 Date : 2018-08-06 Abstract: This document defines an extension to the Opus audio codec to encapsulate coded ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-ambisonics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-codec-ambisonics-08 https://datatracker.ietf.org/doc/html/draft-ietf-codec-ambisonics-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-ambisonics-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 6 10:33:47 2018 Return-Path: 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 ; 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 ; 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 ; Mon, 6 Aug 2018 10:33:42 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id o18-v6so15266177wmc.0 for ; 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 Date: Mon, 6 Aug 2018 19:33:28 +0200 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry , codec@ietf.org, codec-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009bd8ee0572c7addc" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:33:46 -0000 --0000000000009bd8ee0572c7addc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 t= he > > 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. Th= is > > corresponds to periphonic ambisonics from zeroth to fourteenth ord= er > > 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 an= d > 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 =E2=80=9CA demuxer implementation encountering a 'channel mapping family' value that it does not recognize SHOULD NOT attempt to decode the packets=E2=80=9C 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 =E2=80=9CIf '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=E2=80=9D So, it would either decode and play an unintended mixing, or not produce audio at all. --0000000000009bd8ee0572c7addc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the comments! Our responses are inline below. A= new version of the doc has been uploaded.

Cheers,
=
Jan


S 3.2.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Stream Count=C2=A0 |=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Coupled Count | Demixing Matrix=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 MUS= T provide a matrix in the channel mapping table.


S 5.2.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The remaining channel mapping familie= s (2...254) are reserved.=C2=A0 A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0demuxer implementation encountering a= 'channel mapping family'
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value that it does not recognize SHOU= LD NOT attempt to decode the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets and SHOULD NOT use any inform= ation except for the first 19
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0octets of the ID header packet (Fig. = 2) and the comment header
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(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 paragr= aphs 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 a= nd RFC 6716 suggested that the necessary updates to RFC 7845 should be incl= uded in this draft.

=C2=A0
COMMENTS
S 3.2.
>=C2=A0 =C2=A0 =C2=A0 whether or not there is a separate non-diegetic st= ereo stream.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0 corresponds to periphonic ambisonics from zeroth t= o fourteenth order
>=C2=A0 =C2=A0 =C2=A0 plus potentially two channels of non-diegetic ster= eo.=C2=A0 Explicitly the
>=C2=A0 =C2=A0 =C2=A0 allowed number of channels are 1, 3, 4, 6, 9, 11, = 16, 18, 25, 27, 36,
>=C2=A0 =C2=A0 =C2=A0 38, 49, 51, 64, 66, 81, 83, 100, 102, 121, 123, 14= 4, 146, 169, 171,
>=C2=A0 =C2=A0 =C2=A0 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.
=C2=A0=
S 3.2.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 3:= Demixing in Channel Mapping Family 3
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 The matrix MUST be provided as side information an= d MUST be stored in
>=C2=A0 =C2=A0 =C2=A0 the channel mapping table part of the identificati= on header, c.f.
>=C2=A0 =C2=A0 =C2=A0 section 5.1.1 in [RFC7845].=C2=A0 The matrix repla= ces 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.
=C2=A0

S 5.1.
>=C2=A0 =C2=A0 =C2=A0 Figure 6: Stereo Downmixing Matrix for Channel Map= ping Family 2 and 3
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Ambisonic Channels Pl= us a Non-diegetic Stereo Stream
>=C2=A0 =C2=A0
>=C2=A0 =C2=A05.=C2=A0 Updates to RFC 7845
>=C2=A0 =C2=A0
>=C2=A0 =C2=A05.1.=C2=A0 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 map= ping family 255, and instead =E2=80=9CA
demuxer implementation enc= ountering a 'channel mapping family'
value that it does no= t recognize SHOULD NOT attempt to decode the
packets=E2=80=9C
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 inval= id and not decode, or, if the index is lower-valued, decode the streams acc= ording to the old rule
=E2=80=9CIf '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&= #39; is 2*M or larger, but less than 255, the output
MUST be take= n from decoding stream ('index' - M) as mono. If
'in= dex' is 255, the corresponding output channel MUST contain
pu= re silence=E2=80=9D

So, it would either decode and play an unintende= d mixing, or not produce audio at all.


= =C2=A0
--0000000000009bd8ee0572c7addc-- From nobody Mon Aug 6 10:36:30 2018 Return-Path: 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 4DCCA130F0A for ; Mon, 6 Aug 2018 10:36:17 -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 n4LJ9GCLD3Wa for ; Mon, 6 Aug 2018 10:36:16 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 7E832130EEC for ; Mon, 6 Aug 2018 10:36:10 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id r24-v6so12122648wmh.0 for ; Mon, 06 Aug 2018 10:36:10 -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=OTRIhTQRksQ1vtFS4dos3I2yYtwLKAqoL6oc9Gg5dzM=; b=QF3KUj4KS9PP8cjsQDtOED536/5iwuGttjo8YePhxZPeAX35Qr3Pq4zlqoMOCbQL77 Tq0QG05g1DdknqGVSK2GtfrXdW2M7ZfgBysgZloRnVuLNnRN3o4YDuWQwAg1kHNnHA9s X7JTarGg8ii1txQy+U8BS5AnEWYMiiLMmW5xIZ5GRmz5kcII5bOK2b1yfdY2VODYIW+U kgnaO1ZkZzAXa8SD+lRyXnnR4g2y1zmWbKh/AA5hEuxfiM90pcsRJrJ8LTMWOj/Zwbrc WVFWH4Wz2gJ+5/qPnbCTbaP7eOSIoB+jLpUhMlzO1ZpyZ10/S+tYWo7AeJ4EW4ifxJlZ EEfA== 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=OTRIhTQRksQ1vtFS4dos3I2yYtwLKAqoL6oc9Gg5dzM=; b=OhjtOyX5gC+uFQK/eHTtUI47iGKFet3+0H3LJbex4YK4E71NekIR5pHCyf5obUrpjK sAH1pUS6iW7p2nSx8pXFYb6pnzL6elTQUqOwGdiPjSsKH6W9M3J2hRX2f/AY1w2b5PDd MCNkocu5EdkC1XvUDbvU+JekR5O+pMoIZ1kQsBWxq/RLdU7OZpsMgikzvdUbZ0D7u07g kvvsV5zqmeCrYq5jj24JVMs+bpa/dodakL6Yo033M/73hvDr924yObRc2IwzvDPtnm6f HigpJRlrOM6wMf8nvYMv9emxvFv+Y3bdV6rccMSmV2QS6z4dBri2/1piugNgaE5vglOJ BYZQ== X-Gm-Message-State: AOUpUlHYVUzjc9b92zqoHweoemmAk5YgYxYI9jt+KItrj5FjYg94D2Wo BfeZbAtBGCpS0+fXFmd23+prR4i5Xk0bgfO5sWW53w== X-Google-Smtp-Source: AAOMgpfk7nNuh/zUxB46b92NMpCwhrbSH0mRV+t9j1CS3nsOcYi0NkfRPEWoSGkNcPPiRyDOKS6aPGSRjQhAnDkj72Q= X-Received: by 2002:a1c:4887:: with SMTP id v129-v6mr11712908wma.129.1533576968465; Mon, 06 Aug 2018 10:36:08 -0700 (PDT) MIME-Version: 1.0 References: <153307969456.3468.10316294264002492424.idtracker@ietfa.amsl.com> In-Reply-To: <153307969456.3468.10316294264002492424.idtracker@ietfa.amsl.com> From: Jan Skoglund Date: Mon, 6 Aug 2018 19:35:56 +0200 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry , codec-chairs@ietf.org, codec@ietf.org Content-Type: multipart/alternative; boundary="00000000000071b2cc0572c7b6c2" Archived-At: Subject: Re: [codec] Adam Roach'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:36:21 -0000 --00000000000071b2cc0572c7b6c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the comments! Our responses are inline below. A new version of the doc has been uploaded. Cheers, Jan > =C2=A74: > > Are implementors intended to assume that the elided matrix coefficients > are all > 0.0? If so, it's probably best to say so explicitly. > > Yes. Added. > =C2=A76: > > To be clear, these code points that are being reserved are for experiment= al > channel mappings in general, not just channel mappings that are specific = to > ambisonics, right? If so, I would suggest calling this out explicitly. > Yes. Added. --00000000000071b2cc0572c7b6c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks = for the comments! Our responses are inline below. A new version of the doc = has been uploaded.
=
Cheers,
Jan



=C2=A74:

Are implementors intended to assume that the elided matrix coefficients are= all
0.0? If so, it's probably best to say so explicitly.


Yes. Added.

=C2= =A0
=C2=A76:

To be clear, these code points that are being reserved are for experimental=
channel mappings in general, not just channel mappings that are specific to=
ambisonics, right? If so, I would suggest calling this out explicitly.
<= /blockquote>


Yes. Added.
= =C2=A0
--00000000000071b2cc0572c7b6c2-- From nobody Mon Aug 6 10:43:56 2018 Return-Path: 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 ; 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 ; 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 ; Mon, 6 Aug 2018 10:43:44 -0700 (PDT) Received: by mail-wm0-x22c.google.com 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; 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 Date: Mon, 6 Aug 2018 19:43:30 +0200 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry , codec-chairs@ietf.org, codec@ietf.org 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-BeenThere: codec@ietf.org 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 --0000000000008063d00572c7d1b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 large= r > 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 no= te > 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 =E2=80=9CA demuxer implementation encountering a 'channel mapping family' value that it does not recognize SHOULD NOT attempt to decode the packets=E2=80=9C 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 =E2=80=9CIf '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=E2=80=9D 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 =E2=80=9Dn =3D 0, 1, =E2=80=A6, 14=E2=80=9D , 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 necessaril= y > 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 i= n > 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 portio= n > 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 no= t > be too hard to also modify the registry structure to add such a thing, if > you want. > > Perhaps, but I=E2=80=99m afraid I wouldn=E2=80=99t know how to do that:) --0000000000008063d00572c7d1b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks = for the comments! Our responses are inline below. A new version of the draf= t has been uploaded.

Cheers,
=
Jan


I see that Section 5.2 attempts to Update RFC 7845 to allow for the larger<= br> 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.=C2=A0 The actual mapping ta= ble
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 necess= ary. I.e., not interpreting as channel mapping family 255, and instead =E2= =80=9CA
demuxer implementation encountering a 'channel mapping famil= y'
value that it does not recognize SHOULD NOT attempt to decode the=
packets=E2=80=9C
I think that, depending on implementation, an old d= ecoder would interpret a Q15 value as an index and either, most likely, dec= ide the value to be invalid and not decode, or, if the index is lower-value= d, decode the streams according to the old rule
=E2=80=9CIf 'index&#= 39; is less than 2*M, the output MUST be taken from
decoding stream (= 9;index'/2) as stereo and selecting the left
channel if 'index&#= 39; is even, and the right channel if 'index' is
odd. If 'in= dex' is 2*M or larger, but less than 255, the output
MUST be taken f= rom decoding stream ('index' - M) as mono. If
'index' is= 255, the corresponding output channel MUST contain
pure silence=E2=80= =9D
So, it would either decode and play an uninten= ded mixing, or not produce audio at all.

=

=C2=A0
Section 1

I think we want to say "by adding itesm with values 2 and 3" to t= he
registry, since we add two entries and not a single superposed entry.

Changed.
=C2=A0
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 =E2= =80=9Dn =3D 0, 1, =E2=80=A6, 14=E2=80=9D , which we feel that most readers = will interpret such that all integers in the given range, including 0 and 1= 4, are valid.
=C2=A0
Section 3.2

Figure 3 could perhaps make it more clear that C and K are not necessarily<= br> equal.

=C2=A0
We feel it's sufficiently clear in th= e 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 pa= ragraph.
=C2=A0
The term "side information" is used without definition (and is no= t used in
RFC 7845).=C2=A0 Does this clause really add anything in comparison to if w= e
just say "The matrix MUST be provided in the channel mapping table por= tion
of the identification header, in place of a normal channel mapping table&qu= ot;?


Changed.
=C2=A0
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.)
=C2=A0
Changed.
=C2=A0
Section 8

Sometimes I see a "Description" column that allows for in-registr= y
visibility that a range is for experimental usage.=C2=A0 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=E2=80=99m afrai= d I wouldn=E2=80=99t know how to do that:)
=C2=A0
--0000000000008063d00572c7d1b0-- From nobody Mon Aug 6 10:55:03 2018 Return-Path: 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 9A516130F07; Mon, 6 Aug 2018 10:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 3Upf7o93968m; Mon, 6 Aug 2018 10:54:52 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E124E130EE2; Mon, 6 Aug 2018 10:54:51 -0700 (PDT) X-AuditID: 12074425-38dff7000000268a-a2-5b688b69fa66 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 57.E7.09866.96B886B5; Mon, 6 Aug 2018 13:54:50 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w76Hslku009109; Mon, 6 Aug 2018 13:54:48 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w76HshQZ006900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Aug 2018 13:54:45 -0400 Date: Mon, 6 Aug 2018 12:54:43 -0500 From: Benjamin Kaduk To: Jan Skoglund Cc: The IESG , draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry , codec-chairs@ietf.org, codec@ietf.org Message-ID: <20180806175442.GN97277@kduck.kaduk.org> References: <153297931466.7637.15045953147147693291.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixCmqrJvVnRFtMO+6kMXv82dZLE43rWe1 OHbtD4vFjD8TmS0OrzzBbnH2RyOTA5vHgk2lHkuW/GTy6DvQxRrAHMVlk5Kak1mWWqRvl8CV sabjLkvBbPmK//+XMDUw9kh0MXJySAiYSKw6/5mli5GLQ0hgMZPE3P3r2SGcDYwSd991QTlX mCROPLjCDNLCIqAicfLNbUYQmw3Ibui+DBYXEVCU2HlsI9goZoGljBJ/P39mBUkIC8RJPP11 hR3E5gXat+7ERyaIqVMYJRqe7WCESAhKnJz5hAXEZhZQl/gz7xLQVA4gW1pi+T8OiLC8RPPW 2WDLOAUCJSbN3w7WKiqgLLG37xD7BEbBWUgmzUIyaRbCpFlIJi1gZFnFKJuSW6Wbm5iZU5ya rFucnJiXl1qka6GXm1mil5pSuokRFAvsLqo7GOf89TrEKMDBqMTDu4ElI1qINbGsuDL3EKMk B5OSKC9TO1CILyk/pTIjsTgjvqg0J7X4EKMEB7OSCC9vJlCONyWxsiq1KB8mJc3BoiTOe78m PFpIID2xJDU7NbUgtQgmK8PBoSTBq9MF1ChYlJqeWpGWmVOCkGbi4AQZzgM0fFcnyPDigsTc 4sx0iPwpRl2OP++nTmIWYsnLz0uVEocoEgApyijNg5sDSmES2ftrXjGKA70lzPsMZB0PMP3B TXoFtIQJaEm1SSrIkpJEhJRUA+PiRUwq1nX3NETfHbddKtdz+f6/LWJZXyJVj8aYzRbczFJW HidY5PqxxPSGmEPUDfXMrHzNA0xXY8T5Dirc6/Pl3rj/1W1vt7i/6vOnHZ2aZLR7iaeBxMqO 0F0ehxyusl7a2nftjERRg0zeVXmejuN6H3uDneqrX3cW3muuu8Lzq+vPcxGNs0osxRmJhlrM RcWJAMT/7Hw8AwAA Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:55:02 -0000 On Mon, Aug 06, 2018 at 07:43:30PM +0200, Jan Skoglund wrote: > 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. Did you consider adding some text describing this situation to the document? I guess it is not strictly required from a protocol description point of view, but would probably save readers some effort, when aggregated over time. > > > > > 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:) We can help you out if you do want to go down that route, but I don't think anyone is insisting on it :) Thanks, Benjamin From nobody Thu Aug 9 14:48:45 2018 Return-Path: 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 826FD130F27 for ; Thu, 9 Aug 2018 14:48:42 -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 rTEmCK9Y57xO for ; Thu, 9 Aug 2018 14:48:41 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 DFA09130EF0 for ; Thu, 9 Aug 2018 14:48:39 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id l9-v6so3459762pff.9 for ; Thu, 09 Aug 2018 14:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thaumas-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Yc88Ifo5RpcquRK4CyxfU9Y6hT1RoGwDTZ1HNGheUg8=; b=aYFQTeSXi5VVKThyZ56147HpPbK1fL9szz+khPMhOLhYCfRY6vyIqqNYQ5/O8AA+Y9 qnsbvyqlIqsucA+/NGICGGjRNVP7RqAWDTQvSeGdFzvgxfAJV2HSblSEW7IMHYL7StoA P64JFzuW8fyNNxR3jf2+sud3aSfk2HxuqYvSqNxIt4TeMz1zdKWw4FJA7H8ao/lGszln hFwru9Dd3EiNJCTpg98LRi6yIUC690AASUlExrgGc6LcvZKOOPCsA78pNBBzi7FYjsl+ jqsg/A54D+UpizAhd8rUG9ZbSK4fzfFxBnHNUDaGh0N2vLmGyCv3cXgvpc1eJ/58A955 FA0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Yc88Ifo5RpcquRK4CyxfU9Y6hT1RoGwDTZ1HNGheUg8=; b=h7BbbkYwGlSTSi/KR/QO+hHJj4Xbm6VEMjdFjqVUMfbcvc+qiDlowvsw5GzjBm7sOD O734WcBZ61QXwgSXwZ8+4Xrw7v7hjytBCEB3rVoiZ1tMyDsT3/s6N6frvnDbFW+9MFC9 Yanjf7V/6p++bCsHiCT4MFBkyU840PYRTpiXwNvGK8r8uQEWXehMvCiBNxrHsJcmW1ow 7QXOfMeoxpt/ift3IzdwERPjUFhHAeKY7ELTgHiLg9H8BeV1+2CJMbWhmf9FAeH+ivQA ocxS6yXDPMfBAP6IzUHZc0Hzntb61ZLTD48PO+gBO8ls2bI3xBLaAX6/HvAJX+2dkW2c GvHg== X-Gm-Message-State: AOUpUlEze3lfRzzSg1JUSP3D+FlDSSrj/Vp5O9X/BZOp0LmpoShdFFTE b10kO4PtHL8KW3BErx0/luXIoA== X-Google-Smtp-Source: AA+uWPx5vbuqUkl+s6OQf1xMGol+7k+gZRWnrX5LnWwfJdVGfPWM7Zx2ZmOY1pHT+TaB5Xmp+VEwYw== X-Received: by 2002:a62:9ed1:: with SMTP id f78-v6mr4105382pfk.35.1533851316451; Thu, 09 Aug 2018 14:48:36 -0700 (PDT) Received: from [192.168.1.215] (S0106185933484486.vc.shawcable.net. [174.7.172.49]) by smtp.gmail.com with ESMTPSA id t15-v6sm13499666pfa.158.2018.08.09.14.48.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 14:48:35 -0700 (PDT) To: Benjamin Kaduk , Jan Skoglund Cc: Tim Terriberry , codec@ietf.org, draft-ietf-codec-ambisonics@ietf.org, codec-chairs@ietf.org, The IESG References: <153297931466.7637.15045953147147693291.idtracker@ietfa.amsl.com> <20180806175442.GN97277@kduck.kaduk.org> From: Ralph Giles Message-ID: <17548084-d2cd-b8e9-7dda-661725a9ac8d@thaumas.net> Date: Thu, 9 Aug 2018 14:48:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180806175442.GN97277@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 21:48:43 -0000 On 2018-08-06 10:54 AM, Benjamin Kaduk wrote: >>> 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. I think this is a good idea. How about something like: +---------+---------------------------+---------------------------+ | Value | Description | Reference | +---------+---------------------------+---------------------------+ | 0 | Mono, L/R stereo | RFC 7845, Section 5.1.1.1 | | | | | | 1 | 1-8 channel surround | RFC 7845, Section 5.1.1.2 | | | | | | 2 | Ambisonic channel order | This Document Section 3.1 | | | | | | 3 | Ambisonic with mix matrix | This Document Section 3.2 | | | | | | 240-254 | Experimental use | This Document Section 6 | | | | | | 255 | Discrete channels | RFC 7845, Section 5.1.1.3 | +---------+---------------------------+---------------------------+ -r From nobody Thu Aug 9 17:22:06 2018 Return-Path: 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 ; 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 ; 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 ; Thu, 9 Aug 2018 17:21:57 -0700 (PDT) Received: by mail-pl0-x22d.google.com with SMTP id f6-v6so3254659plo.1 for ; 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 , Tim Terriberry From: Ralph Giles Message-ID: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Fri Aug 10 12:34:47 2018 Return-Path: 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 D1AE2130F81 for ; Fri, 10 Aug 2018 12:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 Hpyu748vJ-rA for ; Fri, 10 Aug 2018 12:34:43 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 3774F130F6D for ; Fri, 10 Aug 2018 12:34:42 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id f18-v6so7353927lfc.2 for ; Fri, 10 Aug 2018 12:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k+ZWOfoBWb+stPBp2hseIMXQ/5b3yUUHNqajg6zFv7E=; b=hJnzvuIpnjkp6kW/Y+FEbbKw1qg687QgRNnpKnemiUATPTm8xYjhD+7KlAQRZ6ZB7z SvpBwLftP0tS4xhOTLrAvQeTtSxXG3IpuMAFtkCDiGw5QHI1mOmWeABMBD7cv0H9se+k wh1rWvytmOt/2QbwweQGmDweO3K9VuhGyUVWtb3oTxEjrloTVbEF1BiBIjV2+7Ynr/Rl lD7io6XDtKiBfQQ1YvogVnGtiy4RP5g6EjiFLg+16G8lIjKUjSIuUlfYz2eSjFzTRYFu jSzbXQhOar45xWWPf4CkDi4DmHUMm5XGm0WMXW4AqPR/utJNq3d3RlYwL/zuWr7TImC4 HsUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k+ZWOfoBWb+stPBp2hseIMXQ/5b3yUUHNqajg6zFv7E=; b=aAwZnXPjJm0ldRtRYUwK8bHcOb9WOUGVRsVcsfqKOePNhZClWFTZelE5xSSYqv0cTn ahVe1yu4pRRgXBi+X7c4+yKMh2DJgfQaa9iYe5aBQ+wmbLhl/mTa96a5SxXAXsaQp1FS N0bv5+idQi0Paqb//Ro+NTPh+00xbuYVE4hAB7ukDvGFcX8Jz9fTw36tjjveaA3fsDly SlYpwl1HJRnDb1j3hcGl0jvdFdGYQkJ4uwSUFwrhdi5bBR3Xn/l4qeP0O8bdkxt3RNY1 fY7dr42aDdn72xJhhEpkxbpaPILZBu29J3h/3my1UHp7Cu5B4QW3zLuHJaq+/e9haFor gD8Q== X-Gm-Message-State: AOUpUlGFcw5cUuWNTxKD0ZdH9rQy7POqbs8gAiCT8SOfAsFV7Jk/UNN/ /YnV/CNSi9RW+BH62aMTXvCM9S8SE6e4L1TigwREsg== X-Google-Smtp-Source: AA+uWPzFa92Wi4dn41AyI/mxGBxOpNcq/+bxecj/K8T4sXm2q18w6B4pzp7YCPHE5PxpTFcWnd4vlVpzil1fLO6FnkI= X-Received: by 2002:a19:c3c7:: with SMTP id t190-v6mr2356526lff.108.1533929680443; Fri, 10 Aug 2018 12:34:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 10 Aug 2018 12:33:59 -0700 (PDT) In-Reply-To: References: <153295358610.1069.2720875646830940452.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Fri, 10 Aug 2018 12:33:59 -0700 Message-ID: To: Jan Skoglund Cc: The IESG , draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry , codec@ietf.org, codec-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000b6b156057319d5c2" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 19:34:45 -0000 --000000000000b6b156057319d5c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 6, 2018 at 10:33 AM, Jan Skoglund wrote: > 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 firs= t >> 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. > Sorry, I don't understand. Why did they need to be revised to have this change? The authors of RFC 7845 and RFC 6716 suggested that the necessary updates > to RFC 7845 should be included in this draft. > I understand, but my point is that people are likely to ignore this draft if they don't care about ambisonics and thereby miss out on a relevant information. In any case, I'll defer to the WG and AD. 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 =E2=80=9CA > demuxer implementation encountering a 'channel mapping family' > value that it does not recognize SHOULD NOT attempt to decode the > packets=E2=80=9C > Sorry, I'm not following. Is your point that previously it would have misdecoded it and now it will just refuse to play? That's a reasonable design choice, but it seems like it was always present in this design, so why does it need to change? 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 > =E2=80=9CIf '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=E2=80=9D > > So, it would either decode and play an unintended mixing, or not produce > audio at all. > All right. -Ekr > > > --000000000000b6b156057319d5c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 6, 2018 at 10:33 AM, Jan Skoglund <jks@google.com> wrote:
Thanks for th= e comments! Our responses are inline below. A new version of the doc has be= en uploaded.

Cheers,
Jan


S 3.2.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Stream Count=C2=A0 |=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Coupled Count | Demixing Matrix=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The remaining channel mapping familie= s (2...254) are reserved.=C2=A0 A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0demuxer implementation encountering a= 'channel mapping family'
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value that it does not recognize SHOU= LD NOT attempt to decode the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets and SHOULD NOT use any inform= ation except for the first 19
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0octets of the ID header packet (Fig. = 2) and the comment header
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(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 accommod= ate the proposed channel mapping families in this draft.
=

Sorry, I don't understand. Why did the= y need to be revised to have this change?


The authors of RFC 7845 and RFC 6716 suggested that the necessary up= dates to RFC 7845 should be included in this draft.

I understand, but my point is that people are l= ikely to ignore this draft if they don't care about ambisonics and ther= eby miss out on a relevant information. In any case, I'll defer to the = WG and AD.


S 5.1.
>=C2=A0 =C2=A0 =C2=A0 Figure 6: Stereo Downmixing Matrix for Channel Map= ping Family 2 and 3
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Ambisonic Channels Pl= us a Non-diegetic Stereo Stream
>=C2=A0 =C2=A0
>=C2=A0 =C2=A05.=C2=A0 Updates to RFC 7845
>=C2=A0 =C2=A0
>=C2=A0 =C2=A05.1.=C2=A0 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 reas= on the changes below to 7845 are necessary. I.e., not interpreting as chan= nel mapping family 255, and instead =E2=80=9CA
de= muxer implementation encountering a 'channel mapping family'
= value that it does not recognize SHOULD NOT attempt to decode the
packets=E2=80=9C

Sorry, I'm not following. Is your point that previously it would = have misdecoded it and now it will just refuse to play? That's a reason= able design choice, but it seems like it was always present in this design,= so why does it need to change?

I think that, depe= nding on implementation, an old decoder would interpret a Q15 value as an i= ndex 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
=E2=80=9CIf 'index' is less than 2*M, the output MUST be t= aken from
decoding stream ('index'/2) as stereo and selec= ting the left
channel if 'index' is even, and the right c= hannel if 'index' is
odd. If 'index' is 2*M or la= rger, but less than 255, the output
MUST be taken from decoding s= tream ('index' - M) as mono. If
'index' is 255, = the corresponding output channel MUST contain
pure silence=E2=80= =9D

So, it would either decode and play an unintended mixing, or not= produce audio at all.

Al= l right.

-Ekr



=C2=A0

--000000000000b6b156057319d5c2-- From nobody Fri Aug 10 12:36:05 2018 Return-Path: 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 4C711130F6D for ; Fri, 10 Aug 2018 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=masque.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 mIxFlfVOrIJD for ; Fri, 10 Aug 2018 12:36:01 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 BC9F8130EAE for ; Fri, 10 Aug 2018 12:36:00 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id z20-v6so8644322iol.0 for ; Fri, 10 Aug 2018 12:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=masque.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=EuHwErt5CDPKw9nT7vHg5pXcsi0mJp1+w//PROnNssM=; b=BJpeaDJgSulpjt3YLwY2hnSb9Kn8Mvvm9nHTArgEz03R4eP4Tnu5XWI5LgnnL2jslE yt3W4CZFV3n0oY4TGuRmjn7OwFQy+109Whg5KLZunPPVhVmWD0gr2KHtBExksDgNBO+P YYKGb6si/N9XwWLz/Z+xUzwR3WfCPo1NZ1288= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=EuHwErt5CDPKw9nT7vHg5pXcsi0mJp1+w//PROnNssM=; b=LwZjt2pEooTnpgWzi/IW7NL+ftezmN7Ctyar/j1893pvEHfhTkMtk06VmRi1qb6O6K SqvqnDEFXt9LoZmj7FCc9eJyGXKFgoTy3PJyMp4/oBQdMMzO2ibLioyH4EODCC0jPqu5 5UBYs4oxKWhekyWrT7Lft8tp9ORsZL8koYDIUH5kLbBep61hZrozrA3dQeJJTDJsLqar lUu105gpnk8Ze/ZMwkHHer5DZrXMmisicXO7hgf/CYYr73hKhxydakd6cIV24iB9nJP1 V9YrH5uGrDu8zoPBCRaVRjNYwv/TQc5Nc2nJ4+0SipQtuFSCqDjAi2deQpoAEEcY55g3 7vGg== X-Gm-Message-State: AOUpUlHi/h4M6NSkbAiDYqpL1MeTbnDFqdaKk1eiP29Ej5Qd+66588Lt H9AZBP/wvdyK8E/kPWJkGxCy1Q== X-Google-Smtp-Source: AA+uWPyppDNFJv1yNQ6Gqc+0lEXitaap77jnaUj/DqA5poWucm8bePBCCi3VMxPzKhbULiDP4XwAVw== X-Received: by 2002:a6b:cac3:: with SMTP id a186-v6mr6649948iog.116.1533929760018; Fri, 10 Aug 2018 12:36:00 -0700 (PDT) Received: from [192.168.7.134] (173-8-226-67-littleton.hfc.comcastbusiness.net. [173.8.226.67]) by smtp.gmail.com with ESMTPSA id w20-v6sm3131371ioa.82.2018.08.10.12.35.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Aug 2018 12:35:59 -0700 (PDT) To: codec@ietf.org, draft-ietf-codec-ambisonics@ietf.org References: Cc: Ralph Giles , Jan Skoglund , Tim Terriberry From: John Ridges Message-ID: Date: Fri, 10 Aug 2018 13:35:58 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8E0E361415EE770C89B90C01" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 19:36:03 -0000 This is a multi-part message in MIME format. --------------8E0E361415EE770C89B90C01 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 8/9/2018 6:21 PM, Ralph Giles wrote: > From: > Ralph Giles 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. I believe the technical term for a matrix "stored column-wise" is that the matrix is stored in "column-major order". Re: https://en.wikipedia.org/wiki/Row-_and_column-major_order --------------8E0E361415EE770C89B90C01 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 8/9/2018 6:21 PM, Ralph Giles <giles@thaumas.net> wrote:
From:
Ralph Giles <giles@thaumas.net> 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.

I believe the technical term for a matrix "stored column-wise" is that the matrix is stored in "column-major order".
Re: https://en.wikipedia.org/wiki/Row-_and_column-major_order

--------------8E0E361415EE770C89B90C01-- From nobody Mon Aug 13 10:26:00 2018 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C521C130FE2; Mon, 13 Aug 2018 10:25:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: codec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: codec@ietf.org Message-ID: <153418115375.24977.17209740935260892998@ietfa.amsl.com> Date: Mon, 13 Aug 2018 10:25:53 -0700 Archived-At: Subject: [codec] I-D Action: draft-ietf-codec-ambisonics-09.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 17:25:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec WG of the IETF. Title : Ambisonics in an Ogg Opus Container Authors : Jan Skoglund Michael Graczyk Filename : draft-ietf-codec-ambisonics-09.txt Pages : 10 Date : 2018-08-13 Abstract: This document defines an extension to the Opus audio codec to encapsulate coded ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-ambisonics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-codec-ambisonics-09 https://datatracker.ietf.org/doc/html/draft-ietf-codec-ambisonics-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-ambisonics-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 13 10:53:48 2018 Return-Path: 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 030A9130E43 for ; Mon, 13 Aug 2018 10:53:47 -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 D1344J90Rk-f for ; Mon, 13 Aug 2018 10:53:44 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 CE4CA130E08 for ; Mon, 13 Aug 2018 10:53:43 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id j5-v6so14988835wrr.8 for ; Mon, 13 Aug 2018 10:53:43 -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=ih9ykLv73O8gxPlXHdUOkk+WwSScuvCoAGY1pzwM7dQ=; b=Wek+qKR651pAd7WWostmbe0OAVOqQXxzH14lVJS1H3KElZmdD5nJk2ZUucrdKFL/vp c9Q2HWlyIUDAlaHkN85xOi9Xj/KVm3yQ4JHXPHlps8JIpdsjHjayT3maobzfPrI7Ysyl vCu/F5PU165f+BwHrFJ2iTT1CyIITd36dsbJckgwx6YvJT1DLUpJWY3DH8T1oKJY2b0D Yi9ZKZStc+kVwrPZXKHIahweVudFDKTQSUsKj2CskwcHRbnJUgiM1P+KEK4P15/vKEc2 +JbkoZw4FXn02rH9VFy6n2YT5yp2wZxbpUMLZRiJhgR8AxbqGpOWUcCW7UXgoEcbxkPX 52eA== 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=ih9ykLv73O8gxPlXHdUOkk+WwSScuvCoAGY1pzwM7dQ=; b=S418Ofc1oTe6kRLK0f6D6w/c9n2GQVlaLfYIo8CQ5O4AkDFf7YYbAN6OGx+LAdKT+0 w9pdivBlnQK7YXtE3bloK2SDXcsN9IFnVuP173Lll/PB+KCFXjkBZhar34qeDOAJ39ze G0QTeQdbCgipKJ7YJzaz9BU7qSw0lVyTxlDMtZ1aecgKPZETDzgtB4xonu7PEs6jn48q /FQBp0PVlvv5DPD7jyygKQYLtY8ga4RxanmVgVI2+B3aX4m7/zKZK5o8t8IFPpqGAB3C VY6sV2T8k3+RiR4JZBvH8WWRG2b1ZBQY94K7iQ1Rr1WNhcPLOP4FcO+yYhSpwJavZcsf x17g== X-Gm-Message-State: AOUpUlHR+kPUrWhHe9tuvnTh5f9PUJHjTI9L+6zBQA2qo7KPxyXA18LE WNfriS2ISDPsiJ7FNcfI8hd/bRfusyLMwkqtdtGM9ddr6uU= X-Google-Smtp-Source: AA+uWPzEEuF6wMw3PALoaRKU6V+Zqbf9TIV1vRsGep2y80AgAu/cKXQOvSoLgsSK9qkR7smQramtuXxhcJ/tTSmIb78= X-Received: by 2002:adf:b786:: with SMTP id s6-v6mr11455504wre.247.1534182821807; Mon, 13 Aug 2018 10:53:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jan Skoglund Date: Mon, 13 Aug 2018 10:53:29 -0700 Message-ID: To: giles@thaumas.net Cc: IETF - CoDec , draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry Content-Type: multipart/alternative; boundary="0000000000001da387057354c64b" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 17:53:47 -0000 --0000000000001da387057354c64b Content-Type: text/plain; charset="UTF-8" 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 --0000000000001da387057354c64b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 t= o the more prevalent notion "column-major order"
<= br>
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, i= f full order is used. This is also repeated in Section 3.3.
=
=C2=A0
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 ha= s not been considered. The structure proposed in the draft has been impleme= nted into Opus.
=C2=A0
I don't see an Implementation Status section (as recommended by RFC 6982). Are there multiple implementations of this draft? Test vectors?
<= br>
=C2=A0
This draft has been implemented and is fully availabl= e in the official Opus repository. An experimental flag was recently remove= d. No specific test vectors have been produced.


Cheers,
Jan



<= /div>

=C2=A0
--0000000000001da387057354c64b-- From nobody Mon Aug 13 11:25:05 2018 Return-Path: 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 5AC0A130E14 for ; Mon, 13 Aug 2018 11:25:04 -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=jmvalin-ca.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 iUi1HZhlE05o for ; Mon, 13 Aug 2018 11:25:03 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 DB26D130DFE for ; Mon, 13 Aug 2018 11:25:02 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id 27-v6so11672677qkv.0 for ; Mon, 13 Aug 2018 11:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jmvalin-ca.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KnUq3UjfwdNfPUmxtYKBlYtVQG1zzJtknRZqe3cEw7Q=; b=cqEPFS/XOALyRbDwx6GsfKsNl8yWYoAH9Z6QKFzQn8iXnbfSBt/699wvXMYK9PHEqR ZWue6MNjUWjsucAzQ8rQggiqmvq0c5uEdu0p02huJ+e8jEMhVXdaD5nbIljdwjjoRkGQ cBQxVI6GKAQE3eNpffwHks0tkOydBxffekDKwUbw4v1engly5pE53+pawxL5lxNqQmqV +pNozv2nOa2b3ScCsy/VQTmgKNhu9x8lBe+JyZOXmupQ/Z/w/Gj2dKgPq8aeYfCDNaw8 Bgkh19GhDgWqO2ySYQie6sJey2dTSAFxy7Z/RULdf341hMlRznwm0AWX2nt0x3glDgif 6onw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KnUq3UjfwdNfPUmxtYKBlYtVQG1zzJtknRZqe3cEw7Q=; b=R9EUm4wkK/tvV9/kBnfTvHHm/uA4UyxvyJb81cAB+RxPF9S5ojSduwvGl0feC15O1v veexVQ94UkPCXkBRLB0+1aAAX5ixw4i9aZiiX0/ZNNNEL6JsDQY8Pac1zAFtzWsXEmw5 h0qYAvN+4zKhxSGJfRbEPsKSkqs9SXvx3D64lUxvTMjl9SGM0TrbQVcpUUd56reDkVHE yTJe2NnKMbnG6zFBrk9D0L1motoKDvOvMmoq937UxFxByB88ZD4p3UxsubHXYxl58isi fcjabxKz7DjF7EzNmsYanPG/QLDfkO03q8yJCdKF5eTsEY8BaCNZKWV+6AyWZm57QoBT +wSw== X-Gm-Message-State: AOUpUlHlY/5Csv1q12IP6Lb7ZPKQSqRZN3YV2EuSprbAlnz02w8OO6wb UpN0FrVN2s1pj/vltRo+E7tvMw== X-Google-Smtp-Source: AA+uWPz7oKYncK125DhllCqlmmIKecV+/+KMka6AraRraGagNdy6Z5J3o3nv1gHVWy4pwO7nDpmE5g== X-Received: by 2002:a37:c65c:: with SMTP id b89-v6mr16577183qkj.421.1534184701892; Mon, 13 Aug 2018 11:25:01 -0700 (PDT) Received: from obelix.jmvalin.ca (modemcable231.101-131-66.mc.videotron.ca. [66.131.101.231]) by smtp.gmail.com with ESMTPSA id e21-v6sm11831322qtc.67.2018.08.13.11.25.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Aug 2018 11:25:00 -0700 (PDT) To: Eric Rescorla , Jan Skoglund Cc: Tim Terriberry , codec-chairs@ietf.org, draft-ietf-codec-ambisonics@ietf.org, codec@ietf.org, The IESG References: <153295358610.1069.2720875646830940452.idtracker@ietfa.amsl.com> From: Jean-Marc Valin Message-ID: Date: Mon, 13 Aug 2018 14:24:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 18:25:05 -0000 > 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“ > > Sorry, I'm not following. Is your point that previously it would have > misdecoded it and now it will just refuse to play? That's a reasonable > design choice, but it seems like it was always present in this design, > so why does it need to change? Basically, RFC 7845 didn't consider the possibility of new mappings requiring some kind of transformation (in the case of family 3, a matrix multiply) between the Opus streams and what the decoder needs to output. Once you consider that, then it makes no sense to output the "raw" decoded streams as if it were a family 255. Cheers, Jean-Marc From nobody Fri Aug 24 13:52:15 2018 Return-Path: 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 9A5BB130DC0; Fri, 24 Aug 2018 13:52:14 -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=ham 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 MAdhihIug468; Fri, 24 Aug 2018 13:52:12 -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 C974D130DDF; Fri, 24 Aug 2018 13:52:12 -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 w7OKq6rS079009 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 Aug 2018 15:52:11 -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 Message-Id: <79B0D7AD-8F65-4E9A-A0D6-02473ED1899A@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_AC410CAA-ED0E-4782-AF95-8060AB0377B2"; 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:51:55 -0500 In-Reply-To: Cc: Jan Skoglund , Tim Terriberry , codec-chairs@ietf.org, draft-ietf-codec-ambisonics@ietf.org, codec@ietf.org, The IESG To: Eric Rescorla References: <153295358610.1069.2720875646830940452.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 20:52:15 -0000 --Apple-Mail=_AC410CAA-ED0E-4782-AF95-8060AB0377B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2018, at 2:33 PM, Eric Rescorla wrote: >=20 >=20 >=20 > 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). >=20 > 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. >=20 > These paragraphs are updates to RFC 7845, which needed to be revised = to accommodate the proposed channel mapping families in this draft. >=20 > Sorry, I don't understand. Why did they need to be revised to have = this change? >=20 >=20 > The authors of RFC 7845 and RFC 6716 suggested that the necessary = updates to RFC 7845 should be included in this draft. >=20 > I understand, but my point is that people are likely to ignore this = draft if they don't care about ambisonics and thereby miss out on a = relevant information. In any case, I'll defer to the WG and AD. >=20 Closing the loop on this point: We have commonly put updates to RFCs in the documents that create the = need for the updates, even if the update is generally applicable. We = have the =E2=80=9CUpdates/Updated by=E2=80=9D relationships to track = this sort of thing. I am sympathetic to Ekr=E2=80=99s argument, in that I agree it would be = more convenient for the reader to find the update in a smaller, = dedicated draft. But at this point in the process, I highly doubt the wg = has the energy to do that sort of restructuring. Therefore I am inclined = to leave this the way it is. Thanks, Ben. --Apple-Mail=_AC410CAA-ED0E-4782-AF95-8060AB0377B2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAluAb+sACgkQgFZKbJXz 1A3dOg//e8b1cOkVWuHdmcfleTBpBtmgeST8R0MuJtnwWHy/6zca6BwvCfdeSKPF 2/1dvvJ/yEH3zMB8s4D6sK28OJrbqnY5Oocd5WNs1gsxWtJhxClOsn3Kq1iyvwFf wM2LXNbbr5daGF5AQctkrKI12sYFj0ls0mT8aAyxIfBIlssu3fkqrJH59ePwMYSZ 8SQHhe1oCMNshiCuY8TsbPEuDZ1/3oUKSieiVagUpJaVthA1suy9w/MYwTM70SKo sj+EVDFL3JAqCTO7avX5RwM2Xup/tXbmLadtu7O5R3zXKbbAU7/yCXxOIp3W19sg J/S9NPljYGGEL8FOLcHSz8dV7mVk7s7ril7pN+lJGvkoS0YNIkwCrXPr/phtASKq /GodwmC/Qir2xFzpUC0mkGlKPmhSZ7Gs0L6BmqDsBkyznm67+VDMOZr52lOy9J6C rm+NpzqdtoDyzjmcUNNY65YgXaC3Q4tYLwWtsZyPb7bWo6dGJI/QblvWObVXjaoL D64LcdofQ/LZGPRQksMU/MqgLpzXeGgxdYFvEBWjZvhEsSCg9noQm3TmyVXZkUie tiJGomzSKOPFzmT+sUlrfPpkeVuteJF5tUeUsT2EgYpojUd7EpsLGCNxzTkPi7Mn UBITuyUqd4NlPxCcfV7Bc9Dz6eRy+DnQOdtOHM6HjyvplyZFjQc= =iFxc -----END PGP SIGNATURE----- --Apple-Mail=_AC410CAA-ED0E-4782-AF95-8060AB0377B2-- From nobody Fri Aug 24 13:58:04 2018 Return-Path: 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 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: Cc: Tim Terriberry , draft-ietf-codec-ambisonics@ietf.org, IETF - CoDec , Jan Skoglund To: Ralph Giles References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 20:58:02 -0000 --Apple-Mail=_6C5BCCF6-B014-4A50-A642-56F8A4BAFDFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = wrote: >=20 > Hey, >=20 > Thanks for the comments! >=20 >=20 >=20 > 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. >=20 > Changed to the more prevalent notion "column-major order" >=20 > 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. >=20 > Section 3,2 changed to MUST for 12th order, if full order is used. = This is also repeated in Section 3.3. >=20 > 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? >=20 > This has not been considered. The structure proposed in the draft has = been implemented into Opus. >=20 > I don't see an Implementation Status section (as recommended by RFC > 6982). Are there multiple implementations of this draft? Test vectors? >=20 >=20 > 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. >=20 >=20 > Cheers, > Jan >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --Apple-Mail=_6C5BCCF6-B014-4A50-A642-56F8A4BAFDFA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAluAcVEACgkQgFZKbJXz 1A1muRAAy5Ii+Z/Gz2PkQj37DM4ANnhrzQUABmCQ0B4X0jcEBPkpwOPnHfBEUMUC mz3U8gaCMpmu6XlXbaPmSjnHR0MEAfJjuLNhAarniJtzXHqskLYkcvDicMLrgSVs Ab0TzL8b1PwUECWtqSjC0DUzxHz3St8iIpNvY5+xZw2oTm7eH5hfWb5gwanfiL49 GAd1IUBtzl/8+M6PnBI3/u4t2Vh/YSPQa+SlcdJEuk6k1DpzP5+aW82GWKzoUrmt xlfH9pYW6XkrkEz8MBAukGNzDZZwdKy4hkhH0VOWA2uvJKtrVI4jMIFexgXrsTjr UmeUl/Tryvcfl88Lh857PwjQc7a7cL6b8fLoCsgitzqb2jvTdE7hEGL5pvYtiqFM yqVfeoRDNVnzt/jUwjfEYZOIAnS8TdXHfZSJ+T1Bypn0TGezUtlJGTy9Q2NNutQ8 y8Tf4jQAkDQb2jNi6j4xrCXi+0i1zRESB1R6+eEhR8Q9kzv9O40S9K04qkSr2wV7 2Ifr9qQhIr7UoTzPyCX7bOmAHYwO8rht2eUjhZ2yoaWgWUrIgYsmHBYgvY7a43yz wcbdG1NDkPnC8EboX0rUhXtKZ6npgK0AKTp44Y8MpTvKJjaTlf+MOTAgUCjONFXk +arulRfZxlRMVgr/6+aOfLZqZgLmELaJj0uVVA3h2JY22wh2ncA= =O7Sl -----END PGP SIGNATURE----- --Apple-Mail=_6C5BCCF6-B014-4A50-A642-56F8A4BAFDFA-- From nobody Fri Aug 24 15:30:51 2018 Return-Path: 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 A4BB7130DEC for ; Fri, 24 Aug 2018 15:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 td3FGUROHn3e for ; Fri, 24 Aug 2018 15:30:43 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 21810130DEB for ; Fri, 24 Aug 2018 15:30:41 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id l15-v6so8002727lji.6 for ; Fri, 24 Aug 2018 15:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LeH2OKXvjPn4re9vdgpmkpNeo9n15o1OX6HNTHJMk24=; b=JwO/HkNJL+wKLNdnC4H4aiQVzXmgsIEZsvgmbsdCOb4NeF0Tea5mceSxyvO/v4gpi+ JuWAHE4qQpyVLA3Pw+yKMKEh0SSLadQIDmG9CpH5c1CkQn8nGSeE0KKejhuCCCpbXt3q FeAqNNyhr8gJYft0YRwYvHuf5N779ddEBLtG5GTkSJ9/Nfpc5nxHRYQ+N4VIyFsTPsi7 uUPGQbRLjOO87ty4//8MCT5VvcMbg5hH2U42g5QASOKTQnu/v9fMOR207LsQ5w2bRqlC ooMWhIWNsBLFgi8r9pmEEwNiCykJ+5xuyzq/esTMvuGwMgFhcFPJaJO5DsTUBmypEZ/P WJzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LeH2OKXvjPn4re9vdgpmkpNeo9n15o1OX6HNTHJMk24=; b=YuaeOCdqIru6+fZYrnssnt+3mm4cBo8KaKmoK1Zxra3syWqWSn8tUDxoi9vbFMnvrk +kDZpb1ONiUyskw1OFyB5E3DRcfhWxvGv2ZEVfsxDrSNs39IyRudhzV8pLx+SJGSGAqS DQvaVCgkGh1CFnSqx3R9FCM/7odufC8jvsm37uRIoH7tH3LVFwoZGoygeqNkNFqUHcm+ kuE4EOxxZh7WHyuWvBzJaBZYPUhUWQuuZxwSPbzauJ19/6RlaRYQTn64ZhcHBQdB48Of 0wgMjU38TTiKZiYURfm1bcXK2slkb20NIlx7IilHZfpR7C2fG7suLicRIf46zM6QC0UK 0j/Q== X-Gm-Message-State: APzg51B6CwZdGbS30hc23ct1sBjxE+Bp6uB+sH4JC7Uh2t01Y6yLP+TS q669ObGlQ/vC3G92/Yr4JvTpDoEFU32Ym5ocrKjl5Q== X-Google-Smtp-Source: ANB0VdagcacQZprQZ/bzSmAMHk1uS7UD49wTaB/ZaQt1lrwt8OXvRVrSb44iBniZ1hQwRhEAv9krdraHtEheXJ0tZjs= X-Received: by 2002:a2e:954e:: with SMTP id t14-v6mr2445396ljh.68.1535149839304; Fri, 24 Aug 2018 15:30:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 24 Aug 2018 15:29:58 -0700 (PDT) In-Reply-To: <79B0D7AD-8F65-4E9A-A0D6-02473ED1899A@nostrum.com> References: <153295358610.1069.2720875646830940452.idtracker@ietfa.amsl.com> <79B0D7AD-8F65-4E9A-A0D6-02473ED1899A@nostrum.com> From: Eric Rescorla Date: Fri, 24 Aug 2018 15:29:58 -0700 Message-ID: To: Ben Campbell Cc: Jan Skoglund , Tim Terriberry , codec-chairs@ietf.org, draft-ietf-codec-ambisonics@ietf.org, codec@ietf.org, The IESG Content-Type: multipart/alternative; boundary="000000000000d95f2f057435ec34" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 22:30:45 -0000 --000000000000d95f2f057435ec34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's a comment on my side, so I leave it to your discretion On Fri, Aug 24, 2018 at 1:51 PM, Ben Campbell wrote: > > > > On Aug 10, 2018, at 2:33 PM, Eric Rescorla wrote: > > > > > > > > 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 heade= r > > > (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. > > > > Sorry, I don't understand. Why did they need to be revised to have this > change? > > > > > > The authors of RFC 7845 and RFC 6716 suggested that the necessary > updates to RFC 7845 should be included in this draft. > > > > I understand, but my point is that people are likely to ignore this > draft if they don't care about ambisonics and thereby miss out on a > relevant information. In any case, I'll defer to the WG and AD. > > > > Closing the loop on this point: > > We have commonly put updates to RFCs in the documents that create the nee= d > for the updates, even if the update is generally applicable. We have the > =E2=80=9CUpdates/Updated by=E2=80=9D relationships to track this sort of = thing. > > I am sympathetic to Ekr=E2=80=99s argument, in that I agree it would be m= ore > convenient for the reader to find the update in a smaller, dedicated draf= t. > But at this point in the process, I highly doubt the wg has the energy to > do that sort of restructuring. Therefore I am inclined to leave this the > way it is. > > Thanks, > > Ben. > > > > > --000000000000d95f2f057435ec34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's a comment on my side, so I leave it to your discr= etion

On= Fri, Aug 24, 2018 at 1:51 PM, Ben Campbell <ben@nostrum.com> wrote:


> On Aug 10, 2018, at 2:33 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> S 5.2.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The remaining channel mapping fa= milies (2...254) are reserved.=C2=A0 A
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0demuxer implementation encounter= ing a 'channel mapping family'
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value that it does not recognize= SHOULD NOT attempt to decode the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets and SHOULD NOT use any i= nformation except for the first 19
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0octets of the ID header packet (= Fig. 2) and the comment header
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(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 t= o accommodate the proposed channel mapping families in this draft.
>
> Sorry, I don't understand. Why did they need to be revised to have= this change?
>
>
> The authors of RFC 7845 and RFC 6716 suggested that the necessary upda= tes to RFC 7845 should be included in this draft.
>
> I understand, but my point is that people are likely to ignore this dr= aft if they don't care about ambisonics and thereby miss out on a relev= ant information. In any case, I'll defer to the WG and AD.
>

Closing the loop on this point:

We have commonly put updates to RFCs in the documents that create the need = for the updates, even if the update is generally applicable. We have the = =E2=80=9CUpdates/Updated by=E2=80=9D relationships to track this sort of th= ing.

I am sympathetic to Ekr=E2=80=99s argument, in that I agree it would be mor= e convenient for the reader to find the update in a smaller, dedicated draf= t. But at this point in the process, I highly doubt the wg has the energy t= o do that sort of restructuring. Therefore I am inclined to leave this the = way it is.

Thanks,

Ben.





--000000000000d95f2f057435ec34-- From nobody Mon Aug 27 09:14:06 2018 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA57130E1B; Mon, 27 Aug 2018 09:14:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: codec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: codec@ietf.org Message-ID: <153538644474.29950.18018131666898331292@ietfa.amsl.com> Date: Mon, 27 Aug 2018 09:14:04 -0700 Archived-At: Subject: [codec] I-D Action: draft-ietf-codec-ambisonics-10.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 16:14:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec WG of the IETF. Title : Ambisonics in an Ogg Opus Container Authors : Jan Skoglund Michael Graczyk Filename : draft-ietf-codec-ambisonics-10.txt Pages : 10 Date : 2018-08-27 Abstract: This document defines an extension to the Opus audio codec to encapsulate coded ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-ambisonics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-codec-ambisonics-10 https://datatracker.ietf.org/doc/html/draft-ietf-codec-ambisonics-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-ambisonics-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 27 14:26:18 2018 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94082124BE5; Mon, 27 Aug 2018 14:26:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Cc: ben@nostrum.com, The IESG , draft-ietf-codec-ambisonics@ietf.org, codec@ietf.org, tterriberry@mozilla.com, Tim Terriberry , codec-chairs@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153540517660.29963.7454420637051669317.idtracker@ietfa.amsl.com> Date: Mon, 27 Aug 2018 14:26:16 -0700 Archived-At: Subject: [codec] Protocol Action: 'Ambisonics in an Ogg Opus Container' to Proposed Standard (draft-ietf-codec-ambisonics-10.txt) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 21:26:17 -0000 The IESG has approved the following document: - 'Ambisonics in an Ogg Opus Container' (draft-ietf-codec-ambisonics-10.txt) as Proposed Standard This document is the product of the Internet Wideband Audio Codec Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-ambisonics/ Technical Summary This document defines an extension to the Opus audio codec to encapsulate coded ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families. Working Group Summary There were no particularly controversial aspects of this draft, and consensus on all decisions was generally easy to reach. Document Quality The format has been implemented in the open-source libopus library (using an experimental mapping family identifier), with support included in the opus-tools package. Several significant vendors have indicated a plan to implement the specification, including Gooogle, Mozilla, and the open source VideoLAN and FFmpeg projects. Mark Harris performed a particularly thorough review, and motivated many of the necessary updates to RFC 7845. In addition, the updates to the "Opus Channel Mapping Families" IANA registry were reviewed by the original authors of RFC 7845 (which created that registry). Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Timothy B. Terriberry Responsible Area Director: Ben Campbell