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

Benjamin Kaduk <kaduk@mit.edu> Mon, 06 August 2018 17:54 UTC

Return-Path: <kaduk@mit.edu>
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 <kaduk@mit.edu>
To: Jan Skoglund <jks@google.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry <tterriberry@mozilla.com>, codec-chairs@ietf.org, codec@ietf.org
Message-ID: <20180806175442.GN97277@kduck.kaduk.org>
References: <153297931466.7637.15045953147147693291.idtracker@ietfa.amsl.com> <CA+KMCSVVrNbZkqC_8UZr72EsGfD+9Jpt3Oan3iQ=R7B0nUJr+A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+KMCSVVrNbZkqC_8UZr72EsGfD+9Jpt3Oan3iQ=R7B0nUJr+A@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/codec/8b98VGW4cDXSE4EiEEVEbHDXDig>
Subject: Re: [codec] Benjamin Kaduk's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2018 17: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