From nobody Fri Mar 3 15:59:23 2017 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 BD9891299F0; Fri, 3 Mar 2017 15:55:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532977.15846.3357520719260458556.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:29 -0800 Archived-At: Cc: codec@ietf.org Subject: [codec] codec - Requested session has been scheduled for IETF 98 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:30 -0000 Dear Tim Terriberry, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. codec Session 1 (1:00:00) Thursday, Morning Session I 0900-1130 Room Name: Montreux 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Internet Wideband Audio Codec Area Name: Applications and Real-Time Area Session Requester: Tim Terriberry Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: netvc Second Priority: avtcore mmusic payload perc rtcweb rmcat tram People who must be present: Ben Campbell Tim Terriberry Mo Zanaty Resources Requested: Projector in room Special Requests: --------------------------------------------------------- From nobody Tue Mar 7 11:13:32 2017 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 2BC6912948D; Tue, 7 Mar 2017 11:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 BgGwReNxIulb; Tue, 7 Mar 2017 11:13:28 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 6D39C129483; Tue, 7 Mar 2017 11:13:28 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 1BC0BC06F4; Tue, 7 Mar 2017 19:13:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D37sQL61-z_c; Tue, 7 Mar 2017 19:13:28 +0000 (UTC) Received: from [10.252.25.45] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id C1250BFE6F; Tue, 7 Mar 2017 19:13:27 +0000 (UTC) Message-ID: <58BF0657.5000400@xiph.org> Date: Tue, 07 Mar 2017 11:13:27 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "codec-chairs@ietf.org" Subject: [codec] Requests for agenda time X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:13:30 -0000 The CODEC WG is scheduled to meet on Thursday, March 30th 2017 at 9:00 AM in Montreux 3. We currently have one agenda item (draft-ietf-codec-ambisonics-01). If anyone else would like to present in this time slot, please send an e-mail to the chairs before March 15th. From nobody Mon Mar 13 10:08:56 2017 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 E82F612988A for ; Mon, 13 Mar 2017 10:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Tgp6Uafz0LjR for ; Mon, 13 Mar 2017 10:08:53 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 6CB23129860 for ; Mon, 13 Mar 2017 10:08:53 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id l37so108095593wrc.1 for ; Mon, 13 Mar 2017 10:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=arggS2MKIsWsktKBIKGPaajHleGRz7nOAVwXG6Hbq2s=; b=pls0BzjwUWGA2nXgpBU9hO0GszTH5w8aMQte5gulGsYcXcCIVa2rEoJF0cSrzN9VwT SUuOLKHzcAOhOcy3hbPO9RhfQYPSaV9SaKZv0MdCxq76eCaSPtK8tVDyHlKmv+dm6u5Q bbMTEb1Iwnfcc5V+9ogzeICH4ZtsSEh7wiRMybkCvDIrTs+DtEu73gra+cUMnxZltSUV tTUpIPpogUOSYT4mempOQmJYijjv2PlbFhf5xjvsehhodLadub5fVxfcXbNYMAQqPqKH PXgwW4t3na0GnVis4yZgbW85LqT4u3UPZt2f2K0YRltP+U6JGjEfhr+FBTVnv3k7mis8 thvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=arggS2MKIsWsktKBIKGPaajHleGRz7nOAVwXG6Hbq2s=; b=hAccL3DZdJHVaJKgE00VZHza86Ee1qtBSzRHMGhFOfPM2ZOIg6THTIOt0KJoK9Mbog 45QGaSq5EulpvKteZS7Xl+b0obTFKvkZ7sWAx7VZbgtT6kBsn2vGeSri2xMVUrkYK7pk 0xNY3TC2WBrmvuFopIjIxvKYC8yEsez7JVDuqeHl5Cgl1vkADviaVswJgRR+6K1zOMRd bp6qGU6YUA8QTW5saCdLhGwr3h7M44sckMThPhgKWBTEsBKjFJKKVENIrKe9T7NlB7S+ LgCuMrXmKgQZTIk5go78JW7QU6zGxJRnqzHM0DnMpGNuCKxYOAVjeh1NiXwLxTxbhWsE INwg== X-Gm-Message-State: AMke39nXrh/dGeD+3H4MMpr72nGW/anyaS/qJ2PUAP2zGcPQxbkAMaCrw7hpyNjS/aU/xG7vjQTz4XboHfhhLg== X-Received: by 10.223.129.183 with SMTP id 52mr31139589wra.88.1489424931790; Mon, 13 Mar 2017 10:08:51 -0700 (PDT) MIME-Version: 1.0 Sender: markh.sj@gmail.com Received: by 10.223.163.91 with HTTP; Mon, 13 Mar 2017 10:08:51 -0700 (PDT) In-Reply-To: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> From: Mark Harris Date: Mon, 13 Mar 2017 10:08:51 -0700 X-Google-Sender-Auth: vL0WVGgIrtxpu_oqd927TFoJqnI Message-ID: To: Jan Skoglund , "codec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:08:55 -0000 On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin wrote: > 3.2. Channel Mapping Family 3 > > I would suggest removing the "Output Channel Numbering" field because it > is fully equivalent to simply permuting lines of the matrix. Also, I > believe that the size of the matrix was meant to be "32*(N+M)*C bits" > rather than "32*N*C bits". To expand on this a bit, a mapping family maps M+N decoded channels (corresponding to the actual order of the coupled and uncoupled channels in the bitstream) to C output channels (channels with a specific semantic meaning). The additional "Output Channel Numbering" table confuses things by adding an additional mapping from the output channel numbers to a different set of numbers with actual semantic meaning, leaving the output channel numbers with no apparent meaning. This does have a potential benefit as a matrix compression technique, to reduce the size of the matrix when it would contain rows that are all zero. However considering that the matrix occurs only once, and mapping family 2 already offers a way to compress the matrix, this alone does not seem worth the complexity of another level of indirection. If matrix compression is desired it would probably be less confusing to describe it in those terms and keep the semantic meaning tied to the output channels. The description of the Output Channel Numbering also does not specify the intended behavior if the same value appears in the table multiple times. Additionally, section 4.2 describes how to perform a stereo downmix of mapping family 3, but makes assumptions about the output channel numbering. This seems harmful and likely to promote implementations that make similar assumptions. If it is necessary to apply the output channel numbering described in section 3.2 in order to implement a correct stereo downmix, then it would be better to simply use the output channels from section 3 as input to the downmix, consolidating sections 4.1 and 4.2, rather than specify new formulas that make assumptions about the mapping. That would also greatly simplify section 4. Eliminating the Output Channel Numbering table as Jean-Marc suggests should resolve these concerns. On another note, unless I am missing something, the formula in figure 2 does not appear to be correct. For example, according to the formula, k=3 (ACN 2) corresponds to order 0 degree 2, which does not make sense. It is also not clear why this channel index begins at 1, when all others begin at 0. It might also be a good idea to clarify that this is an output channel index, as other uses of channel index in RFC 7845 refer to decoded channel index (and also begin at 0). - Mark From nobody Mon Mar 13 10:39:20 2017 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 CF8D6129981 for ; Mon, 13 Mar 2017 10:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 VUzn_WLub-6y for ; Mon, 13 Mar 2017 10:39:06 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 8026C129979 for ; Mon, 13 Mar 2017 10:39:06 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id i34so37455279qtc.0 for ; Mon, 13 Mar 2017 10:39:06 -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; bh=nRqjYh1HABeNwiq08c3Ei10P2OkmZziMFoLI+g+mP1Q=; b=VjTtBY+D6J/X22gHkXdB8nsyv4zis2+zEj85oDofJNwW/5gOGG278SXdyxmAX/yRRD LCZJoe604lg+uxdSwlDPI5VF9LnqhX8mgK0rYkcF0f2AwHjvf56OBEaBFqKExoQ4Ceew 6ZW9pWR/qhgDbnOVET3mLjXEhP5Jr0ns+aSDZCjMi3plkxK1yUYJXrjlf3N9x1xd0vXo c2yZd3H3pEze5UsO+tYPwITO5odV79T4ULR0C9Iz6wN7TXGluNKRXxruhrVPPeUW/qG+ vs0/Pu3RCzitIWXjukFM0mN2uCtmWPwwocWdmXeQvDASIog+Zzj+w1GKY5gAtbmBI71q +9RQ== 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; bh=nRqjYh1HABeNwiq08c3Ei10P2OkmZziMFoLI+g+mP1Q=; b=Lx9kjgB+uae1cEU1VctCrvBoR39FVJ/hKcFOZxEXG9cKRowy7TDLsM8Kgd6F5GK3lW cFAGxJzl1asGNF2VHXIVXqAG0NRFaMCllK3ySc4641Vboqs86EQqZU0l1aLj3Gez3Wwh gvMutY+sUincpj8OYkC1XFNjKQWH9dynSbidjZoCWk+RkZirL6/Hc5ZUxibTWfEwAUMQ p65FNE7QJ78UJhGee05meXQjMXfbfSjUFN3qfLuPvh4xsuR7NnP6sv0YZoFlRFxijoQh 2wdxHtMCzWf4EggTaGGvR02SbftsB0st729LhqferDHB8vfBEW1Z1CaqYRYnXfzpxlZJ zWHw== X-Gm-Message-State: AMke39lmYpO4tCXlMFLOwczoLYyqSFssKmR5TlBGT3M+jBykH9QkRvMSKmeqEs6N2l/qHLD9twNa5rsLZkZRlsuw X-Received: by 10.237.57.164 with SMTP id m33mr35587856qte.293.1489426745430; Mon, 13 Mar 2017 10:39:05 -0700 (PDT) MIME-Version: 1.0 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> In-Reply-To: From: Jan Skoglund Date: Mon, 13 Mar 2017 17:38:54 +0000 Message-ID: To: Mark Harris , "codec@ietf.org" Content-Type: multipart/alternative; boundary=001a1141030614ff0e054aa0307e Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:39:12 -0000 --001a1141030614ff0e054aa0307e Content-Type: text/plain; charset=UTF-8 Hey, Thanks for your comments On Mon, Mar 13, 2017 at 10:08 AM Mark Harris wrote: > On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin > wrote: > > 3.2. Channel Mapping Family 3 > > > > I would suggest removing the "Output Channel Numbering" field because it > > is fully equivalent to simply permuting lines of the matrix. Also, I > > believe that the size of the matrix was meant to be "32*(N+M)*C bits" > > rather than "32*N*C bits". > > To expand on this a bit, a mapping family maps M+N decoded channels > (corresponding to the actual order of the coupled and uncoupled > channels in the bitstream) to C output channels (channels with a > specific semantic meaning). The additional "Output Channel Numbering" > table confuses things by adding an additional mapping from the output > channel numbers to a different set of numbers with actual semantic > meaning, leaving the output channel numbers with no apparent meaning. > > This does have a potential benefit as a matrix compression technique, > to reduce the size of the matrix when it would contain rows that are > all zero. However considering that the matrix occurs only once, and > mapping family 2 already offers a way to compress the matrix, this > alone does not seem worth the complexity of another level of > indirection. If matrix compression is desired it would probably be > less confusing to describe it in those terms and keep the semantic > meaning tied to the output channels. > The description of the Output Channel Numbering also does not specify > the intended behavior if the same value appears in the table multiple > times. > > Additionally, section 4.2 describes how to perform a stereo downmix of > mapping family 3, but makes assumptions about the output channel > numbering. This seems harmful and likely to promote implementations > that make similar assumptions. If it is necessary to apply the output > channel numbering described in section 3.2 in order to implement a > correct stereo downmix, then it would be better to simply use the > output channels from section 3 as input to the downmix, consolidating > sections 4.1 and 4.2, rather than specify new formulas that make > assumptions about the mapping. That would also greatly simplify > section 4. > > Eliminating the Output Channel Numbering table as Jean-Marc suggests > should resolve these concerns. > The problem is that once we allow mixed orders there is no unique way for a receiver/decoder to resolve the mapping to ACNs from just a number of total output channels. On another note, unless I am missing something, the formula in figure > 2 does not appear to be correct. For example, according to the > formula, k=3 (ACN 2) corresponds to order 0 degree 2, which does not > make sense. It is also not clear why this channel index begins at 1, > when all others begin at 0. It might also be a good idea to clarify > that this is an output channel index, as other uses of channel index in RFC 7845 refer to decoded channel index (and also begin at 0). > You're completely right, and there's no reason why the channel index should start with 1. - Mark > --001a1141030614ff0e054aa0307e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey,

Thanks for your comments

On Mon, Mar 13, 2017 at 10:08 AM = Mark Harris <mark.hsj@gmail.com> wrote:
On Fri, Feb 17, 2017 a= t 1:57 PM, Jean-Marc Valin <jmvalin@jmvalin.ca> wrote:
> 3.2.=C2=A0 Channel Mapping Family 3
>
> I would suggest removing the "Output Channel Numbering" fiel= d because it
> is fully equivalent to simply permuting lines of the matrix. Also, I > believe that the size of the matrix was meant to be "32*(N+M)*C b= its"
> rather than "32*N*C bits".

To expand on this a bit, a mapping family maps M+N decoded channels
(corresponding to the actual order of the coupled and uncoupled
channels in the bitstream) to C output channels (channels with a
specific semantic meaning).=C2=A0 The additional "Output Channel Numbe= ring"
table confuses things by adding an additional mapping from the output
channel numbers to a different set of numbers with actual semantic
meaning, leaving the output channel numbers with no apparent meaning.

This does have a potential benefit as a matrix compression technique,
to reduce the size of the matrix when it would contain rows that are
all zero.=C2=A0 However considering that the matrix occurs only once, and mapping family 2 already offers a way to compress the matrix, this
alone does not seem worth the complexity of another level of
indirection.=C2=A0 If matrix compression is desired it would probably be less confusing to describe it in those terms and keep the semantic
meaning tied to the output channels.=C2=A0

The description of the Output Channel Numbering also does not specify
the intended behavior if the same value appears in the table multiple
times.

Additionally, section 4.2 describes how to perform a stereo downmix of
mapping family 3, but makes assumptions about the output channel
numbering.=C2=A0 This seems harmful and likely to promote implementations that make similar assumptions.=C2=A0 If it is necessary to apply the output=
channel numbering described in section 3.2 in order to implement a
correct stereo downmix, then it would be better to simply use the
output channels from section 3 as input to the downmix, consolidating
sections 4.1 and 4.2, rather than specify new formulas that make
assumptions about the mapping.=C2=A0 That would also greatly simplify
section 4.

Eliminating the Output Channel Numbering table as Jean-Marc suggests
should resolve these concerns.
The problem is that once we allow mixed orders there is no uniq= ue way for a receiver/decoder=C2=A0
to resolve the mapping to ACN= s from just a number of total output channels.=C2=A0


On another note, unless I am missing something, the formula in figure
2 does not appear to be correct.=C2=A0 For example, according to the
formula, k=3D3 (ACN 2) corresponds to order 0 degree 2, which does not
make sense.=C2=A0 It is also not clear why this channel index begins at 1,<= br class=3D"gmail_msg"> when all others begin at 0.=C2=A0 It might also be a good idea to clarify that this is an output channel index, as other uses of channel index
in RFC 7845 refer to decoded channel index (and also begin at 0).

You're completely right= , and there's no reason why the channel index should start with 1.=C2= =A0


=C2=A0- Mark
--001a1141030614ff0e054aa0307e-- From nobody Mon Mar 13 10:46:32 2017 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 EB45D129972 for ; Mon, 13 Mar 2017 10:46:30 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 GPX7LOo3gYqx for ; Mon, 13 Mar 2017 10:46:29 -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 D9259129969 for ; Mon, 13 Mar 2017 10:46:28 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id 1so228190389qkl.3 for ; Mon, 13 Mar 2017 10:46:28 -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; bh=ofbwTzyuocE+tvmcnIx4+0/I5AYAKAooEmftJS8qNmw=; b=LtukjFG3UEUeequuMlM+0SbWelRFLNTLTVzJPZrmB5v0Cn3vi5/49wQNAA1x7UQRkS 3g58/XzIu6xo1VcYjffQ877QhNMqAyfDWhQmM8DMPFOf1FAZRQejX2YJEHa0HozL/+yL x9xhQlwUUoyJMkZf3R8F5FYU33v/5spC05TajaD1sA/KTVzGdXgbvNGq7lZst+UNtVMW 6yWC3skujeSoIDFun8mkuQq+cQnHN0n8WG+EmNo5LiHip6Q30PKmEaisg3pwdlBXOWHD zUl2Shdq152p2jY/pX7QVKJ64A49AWXkV+lz3L6Aokq0ghEKIku9n6/LCq/qBG/KtgIz Us8A== 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; bh=ofbwTzyuocE+tvmcnIx4+0/I5AYAKAooEmftJS8qNmw=; b=iF3sRPuQvxQ1tWjJvZKXh/BXhCb9hP5EFxjT3CqClvtWzGh+YK5PS+sXm8Uppk7uZw j8FScWumrbZNgemYof3olAd+ACehpX0VyrdSDqFppGZ3D3UBCp4yAfPjuylbuhshI3hb BqKWEbudZesJS4kTnAp4jXrfSwsTR8rgKpM/gMAGaT2GdsYJg/CO78imVoZRWnZWp9CD q9QFOwz4WRjfIhCqpHlFBBZAtEy/lYykneuuT0cilZlwp/usn8xtttgw4DhP2CbIshpi FPX4yZN5ws/T4TslkKY/sdzbDpf6MvYXm1KhQpjpYUqmXr2s82uEg3aOuiQoMOHTm4yU d+fA== X-Gm-Message-State: AMke39mv2c91/EnTjmVmJEg9mFLJB79D2Nrgvxgwa/vUA3fDnBOLHatcMsSjlTB2YDTgwz4XO+fHfHvUQtFo8K6Y X-Received: by 10.55.80.135 with SMTP id e129mr31188674qkb.192.1489427187800; Mon, 13 Mar 2017 10:46:27 -0700 (PDT) MIME-Version: 1.0 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> In-Reply-To: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> From: Jan Skoglund Date: Mon, 13 Mar 2017 17:46:17 +0000 Message-ID: To: Jean-Marc Valin , "codec@ietf.org" Content-Type: multipart/alternative; boundary=001a114a6b4e730b85054aa04aca Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:46:31 -0000 --001a114a6b4e730b85054aa04aca Content-Type: text/plain; charset=UTF-8 Hey Jean-Marc, Thanks for your comments! On Fri, Feb 17, 2017 at 1:57 PM Jean-Marc Valin wrote: Hi Jan, Here's some comments based on my review of the ambisonics draft: 3. Ambisonics With Ogg Opus > Ambisonics MAY be encapsulated in the Ogg format by encoding with the I would suggest replacing the normative MAY by just "can" Agree 3.1. Channel Mapping Family 2 > This channel mapping uses the same channel mapping table format used > by channel mapping families 1 and 255. I would suggest saying "mapping family 1" rather than "mapping families 1 and 255" since otherwise, you have families 2 referencing itself. Also, we don't know what families 4 and up will look like. Agree 3.2. Channel Mapping Family 3 I would suggest removing the "Output Channel Numbering" field because it is fully equivalent to simply permuting lines of the matrix. Allowing mixed orders means that there's no unique configuration for a given total number of channels. Therefore we need to signal to the decoder which ACN numbers each output channel corresponds to. About the matrix -- and as previously discussed privately -- I think it should probably be stored as 16-bit integers in Q15 format. If any global scaling is ever required, then the "output gain" field can always be used. Sure, this will work. > Note that [RFC7845] specifies that the identification header cannot > exceed one "page", which is 65,025 octets. This sets a practical > maximum ambisonic order of 10, if full order is utilized and the > number of coded streams is the same as the ambisonic order plus the > two non-diegetic channels. This text is unclear about whether partial order 11 is allowed. I have no strong opinion on the subject, but think it should be clarified. OK, I don't think we need to to specify a maximum allowed, just point out the headroom's practical aspect Cheers, Jean-Marc Cheers, Jan --001a114a6b4e730b85054aa04aca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Jean-Marc,

Th= anks for your comments!

On Fri, Feb 17, 2017 at 1:57 PM Jean= -Marc Valin <jmvalin@jmvalin.ca> wrote:
<= /div>
Hi Jan,

Here's some comments based on my review of the ambisonics draft:

3.=C2=A0 Ambisonics With Ogg Opus

>=C2=A0 =C2=A0 Ambisonics MAY be encapsulated in the Ogg format by encod= ing with the

I would suggest replacing the normative MAY by just "can"

Agree
=C2=A0
3.1.=C2=A0 Channel Mapping Family 2

>=C2=A0 =C2=A0 This channel mapping uses the same channel mapping table = format used
>=C2=A0 =C2=A0 by channel mapping families 1 and 255.

I would suggest saying "mapping family 1" rather than "mappi= ng families
1 and 255" since otherwise, you have families 2 referencing itself. Also, we don't know what families 4 and up will look like.

Agre= e
= =C2=A0
3.2.=C2=A0 Channel Mapping Family 3

I would suggest removing the "Output Channel Numbering" field bec= ause it
is fully equivalent to simply permuting lines of the matrix.

Allowing mixed orders means th= at there's no unique configuration for a given total number of channels= .
Therefore we need to signal to the decoder = which ACN numbers each output channel corresponds to. =C2=A0

=C2=A0
About the matrix -- and as previously discussed privately -- I think it
should probably be stored as 16-bit integers in Q15 format. If any
global scaling is ever required, then the "output gain" field can= always
be used.

Sure, this= will work.
=C2=A0

>=C2=A0 =C2=A0 Note that [RFC7845] specifies that the identification hea= der cannot
>=C2=A0 =C2=A0 exceed one "page", which is 65,025 octets.=C2= =A0 This sets a practical
>=C2=A0 =C2=A0 maximum ambisonic order of 10, if full order is utilized = and the
>=C2=A0 =C2=A0 number of coded streams is the same as the ambisonic orde= r plus the
>=C2=A0 =C2=A0 two non-diegetic channels.

This text is unclear about whether partial order 11 is allowed. I have
no strong opinion on the subject, but think it should be clarified.

OK, I don't think we n= eed to to specify a maximum allowed, just point out the headroom's prac= tical aspect
=C2=A0
Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc
<= div>
Cheers,
Jan=C2=A0
=C2=A0
= --001a114a6b4e730b85054aa04aca-- From nobody Mon Mar 13 14:41:03 2017 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 C0FE6127058 for ; Mon, 13 Mar 2017 14:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jRu51kFhFFyX for ; Mon, 13 Mar 2017 14:40:59 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 CA0A61297F1 for ; Mon, 13 Mar 2017 14:40:57 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n11so50611667wma.1 for ; Mon, 13 Mar 2017 14:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=86VTz7w+6Jm6ljEk8nFhvnboOyjmnwZyTHHMaO41Aww=; b=VwrSPJ6xxOGaw02DxG5OKXxHFBJyyPHM7PTi/8qF0dnoY/aHEdjZUlykYJgkyD1ysO aTxklCZJ+cUB88wO6eelJCkKlVrt7QDDyC2I2wmD+OexU68JzJsuANVAura38jwRbdXk uqZ4/9OBQNAG0fKVEn22dNl+OGyYhYZ8kOUdMHju98Iec438bytQIHN1qoFlMUXd53hJ hmCynhNl0B+aNIMsCo1afjliLW99Dn7K5LsfMVBBl+K/yT6fzyr3ox4q6mtY3F/Cjuqa fSHCqOulyEmshlAssvByl/1iafxi1nhHBaIKjw/ivnp4gYVMS4h9NAegL/LUp3vF3xPG cYdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=86VTz7w+6Jm6ljEk8nFhvnboOyjmnwZyTHHMaO41Aww=; b=M1M5POogJmWrcWtQAdLLc61ooXM0YxuDWzflbNdRWAfa0Zln4IJxbYr5bsZJxMPTyu 3WVn+h08vgeCWBcAhMH9WRDA+ApWMYFVCD3ca5vqxHa4EzXW63A6AV6U0C8Aa+FH3SxI 35o+asW6QaIvYHNGSDVEqCdtRgGQ03dEFIK141Dv7zfx0hxQr5t/2JMD/IrV760d1I9l n8EQyC4zQHxIZfEtEG54MSn5E4Dsigu5rAemG3u9gvZFCcPlC/F7ePQQtFqy7OGjQq+m wjjvujWGZTfKG6EO6Ducf5xlS/+xOVFIIUcZrxjSyqEkOwNLJJAFLgzAC7shs7fccG+6 lCiA== X-Gm-Message-State: AFeK/H1v3M/7eaYRKH8unNuW+M24EgcxOR1mdV5YogJKUYKg6gDj4y4tOgwwZoNEJynBz0V28jYu8ZgYdnJf3A== X-Received: by 10.28.232.13 with SMTP id f13mr11758831wmh.141.1489441256321; Mon, 13 Mar 2017 14:40:56 -0700 (PDT) MIME-Version: 1.0 Sender: markh.sj@gmail.com Received: by 10.223.163.91 with HTTP; Mon, 13 Mar 2017 14:40:55 -0700 (PDT) In-Reply-To: References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> From: Mark Harris Date: Mon, 13 Mar 2017 14:40:55 -0700 X-Google-Sender-Auth: rNtlBQEdgf7xGcbc90nyrgDn6mc Message-ID: To: Jan Skoglund , "codec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:41:02 -0000 On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund wrote: > Hey, > > Thanks for your comments > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris wrote: >> >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin >> wrote: >> > 3.2. Channel Mapping Family 3 >> > >> > I would suggest removing the "Output Channel Numbering" field because it >> > is fully equivalent to simply permuting lines of the matrix. Also, I >> > believe that the size of the matrix was meant to be "32*(N+M)*C bits" >> > rather than "32*N*C bits". >> >> To expand on this a bit, a mapping family maps M+N decoded channels >> (corresponding to the actual order of the coupled and uncoupled >> channels in the bitstream) to C output channels (channels with a >> specific semantic meaning). The additional "Output Channel Numbering" >> table confuses things by adding an additional mapping from the output >> channel numbers to a different set of numbers with actual semantic >> meaning, leaving the output channel numbers with no apparent meaning. >> >> This does have a potential benefit as a matrix compression technique, >> to reduce the size of the matrix when it would contain rows that are >> all zero. However considering that the matrix occurs only once, and >> mapping family 2 already offers a way to compress the matrix, this >> alone does not seem worth the complexity of another level of >> indirection. If matrix compression is desired it would probably be >> less confusing to describe it in those terms and keep the semantic >> meaning tied to the output channels. >> >> >> The description of the Output Channel Numbering also does not specify >> the intended behavior if the same value appears in the table multiple >> times. >> >> Additionally, section 4.2 describes how to perform a stereo downmix of >> mapping family 3, but makes assumptions about the output channel >> numbering. This seems harmful and likely to promote implementations >> that make similar assumptions. If it is necessary to apply the output >> channel numbering described in section 3.2 in order to implement a >> correct stereo downmix, then it would be better to simply use the >> output channels from section 3 as input to the downmix, consolidating >> sections 4.1 and 4.2, rather than specify new formulas that make >> assumptions about the mapping. That would also greatly simplify >> section 4. >> >> Eliminating the Output Channel Numbering table as Jean-Marc suggests >> should resolve these concerns. > > > The problem is that once we allow mixed orders there is no unique way for a > receiver/decoder > to resolve the mapping to ACNs from just a number of total output channels. In mapping family 2, the channel count (C) is the number of channels in the fully periphonic configuration, but it is not necessary to encode them all. The channel mapping table can map each ACN to a specific decoded channel or to silence. For mixed order, some of the ACNs will be mapped to silence and will not be encoded. In mapping family 3, the matrix can do everything that the channel mapping table can do and more. Why not treat C in the same manner, as the number of channels in the fully periphonic configuration, even if some are silent? - Mark From nobody Mon Mar 13 14:44:35 2017 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 599E9129477 for ; Mon, 13 Mar 2017 14:44:34 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 dEqDZ_8SyPj6 for ; Mon, 13 Mar 2017 14:44:32 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 DEDC9127058 for ; Mon, 13 Mar 2017 14:44:31 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id y193so69171414lfd.3 for ; Mon, 13 Mar 2017 14:44:31 -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; bh=eSwfDCW1+DQ34ed+iyz6fqGrO/MQ00uZpN68mfAqnRE=; b=oyTKQw2Gp2BvcY3DaQ2TE6K/njFcjtXsaLZyqUskkG2eZpAw57HnP0GYll4dCWX2Pb VPJ6XZTWD9NHHAv5dRFgk3d3Tj472PUtbS2B0n52uD/mit5JGo0b2EkxTgmMC5zGx8sT L58RedF6z5xXOkIzBFLzXkHDc6uT05MNJ5RXJwU5dcEmxKWVUdliqO5G9Bl9lhYPVMPv Dt1paFQTeDfsJcfRtWJQG4JFznmrA0ejjOIDmGIL4NGvJYKbVEf7fA6sOJBKOTv8Gjnz Je6+fxOTmz5hkL9OECqq/+LYuSBBHs/qbRXsQYCAjbCblNiF8QiJTRoOwnjAodnLgxJu RJJw== 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; bh=eSwfDCW1+DQ34ed+iyz6fqGrO/MQ00uZpN68mfAqnRE=; b=jO/1JrbzBax7nzmnaMcblXe3wLt9ikY7OekOPTH2pPo+lCZFoXoYDNAPSoYvwnNhDQ nCip0fvpvkU/56cicG3A2ay+BENkXnkAL/xm388AMxFzhN8CGq8/P2m1i0Dp8CKN3Dit lt+NU6W6JmQVr2gls4t3NyRICZaoXmN5livI4GogvZwxG1GGxUXwpmAUVsSECfBfU6Xt D/IwyZKOfpdp+++0MnSPWYpr2Gb+noLG2HSAvtJ1PQBAONNmqAcj1ZjqLDvwSnFk30DV a2ILMcdkBc+sdH4fP3v5rKK88GYsrN51XviOeaowcSgGCXR8mtlYlLALRfp0T4MoB4lZ oE8Q== X-Gm-Message-State: AMke39lXWPsfF1ORnIexvc1MTl37MCjyN0L1bsNFucsuQv6k6ZmZI21gCkw2uwGtmdbz0XfKHExl7+N3xWnIgkTZ X-Received: by 10.46.77.72 with SMTP id a69mr10864299ljb.104.1489441470079; Mon, 13 Mar 2017 14:44:30 -0700 (PDT) MIME-Version: 1.0 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> In-Reply-To: From: Drew Allen Date: Mon, 13 Mar 2017 21:44:19 +0000 Message-ID: To: Mark Harris , Jan Skoglund , "codec@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1aba80bd20d4054aa39def Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:44:34 -0000 --94eb2c1aba80bd20d4054aa39def Content-Type: text/plain; charset=UTF-8 I think the issue is that the number of total channels rises quadratically in respect to the ambisonic order (N + 1)^2. If a user wants to use just the horizontal channels, it is only 2 * N + 1. If they wish to code very high-order (>10th order) horizontal channels, they would be artifically limited by all the zero channels being produced, no? Or can this handled without actually creating all those empty channels? On Mon, Mar 13, 2017 at 2:41 PM Mark Harris wrote: > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund wrote: > > Hey, > > > > Thanks for your comments > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris wrote: > >> > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin > >> wrote: > >> > 3.2. Channel Mapping Family 3 > >> > > >> > I would suggest removing the "Output Channel Numbering" field because > it > >> > is fully equivalent to simply permuting lines of the matrix. Also, I > >> > believe that the size of the matrix was meant to be "32*(N+M)*C bits" > >> > rather than "32*N*C bits". > >> > >> To expand on this a bit, a mapping family maps M+N decoded channels > >> (corresponding to the actual order of the coupled and uncoupled > >> channels in the bitstream) to C output channels (channels with a > >> specific semantic meaning). The additional "Output Channel Numbering" > >> table confuses things by adding an additional mapping from the output > >> channel numbers to a different set of numbers with actual semantic > >> meaning, leaving the output channel numbers with no apparent meaning. > >> > >> This does have a potential benefit as a matrix compression technique, > >> to reduce the size of the matrix when it would contain rows that are > >> all zero. However considering that the matrix occurs only once, and > >> mapping family 2 already offers a way to compress the matrix, this > >> alone does not seem worth the complexity of another level of > >> indirection. If matrix compression is desired it would probably be > >> less confusing to describe it in those terms and keep the semantic > >> meaning tied to the output channels. > >> > >> > >> The description of the Output Channel Numbering also does not specify > >> the intended behavior if the same value appears in the table multiple > >> times. > >> > >> Additionally, section 4.2 describes how to perform a stereo downmix of > >> mapping family 3, but makes assumptions about the output channel > >> numbering. This seems harmful and likely to promote implementations > >> that make similar assumptions. If it is necessary to apply the output > >> channel numbering described in section 3.2 in order to implement a > >> correct stereo downmix, then it would be better to simply use the > >> output channels from section 3 as input to the downmix, consolidating > >> sections 4.1 and 4.2, rather than specify new formulas that make > >> assumptions about the mapping. That would also greatly simplify > >> section 4. > >> > >> Eliminating the Output Channel Numbering table as Jean-Marc suggests > >> should resolve these concerns. > > > > > > The problem is that once we allow mixed orders there is no unique way > for a > > receiver/decoder > > to resolve the mapping to ACNs from just a number of total output > channels. > > > In mapping family 2, the channel count (C) is the number of channels > in the fully periphonic configuration, but it is not necessary to > encode them all. The channel mapping table can map each ACN to a > specific decoded channel or to silence. For mixed order, some of the > ACNs will be mapped to silence and will not be encoded. > > In mapping family 3, the matrix can do everything that the channel > mapping table can do and more. Why not treat C in the same manner, as > the number of channels in the fully periphonic configuration, even if > some are silent? > > - Mark > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --94eb2c1aba80bd20d4054aa39def Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the issue is that the number of total channels ris= es quadratically in respect to the ambisonic order (N + 1)^2. If a user wan= ts to use just the horizontal channels, it is only 2 * N + 1. If they wish = to code very high-order (>10th order) horizontal channels, they would be= artifically limited by all the zero channels being produced, no? Or can th= is handled without actually creating all those empty channels?

On Mon, Mar 13, 2017 at 2:41 PM Ma= rk Harris <mark.hsj@gmail.com&= gt; wrote:
On Mon, Mar 13, 2017 at = 10:38 AM, Jan Skoglund <jks@google.com> wrote:
> Hey,
>
> Thanks for your comments
>
> On Mon, Mar 13, 2017 at 10:08 AM Mark Harris <mark.hsj@gmail.com> wrote:
>>
>> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin <jmvalin@jmva= lin.ca>
>> wrote:
>> > 3.2.=C2=A0 Channel Mapping Family 3
>> >
>> > I would suggest removing the "Output Channel Numbering&q= uot; field because it
>> > is fully equivalent to simply permuting lines of the matrix. = Also, I
>> > believe that the size of the matrix was meant to be "32*= (N+M)*C bits"
>> > rather than "32*N*C bits".
>>
>> To expand on this a bit, a mapping family maps M+N decoded channel= s
>> (corresponding to the actual order of the coupled and uncoupled >> channels in the bitstream) to C output channels (channels with a >> specific semantic meaning).=C2=A0 The additional "Output Chan= nel Numbering"
>> table confuses things by adding an additional mapping from the out= put
>> channel numbers to a different set of numbers with actual semantic=
>> meaning, leaving the output channel numbers with no apparent meani= ng.
>>
>> This does have a potential benefit as a matrix compression techniq= ue,
>> to reduce the size of the matrix when it would contain rows that a= re
>> all zero.=C2=A0 However considering that the matrix occurs only on= ce, and
>> mapping family 2 already offers a way to compress the matrix, this=
>> alone does not seem worth the complexity of another level of
>> indirection.=C2=A0 If matrix compression is desired it would proba= bly be
>> less confusing to describe it in those terms and keep the semantic=
>> meaning tied to the output channels.
>>
>>
>> The description of the Output Channel Numbering also does not spec= ify
>> the intended behavior if the same value appears in the table multi= ple
>> times.
>>
>> Additionally, section 4.2 describes how to perform a stereo downmi= x of
>> mapping family 3, but makes assumptions about the output channel >> numbering.=C2=A0 This seems harmful and likely to promote implemen= tations
>> that make similar assumptions.=C2=A0 If it is necessary to apply t= he output
>> channel numbering described in section 3.2 in order to implement a=
>> correct stereo downmix, then it would be better to simply use the<= br class=3D"gmail_msg"> >> output channels from section 3 as input to the downmix, consolidat= ing
>> sections 4.1 and 4.2, rather than specify new formulas that make >> assumptions about the mapping.=C2=A0 That would also greatly simpl= ify
>> section 4.
>>
>> Eliminating the Output Channel Numbering table as Jean-Marc sugges= ts
>> should resolve these concerns.
>
>
> The problem is that once we allow mixed orders there is no unique way = for a
> receiver/decoder
> to resolve the mapping to ACNs from just a number of total output chan= nels.


In mapping family 2, the channel count (C) is the number of channels
in the fully periphonic configuration, but it is not necessary to
encode them all.=C2=A0 The channel mapping table can map each ACN to a
specific decoded channel or to silence.=C2=A0 For mixed order, some of the<= br class=3D"gmail_msg"> ACNs will be mapped to silence and will not be encoded.

In mapping family 3, the matrix can do everything that the channel
mapping table can do and more.=C2=A0 Why not treat C in the same manner, as=
the number of channels in the fully periphonic configuration, even if
some are silent?

=C2=A0- Mark

_______________________________________________
codec mailing list
cod= ec@ietf.org
https://www.ietf.org/mailman/listinfo= /codec
--94eb2c1aba80bd20d4054aa39def-- From nobody Mon Mar 13 14:55:14 2017 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 81025129BC5 for ; Mon, 13 Mar 2017 14:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 vd-9F8JhLNP2 for ; Mon, 13 Mar 2017 14:55:10 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 A328A129BBF for ; Mon, 13 Mar 2017 14:55:10 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id w124so20726131itb.1 for ; Mon, 13 Mar 2017 14:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=eS9+lRh5wWec8Gn6y0A1JaiR/+R6LVasWy2K6/+2Wmk=; b=WOU68H+vXArNvvMh3Jin52HpAUf30dikyi+ZXOlzNp9d75P2H5/zkQsOz7JTpQo1jr i1rfg5auFVBBnDlKlarP5fHFgCsQqGU/s8sW/HmonKkrkWTAtqWU7OWUQ7rLmhzHdF7/ YyNjvgph75DcPbwYnvd4zKQkn2KazAs7mb6Zk= 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:from:message-id:date :user-agent:mime-version:in-reply-to; bh=eS9+lRh5wWec8Gn6y0A1JaiR/+R6LVasWy2K6/+2Wmk=; b=OuVH52lhMd1mOuTMMh7RL1pJPcWACYYSVTtgXcpNXi1UIog1Rq7xIKeFqaAq/7E28S Nmhn+S3y8gSocTzhamsDhtrxfIEnfXczdgTAzE4VUbG/PlX79bbLjVpyz4uRHu7Xlyjr es3dO51sre2Ap8OaKPCbhYvMB0x6UhphN7uzNNxqSMgK+1zBu9lI0esq8bIY3l2iaATs bzv0Y1NTdNopsvaPp2YiCR1ifH7ORSMnwhQE4CXY6y+UiyrqgARvigQ4B6UqyGUivY6M eYQRlpLt0CzzDWbAaytZVh/PG7dHhFskn17zJlSXhcXDVaRNHZMZVAXI3nAP6j86tfdB dSEA== X-Gm-Message-State: AFeK/H2FzsGuxSWgknucu1CBQSe8fWIi2qaIP4lqVzwNI5zpCbrGWxLGRF+9PV7cv+eMXdHE X-Received: by 10.36.6.72 with SMTP id 69mr13714969itv.75.1489442109874; Mon, 13 Mar 2017 14:55:09 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable067.31-56-74.mc.videotron.ca. [74.56.31.67]) by smtp.gmail.com with ESMTPSA id y21sm8785461ioi.0.2017.03.13.14.55.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 14:55:09 -0700 (PDT) To: Drew Allen , Mark Harris , Jan Skoglund , "codec@ietf.org" References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> From: Jean-Marc Valin Message-ID: <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> Date: Mon, 13 Mar 2017 17:55:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KORVi6DJm5wnPcDJhq6Iolm3xeMwHlfu2" Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:55:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KORVi6DJm5wnPcDJhq6Iolm3xeMwHlfu2 Content-Type: multipart/mixed; boundary="80qVM68AaPDbS5iLARm83mFGcecH2Kv8P"; protected-headers="v1" From: Jean-Marc Valin To: Drew Allen , Mark Harris , Jan Skoglund , "codec@ietf.org" Message-ID: <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> In-Reply-To: --80qVM68AaPDbS5iLARm83mFGcecH2Kv8P Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 13/03/17 05:44 PM, Drew Allen wrote: > I think the issue is that the number of total channels rises > quadratically in respect to the ambisonic order (N + 1)^2. If a user > wants to use just the horizontal channels, it is only 2 * N + 1. If the= y > wish to code very high-order (>10th order) horizontal channels, they > would be artifically limited by all the zero channels being produced, > no? Or can this handled without actually creating all those empty chann= els? As far as I understand, the current draft already has all the limitations you're describing. The channel mapping array is basically equivalent to a CxC permutation matrix that multiplies the Cx(N+M) weight matrix. The result is still a Cx(N+M) matrix, so using the resulting matrix as weights can still do everything without the need for the channel mapping to do the permutations. Cheers, Jean-Marc > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris > wrote: >=20 > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund > wrote: > > Hey, > > > > Thanks for your comments > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris > wrote: > >> > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin > > > >> wrote: > >> > 3.2. Channel Mapping Family 3 > >> > > >> > I would suggest removing the "Output Channel Numbering" field > because it > >> > is fully equivalent to simply permuting lines of the matrix. > Also, I > >> > believe that the size of the matrix was meant to be "32*(N+M)*= C > bits" > >> > rather than "32*N*C bits". > >> > >> To expand on this a bit, a mapping family maps M+N decoded chann= els > >> (corresponding to the actual order of the coupled and uncoupled > >> channels in the bitstream) to C output channels (channels with a= > >> specific semantic meaning). The additional "Output Channel > Numbering" > >> table confuses things by adding an additional mapping from the o= utput > >> channel numbers to a different set of numbers with actual semant= ic > >> meaning, leaving the output channel numbers with no apparent mea= ning. > >> > >> This does have a potential benefit as a matrix compression techn= ique, > >> to reduce the size of the matrix when it would contain rows that= are > >> all zero. However considering that the matrix occurs only once,= and > >> mapping family 2 already offers a way to compress the matrix, th= is > >> alone does not seem worth the complexity of another level of > >> indirection. If matrix compression is desired it would probably= be > >> less confusing to describe it in those terms and keep the semant= ic > >> meaning tied to the output channels. > >> > >> > >> The description of the Output Channel Numbering also does not sp= ecify > >> the intended behavior if the same value appears in the table mul= tiple > >> times. > >> > >> Additionally, section 4.2 describes how to perform a stereo > downmix of > >> mapping family 3, but makes assumptions about the output channel= > >> numbering. This seems harmful and likely to promote implementat= ions > >> that make similar assumptions. If it is necessary to apply the > output > >> channel numbering described in section 3.2 in order to implement= a > >> correct stereo downmix, then it would be better to simply use th= e > >> output channels from section 3 as input to the downmix, consolid= ating > >> sections 4.1 and 4.2, rather than specify new formulas that make= > >> assumptions about the mapping. That would also greatly simplify= > >> section 4. > >> > >> Eliminating the Output Channel Numbering table as Jean-Marc sugg= ests > >> should resolve these concerns. > > > > > > The problem is that once we allow mixed orders there is no unique= > way for a > > receiver/decoder > > to resolve the mapping to ACNs from just a number of total output= > channels. >=20 >=20 > In mapping family 2, the channel count (C) is the number of channel= s > in the fully periphonic configuration, but it is not necessary to > encode them all. The channel mapping table can map each ACN to a > specific decoded channel or to silence. For mixed order, some of t= he > ACNs will be mapped to silence and will not be encoded. >=20 > In mapping family 3, the matrix can do everything that the channel > mapping table can do and more. Why not treat C in the same manner,= as > the number of channels in the fully periphonic configuration, even = if > some are silent? >=20 > - Mark >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 --80qVM68AaPDbS5iLARm83mFGcecH2Kv8P-- --KORVi6DJm5wnPcDJhq6Iolm3xeMwHlfu2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYxxU7AAoJEF5d2aNvkYnIfSEQAJfupB5TNtLi+C6+q2IwLEGO Bx4iqfiF4JjXe2Sp521xUF53Q9YpsqHwKmwKNOAdTHjQQ5LNDiBuc52tSqRdQkKD +U7gwNkKauOv95dLhLDYENhnM1sB/TcchE5nNPE9pFfV+hYqcoFC7g5WNtpcK0jz sNRsXtM4lj1S/iX7JnoqysCKZq5dAT4X0FctOU69/GJHwD4Revch8GihCsfJsqdP UwfxjsM7EAW0oZmvU5Xp2kVAEQ7cmWGmntQ1QSGXOLle/vHGm9ltpPz5NTQZh8Eq wxRY7feN+zLggXMN9Plluet0I8z5N9WXIEgfu5CWKxNx1uan59P314SHQF3pGaV0 1dlKQXGXithD08SSJxgiRRiPWm6AHCze5gygAEhDOJmnLutO9RhIYB9VsAWcTliV OUX3ILrD7bo1tFNv0Dq0BSkTfi6CC3obHs1Yx+IDvaqlqgCiTYFR9aUimeIxcS6B i0FTlLWsJ++XOd2CTBo9K2mWQydTUd/IpEskPugvGRbO7G3AK9k7XzzEL+OGEeyT hOAL2wY0dDw94VVwV2z/rvXlQEz0E0Vxf05gwJaq7/PdhhpAJNNm/gRuPOEuVpj6 EfoOkz2+RoO/holC27vZwjvsLO1T3kw59D3Rpeo5fAkTlHQPG14JHohxNXbx0Zui cxDzKAn/3X81yRgM2wf2 =rRCi -----END PGP SIGNATURE----- --KORVi6DJm5wnPcDJhq6Iolm3xeMwHlfu2-- From nobody Mon Mar 13 15:01:16 2017 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 E6DC21293FB for ; Mon, 13 Mar 2017 15:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 DPpiML_Us8u0 for ; Mon, 13 Mar 2017 15:01:06 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 26544129BE5 for ; Mon, 13 Mar 2017 15:01:06 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id j90so69428978lfk.2 for ; Mon, 13 Mar 2017 15:01:06 -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; bh=SEvVBZ64ymqWCVUJ7WUSqgoqt34JuwzPpNm/wrqm00Q=; b=KHDD3GKbunecHGfWRCgXF+/T7d7Jjn9xM9IEgBL4RE0QGGg0dw3Grjv6fiB2YuOopR 9daFrh8+Bj9M91iQWcIjIyw1odYiqrpyrza+NLRmI76IqmeyqNlmP9XZyjAXVMeFME3e 20Z6PE1kOzmrLCwvtgYab3ObqEn0AHsK9LF4UnqkOVCsCeDhoqAKplpPcBPQUKp5MXJv GAu1f3RLx68btd9dDlreDadm3EZJR0j7AVfMgoPue5lQqLM8cHxQiL3aTFi/hV41nBmZ cv9ZTKyJBu+rhxjhAevWsNSyjxx8U1Oi69mjm196gC8/dLvO+drfbJ7EhhgEaRtxoExy iuyw== 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; bh=SEvVBZ64ymqWCVUJ7WUSqgoqt34JuwzPpNm/wrqm00Q=; b=SThP0fGKbW8qZkrEZ/4sdOWvRmIhTc2n97ATa3+1MhFiEb7twJXQDWEtQGBXWVGjd0 Pfl/iCyOctZnYGCmDWYtj3eG9LMLd+evQ54yXfE9apDlGgHonqk4CUrwtP62KAFh1zT+ MvA+1b6ZghYxeU0LzSrxqsbGcGs9dYLNbfnEJQ06lFOIH5m7DaCk7Q84mwtEI3HSupwL YmaNgUg/ic5WvnH65H/jKMAZE4kg7HtRH3dcodvprFDuwQBw+3WxzHleXSI9rlk+Zdvs InQONxc/sLNWKmCTt11+SPkEjgdacSDD/qk/Bdh8X3PG7c5WqnkkYr26DxSAwR3Ci43T WR+w== X-Gm-Message-State: AMke39kPP3R2gX30L5y0EGAZFsgMG2PC9XtBVzRZYfCVclQF93VaJVK5B6oOfgbXzzXx8iWUGBhDGfSIgu+vf7ZQ X-Received: by 10.25.216.103 with SMTP id p100mr8845496lfg.16.1489442464180; Mon, 13 Mar 2017 15:01:04 -0700 (PDT) MIME-Version: 1.0 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> In-Reply-To: <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> From: Drew Allen Date: Mon, 13 Mar 2017 22:00:53 +0000 Message-ID: To: Jean-Marc Valin , Mark Harris , Jan Skoglund , "codec@ietf.org" Content-Type: multipart/alternative; boundary=001a114005aafdfdbb054aa3d827 Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:01:15 -0000 --001a114005aafdfdbb054aa3d827 Content-Type: text/plain; charset=UTF-8 Got it. In that case, it certainly seems reasonable if I understand correctly. Thanks for clearing that up! On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin wrote: > On 13/03/17 05:44 PM, Drew Allen wrote: > > I think the issue is that the number of total channels rises > > quadratically in respect to the ambisonic order (N + 1)^2. If a user > > wants to use just the horizontal channels, it is only 2 * N + 1. If they > > wish to code very high-order (>10th order) horizontal channels, they > > would be artifically limited by all the zero channels being produced, > > no? Or can this handled without actually creating all those empty > channels? > > As far as I understand, the current draft already has all the > limitations you're describing. The channel mapping array is basically > equivalent to a CxC permutation matrix that multiplies the Cx(N+M) > weight matrix. The result is still a Cx(N+M) matrix, so using the > resulting matrix as weights can still do everything without the need for > the channel mapping to do the permutations. > > Cheers, > > Jean-Marc > > > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris > > wrote: > > > > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund > > wrote: > > > Hey, > > > > > > Thanks for your comments > > > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris > > wrote: > > >> > > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin > > > > > >> wrote: > > >> > 3.2. Channel Mapping Family 3 > > >> > > > >> > I would suggest removing the "Output Channel Numbering" field > > because it > > >> > is fully equivalent to simply permuting lines of the matrix. > > Also, I > > >> > believe that the size of the matrix was meant to be "32*(N+M)*C > > bits" > > >> > rather than "32*N*C bits". > > >> > > >> To expand on this a bit, a mapping family maps M+N decoded > channels > > >> (corresponding to the actual order of the coupled and uncoupled > > >> channels in the bitstream) to C output channels (channels with a > > >> specific semantic meaning). The additional "Output Channel > > Numbering" > > >> table confuses things by adding an additional mapping from the > output > > >> channel numbers to a different set of numbers with actual semantic > > >> meaning, leaving the output channel numbers with no apparent > meaning. > > >> > > >> This does have a potential benefit as a matrix compression > technique, > > >> to reduce the size of the matrix when it would contain rows that > are > > >> all zero. However considering that the matrix occurs only once, > and > > >> mapping family 2 already offers a way to compress the matrix, this > > >> alone does not seem worth the complexity of another level of > > >> indirection. If matrix compression is desired it would probably > be > > >> less confusing to describe it in those terms and keep the semantic > > >> meaning tied to the output channels. > > >> > > >> > > >> The description of the Output Channel Numbering also does not > specify > > >> the intended behavior if the same value appears in the table > multiple > > >> times. > > >> > > >> Additionally, section 4.2 describes how to perform a stereo > > downmix of > > >> mapping family 3, but makes assumptions about the output channel > > >> numbering. This seems harmful and likely to promote > implementations > > >> that make similar assumptions. If it is necessary to apply the > > output > > >> channel numbering described in section 3.2 in order to implement a > > >> correct stereo downmix, then it would be better to simply use the > > >> output channels from section 3 as input to the downmix, > consolidating > > >> sections 4.1 and 4.2, rather than specify new formulas that make > > >> assumptions about the mapping. That would also greatly simplify > > >> section 4. > > >> > > >> Eliminating the Output Channel Numbering table as Jean-Marc > suggests > > >> should resolve these concerns. > > > > > > > > > The problem is that once we allow mixed orders there is no unique > > way for a > > > receiver/decoder > > > to resolve the mapping to ACNs from just a number of total output > > channels. > > > > > > In mapping family 2, the channel count (C) is the number of channels > > in the fully periphonic configuration, but it is not necessary to > > encode them all. The channel mapping table can map each ACN to a > > specific decoded channel or to silence. For mixed order, some of the > > ACNs will be mapped to silence and will not be encoded. > > > > In mapping family 3, the matrix can do everything that the channel > > mapping table can do and more. Why not treat C in the same manner, > as > > the number of channels in the fully periphonic configuration, even if > > some are silent? > > > > - Mark > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > > --001a114005aafdfdbb054aa3d827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Got it. In that case, it certainly seems reasonable if I u= nderstand correctly. Thanks for clearing that up!

On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin= <jmvalin@mozilla.com> wro= te:
On 13/03/17 05:44 PM, Drew Alle= n wrote:
> I think the issue is that the number of total channels rises
> quadratically in respect to the ambisonic order (N + 1)^2. If a user > wants to use just the horizontal channels, it is only 2 * N + 1. If th= ey
> wish to code very high-order (>10th order) horizontal channels, the= y
> would be artifically limited by all the zero channels being produced,<= br class=3D"gmail_msg"> > no? Or can this handled without actually creating all those empty chan= nels?

As far as I understand, the current draft already has all the
limitations you're describing. The channel mapping array is basically equivalent to a CxC permutation matrix that multiplies the Cx(N+M)
weight matrix. The result is still a Cx(N+M) matrix, so using the
resulting matrix as weights can still do everything without the need for the channel mapping to do the permutations.

Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc

> On Mon, Mar 13, 2017 at 2:41 PM Mark Harris <mark.hsj@gmail.com
> <mailto:mark.hsj@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund <= jks= @google.com
>=C2=A0 =C2=A0 =C2=A0<mailto:jks@google.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0> Hey,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks for your comments
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Mon, Mar 13, 2017 at 10:08 AM Mark Harris &= lt;mark.hsj@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:mark.hsj@gmail.com>> wrote: >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc= Valin
>=C2=A0 =C2=A0 =C2=A0<jmvalin@jmvalin.ca <mailto:jmvalin@jmv= alin.ca>>
>=C2=A0 =C2=A0 =C2=A0>> wrote:
>=C2=A0 =C2=A0 =C2=A0>> > 3.2.=C2=A0 Channel Mapping Family 3 >=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > I would suggest removing the "Ou= tput Channel Numbering" field
>=C2=A0 =C2=A0 =C2=A0because it
>=C2=A0 =C2=A0 =C2=A0>> > is fully equivalent to simply permuti= ng lines of the matrix.
>=C2=A0 =C2=A0 =C2=A0Also, I
>=C2=A0 =C2=A0 =C2=A0>> > believe that the size of the matrix w= as meant to be "32*(N+M)*C
>=C2=A0 =C2=A0 =C2=A0bits"
>=C2=A0 =C2=A0 =C2=A0>> > rather than "32*N*C bits".<= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> To expand on this a bit, a mapping family = maps M+N decoded channels
>=C2=A0 =C2=A0 =C2=A0>> (corresponding to the actual order of the = coupled and uncoupled
>=C2=A0 =C2=A0 =C2=A0>> channels in the bitstream) to C output cha= nnels (channels with a
>=C2=A0 =C2=A0 =C2=A0>> specific semantic meaning).=C2=A0 The addi= tional "Output Channel
>=C2=A0 =C2=A0 =C2=A0Numbering"
>=C2=A0 =C2=A0 =C2=A0>> table confuses things by adding an additio= nal mapping from the output
>=C2=A0 =C2=A0 =C2=A0>> channel numbers to a different set of numb= ers with actual semantic
>=C2=A0 =C2=A0 =C2=A0>> meaning, leaving the output channel number= s with no apparent meaning.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> This does have a potential benefit as a ma= trix compression technique,
>=C2=A0 =C2=A0 =C2=A0>> to reduce the size of the matrix when it w= ould contain rows that are
>=C2=A0 =C2=A0 =C2=A0>> all zero.=C2=A0 However considering that t= he matrix occurs only once, and
>=C2=A0 =C2=A0 =C2=A0>> mapping family 2 already offers a way to c= ompress the matrix, this
>=C2=A0 =C2=A0 =C2=A0>> alone does not seem worth the complexity o= f another level of
>=C2=A0 =C2=A0 =C2=A0>> indirection.=C2=A0 If matrix compression i= s desired it would probably be
>=C2=A0 =C2=A0 =C2=A0>> less confusing to describe it in those ter= ms and keep the semantic
>=C2=A0 =C2=A0 =C2=A0>> meaning tied to the output channels.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> The description of the Output Channel Numb= ering also does not specify
>=C2=A0 =C2=A0 =C2=A0>> the intended behavior if the same value ap= pears in the table multiple
>=C2=A0 =C2=A0 =C2=A0>> times.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Additionally, section 4.2 describes how to= perform a stereo
>=C2=A0 =C2=A0 =C2=A0downmix of
>=C2=A0 =C2=A0 =C2=A0>> mapping family 3, but makes assumptions ab= out the output channel
>=C2=A0 =C2=A0 =C2=A0>> numbering.=C2=A0 This seems harmful and li= kely to promote implementations
>=C2=A0 =C2=A0 =C2=A0>> that make similar assumptions.=C2=A0 If it= is necessary to apply the
>=C2=A0 =C2=A0 =C2=A0output
>=C2=A0 =C2=A0 =C2=A0>> channel numbering described in section 3.2= in order to implement a
>=C2=A0 =C2=A0 =C2=A0>> correct stereo downmix, then it would be b= etter to simply use the
>=C2=A0 =C2=A0 =C2=A0>> output channels from section 3 as input to= the downmix, consolidating
>=C2=A0 =C2=A0 =C2=A0>> sections 4.1 and 4.2, rather than specify = new formulas that make
>=C2=A0 =C2=A0 =C2=A0>> assumptions about the mapping.=C2=A0 That = would also greatly simplify
>=C2=A0 =C2=A0 =C2=A0>> section 4.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Eliminating the Output Channel Numbering t= able as Jean-Marc suggests
>=C2=A0 =C2=A0 =C2=A0>> should resolve these concerns.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The problem is that once we allow mixed orders= there is no unique
>=C2=A0 =C2=A0 =C2=A0way for a
>=C2=A0 =C2=A0 =C2=A0> receiver/decoder
>=C2=A0 =C2=A0 =C2=A0> to resolve the mapping to ACNs from just a num= ber of total output
>=C2=A0 =C2=A0 =C2=A0channels.
>
>
>=C2=A0 =C2=A0 =C2=A0In mapping family 2, the channel count (C) is the n= umber of channels
>=C2=A0 =C2=A0 =C2=A0in the fully periphonic configuration, but it is no= t necessary to
>=C2=A0 =C2=A0 =C2=A0encode them all.=C2=A0 The channel mapping table ca= n map each ACN to a
>=C2=A0 =C2=A0 =C2=A0specific decoded channel or to silence.=C2=A0 For m= ixed order, some of the
>=C2=A0 =C2=A0 =C2=A0ACNs will be mapped to silence and will not be enco= ded.
>
>=C2=A0 =C2=A0 =C2=A0In mapping family 3, the matrix can do everything t= hat the channel
>=C2=A0 =C2=A0 =C2=A0mapping table can do and more.=C2=A0 Why not treat = C in the same manner, as
>=C2=A0 =C2=A0 =C2=A0the number of channels in the fully periphonic conf= iguration, even if
>=C2=A0 =C2=A0 =C2=A0some are silent?
>
>=C2=A0 =C2=A0 =C2=A0 - Mark
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0codec mailing list
>=C2=A0 =C2=A0 =C2=A0codec@ietf.org <mailto:codec@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.i= etf.org/mailman/listinfo/codec
>
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/codec
>

--001a114005aafdfdbb054aa3d827-- From nobody Mon Mar 13 15:04:28 2017 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 15886129BCE for ; Mon, 13 Mar 2017 15:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 zLmdeoXFGWCw for ; Mon, 13 Mar 2017 15:04:25 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 BBEC6129B80 for ; Mon, 13 Mar 2017 15:04:24 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id j90so69455257lfk.2 for ; Mon, 13 Mar 2017 15:04:24 -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; bh=gO4Q+OOtYFePx2gVPzH2gIvRvr+lWo+aZqgZKEH5LYQ=; b=UH6LUn578dIG1V9QmXDQOMeEbJ/PK9fYKxD0V6KHvDVL0zg8tsaB69PGh/XeDwjQYY G8wgShRVO52Lq+id4tbN2mV+n3r7MPLfiu9bXxnJHaHYMcTns+zXS/OHiurUApDhYLVP VkhT+4qASgOtQTOBK4h/Y1P4zpeACPkMVg9H5q6/Tq3moaK2/aQQXg9qMXK9GGyulTzN ZJL+bCbnAaDF9u4t/iuNJDvsUKA+7gDoPJr5fShk057gELlJ4YNMsU01xfgMZM0djC1l 7ybXxtJieIBTy9ZNwRM3wnzuf4cUnHWDh8IayGJyC6vKehPciyDu3fCT0tt1T43CRCvM nTvA== 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; bh=gO4Q+OOtYFePx2gVPzH2gIvRvr+lWo+aZqgZKEH5LYQ=; b=cMtJkPw3xLBIvDTH/hK0+wIgVZsFlyYt7V1PZnJSvsRKBfqsARvsRXptI41pF7/9nh kfN4pmwrhw7uJrEfu7iiQo9WXtJ5ySQ7EK+U9OSpBTF+6hZGLOrkM76oNbcqqhp7tFPN h7eq62YqQ9KrjyWItcZtIEThIPYBcXFu03mNOB68DtKaO7+PpBJ/eMu2xS/iUfR6wE1R nFK7LKR5zvX68d7OEEQHnQZvAXl94HLaPoiHjb8ZTzl+0mVvFvi0jDV6Lz4Giw0ESy7V aJcQlplySZiiG3/EagHsyByh03q/8MrkCjCiqle1W53/5In+oOVQSVQwAIddneKy71s1 LHwg== X-Gm-Message-State: AMke39nmDfJCQXsS73Vu1ZtyGykc9/ixF2TT6mAttHOIFVy/rSehuBHbjFETYq/7BlEoSUHxvcmmUhnQ4++khVe5 X-Received: by 10.46.20.80 with SMTP id 16mr8846024lju.81.1489442662841; Mon, 13 Mar 2017 15:04:22 -0700 (PDT) MIME-Version: 1.0 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> In-Reply-To: From: Drew Allen Date: Mon, 13 Mar 2017 22:04:12 +0000 Message-ID: To: Jean-Marc Valin , Mark Harris , Jan Skoglund , "codec@ietf.org" Content-Type: multipart/alternative; boundary=f403045fc076d5b481054aa3e4a7 Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:04:27 -0000 --f403045fc076d5b481054aa3e4a7 Content-Type: text/plain; charset=UTF-8 so just to be clear, if a user, say, wants to encode some mixed order ambisonics using ch253, how does the decoder know what ambisonic channels it has received and know how to render them correctly? On Mon, Mar 13, 2017 at 3:00 PM Drew Allen wrote: > Got it. In that case, it certainly seems reasonable if I understand > correctly. Thanks for clearing that up! > > On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin > wrote: > > On 13/03/17 05:44 PM, Drew Allen wrote: > > I think the issue is that the number of total channels rises > > quadratically in respect to the ambisonic order (N + 1)^2. If a user > > wants to use just the horizontal channels, it is only 2 * N + 1. If they > > wish to code very high-order (>10th order) horizontal channels, they > > would be artifically limited by all the zero channels being produced, > > no? Or can this handled without actually creating all those empty > channels? > > As far as I understand, the current draft already has all the > limitations you're describing. The channel mapping array is basically > equivalent to a CxC permutation matrix that multiplies the Cx(N+M) > weight matrix. The result is still a Cx(N+M) matrix, so using the > resulting matrix as weights can still do everything without the need for > the channel mapping to do the permutations. > > Cheers, > > Jean-Marc > > > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris > > wrote: > > > > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund > > wrote: > > > Hey, > > > > > > Thanks for your comments > > > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris > > wrote: > > >> > > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin > > > > > >> wrote: > > >> > 3.2. Channel Mapping Family 3 > > >> > > > >> > I would suggest removing the "Output Channel Numbering" field > > because it > > >> > is fully equivalent to simply permuting lines of the matrix. > > Also, I > > >> > believe that the size of the matrix was meant to be "32*(N+M)*C > > bits" > > >> > rather than "32*N*C bits". > > >> > > >> To expand on this a bit, a mapping family maps M+N decoded > channels > > >> (corresponding to the actual order of the coupled and uncoupled > > >> channels in the bitstream) to C output channels (channels with a > > >> specific semantic meaning). The additional "Output Channel > > Numbering" > > >> table confuses things by adding an additional mapping from the > output > > >> channel numbers to a different set of numbers with actual semantic > > >> meaning, leaving the output channel numbers with no apparent > meaning. > > >> > > >> This does have a potential benefit as a matrix compression > technique, > > >> to reduce the size of the matrix when it would contain rows that > are > > >> all zero. However considering that the matrix occurs only once, > and > > >> mapping family 2 already offers a way to compress the matrix, this > > >> alone does not seem worth the complexity of another level of > > >> indirection. If matrix compression is desired it would probably > be > > >> less confusing to describe it in those terms and keep the semantic > > >> meaning tied to the output channels. > > >> > > >> > > >> The description of the Output Channel Numbering also does not > specify > > >> the intended behavior if the same value appears in the table > multiple > > >> times. > > >> > > >> Additionally, section 4.2 describes how to perform a stereo > > downmix of > > >> mapping family 3, but makes assumptions about the output channel > > >> numbering. This seems harmful and likely to promote > implementations > > >> that make similar assumptions. If it is necessary to apply the > > output > > >> channel numbering described in section 3.2 in order to implement a > > >> correct stereo downmix, then it would be better to simply use the > > >> output channels from section 3 as input to the downmix, > consolidating > > >> sections 4.1 and 4.2, rather than specify new formulas that make > > >> assumptions about the mapping. That would also greatly simplify > > >> section 4. > > >> > > >> Eliminating the Output Channel Numbering table as Jean-Marc > suggests > > >> should resolve these concerns. > > > > > > > > > The problem is that once we allow mixed orders there is no unique > > way for a > > > receiver/decoder > > > to resolve the mapping to ACNs from just a number of total output > > channels. > > > > > > In mapping family 2, the channel count (C) is the number of channels > > in the fully periphonic configuration, but it is not necessary to > > encode them all. The channel mapping table can map each ACN to a > > specific decoded channel or to silence. For mixed order, some of the > > ACNs will be mapped to silence and will not be encoded. > > > > In mapping family 3, the matrix can do everything that the channel > > mapping table can do and more. Why not treat C in the same manner, > as > > the number of channels in the fully periphonic configuration, even if > > some are silent? > > > > - Mark > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > > --f403045fc076d5b481054aa3e4a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
so just to be clear, if a user, say, wants to encode some = mixed order ambisonics using ch253, how does the decoder know what ambisoni= c channels it has received and know how to render them correctly?

=
On Mon, Mar 13, 2017 at 3:00 PM= Drew Allen <bitllama@google.com<= /a>> wrote:

On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin <jmvalin@mozilla.co= m> wrote:
On 13/03/17 05:44 PM, Drew Allen wrote:
> I think the issue is that the number of total channels rises
> quadratically in respect to the ambisonic order (N + 1)^2. If a user > wants to use just the horizontal channels, it is only 2 * N + 1. If th= ey
> wish to code very high-order (>10th order) horizontal channels, the= y
> would be artifically limited by all the zero channels being produced,<= br class=3D"gmail_msg"> > no? Or can this handled without actually creating all those empty chan= nels?

As far as I understand, the current draft already has all the
limitations you're describing. The channel mapping array is basically equivalent to a CxC permutation matrix that multiplies the Cx(N+M)
weight matrix. The result is still a Cx(N+M) matrix, so using the
resulting matrix as weights can still do everything without the need for the channel mapping to do the permutations.

Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc

> On Mon, Mar 13, 2017 at 2:41 PM Mark Harris <mark.hsj@gmail.com
> <mailto:mark.hsj@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund <= jks= @google.com
>=C2=A0 =C2=A0 =C2=A0<mailto:jks@google.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0> Hey,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks for your comments
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Mon, Mar 13, 2017 at 10:08 AM Mark Harris &= lt;mark.hsj@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:mark.hsj@gmail.com>> wrote: >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc= Valin
>=C2=A0 =C2=A0 =C2=A0<jmvalin@jmvalin.ca <mailto:jmvalin@jmv= alin.ca>>
>=C2=A0 =C2=A0 =C2=A0>> wrote:
>=C2=A0 =C2=A0 =C2=A0>> > 3.2.=C2=A0 Channel Mapping Family 3 >=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > I would suggest removing the "Ou= tput Channel Numbering" field
>=C2=A0 =C2=A0 =C2=A0because it
>=C2=A0 =C2=A0 =C2=A0>> > is fully equivalent to simply permuti= ng lines of the matrix.
>=C2=A0 =C2=A0 =C2=A0Also, I
>=C2=A0 =C2=A0 =C2=A0>> > believe that the size of the matrix w= as meant to be "32*(N+M)*C
>=C2=A0 =C2=A0 =C2=A0bits"
>=C2=A0 =C2=A0 =C2=A0>> > rather than "32*N*C bits".<= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> To expand on this a bit, a mapping family = maps M+N decoded channels
>=C2=A0 =C2=A0 =C2=A0>> (corresponding to the actual order of the = coupled and uncoupled
>=C2=A0 =C2=A0 =C2=A0>> channels in the bitstream) to C output cha= nnels (channels with a
>=C2=A0 =C2=A0 =C2=A0>> specific semantic meaning).=C2=A0 The addi= tional "Output Channel
>=C2=A0 =C2=A0 =C2=A0Numbering"
>=C2=A0 =C2=A0 =C2=A0>> table confuses things by adding an additio= nal mapping from the output
>=C2=A0 =C2=A0 =C2=A0>> channel numbers to a different set of numb= ers with actual semantic
>=C2=A0 =C2=A0 =C2=A0>> meaning, leaving the output channel number= s with no apparent meaning.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> This does have a potential benefit as a ma= trix compression technique,
>=C2=A0 =C2=A0 =C2=A0>> to reduce the size of the matrix when it w= ould contain rows that are
>=C2=A0 =C2=A0 =C2=A0>> all zero.=C2=A0 However considering that t= he matrix occurs only once, and
>=C2=A0 =C2=A0 =C2=A0>> mapping family 2 already offers a way to c= ompress the matrix, this
>=C2=A0 =C2=A0 =C2=A0>> alone does not seem worth the complexity o= f another level of
>=C2=A0 =C2=A0 =C2=A0>> indirection.=C2=A0 If matrix compression i= s desired it would probably be
>=C2=A0 =C2=A0 =C2=A0>> less confusing to describe it in those ter= ms and keep the semantic
>=C2=A0 =C2=A0 =C2=A0>> meaning tied to the output channels.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> The description of the Output Channel Numb= ering also does not specify
>=C2=A0 =C2=A0 =C2=A0>> the intended behavior if the same value ap= pears in the table multiple
>=C2=A0 =C2=A0 =C2=A0>> times.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Additionally, section 4.2 describes how to= perform a stereo
>=C2=A0 =C2=A0 =C2=A0downmix of
>=C2=A0 =C2=A0 =C2=A0>> mapping family 3, but makes assumptions ab= out the output channel
>=C2=A0 =C2=A0 =C2=A0>> numbering.=C2=A0 This seems harmful and li= kely to promote implementations
>=C2=A0 =C2=A0 =C2=A0>> that make similar assumptions.=C2=A0 If it= is necessary to apply the
>=C2=A0 =C2=A0 =C2=A0output
>=C2=A0 =C2=A0 =C2=A0>> channel numbering described in section 3.2= in order to implement a
>=C2=A0 =C2=A0 =C2=A0>> correct stereo downmix, then it would be b= etter to simply use the
>=C2=A0 =C2=A0 =C2=A0>> output channels from section 3 as input to= the downmix, consolidating
>=C2=A0 =C2=A0 =C2=A0>> sections 4.1 and 4.2, rather than specify = new formulas that make
>=C2=A0 =C2=A0 =C2=A0>> assumptions about the mapping.=C2=A0 That = would also greatly simplify
>=C2=A0 =C2=A0 =C2=A0>> section 4.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Eliminating the Output Channel Numbering t= able as Jean-Marc suggests
>=C2=A0 =C2=A0 =C2=A0>> should resolve these concerns.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The problem is that once we allow mixed orders= there is no unique
>=C2=A0 =C2=A0 =C2=A0way for a
>=C2=A0 =C2=A0 =C2=A0> receiver/decoder
>=C2=A0 =C2=A0 =C2=A0> to resolve the mapping to ACNs from just a num= ber of total output
>=C2=A0 =C2=A0 =C2=A0channels.
>
>
>=C2=A0 =C2=A0 =C2=A0In mapping family 2, the channel count (C) is the n= umber of channels
>=C2=A0 =C2=A0 =C2=A0in the fully periphonic configuration, but it is no= t necessary to
>=C2=A0 =C2=A0 =C2=A0encode them all.=C2=A0 The channel mapping table ca= n map each ACN to a
>=C2=A0 =C2=A0 =C2=A0specific decoded channel or to silence.=C2=A0 For m= ixed order, some of the
>=C2=A0 =C2=A0 =C2=A0ACNs will be mapped to silence and will not be enco= ded.
>
>=C2=A0 =C2=A0 =C2=A0In mapping family 3, the matrix can do everything t= hat the channel
>=C2=A0 =C2=A0 =C2=A0mapping table can do and more.=C2=A0 Why not treat = C in the same manner, as
>=C2=A0 =C2=A0 =C2=A0the number of channels in the fully periphonic conf= iguration, even if
>=C2=A0 =C2=A0 =C2=A0some are silent?
>
>=C2=A0 =C2=A0 =C2=A0 - Mark
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0codec mailing list
>=C2=A0 =C2=A0 =C2=A0codec@ietf.org <mailto:codec@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.i= etf.org/mailman/listinfo/codec
>
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/codec
>

--f403045fc076d5b481054aa3e4a7-- From nobody Mon Mar 13 15:12:56 2017 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 28611129B83 for ; Mon, 13 Mar 2017 15:12:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 SP-KEywxMHox for ; Mon, 13 Mar 2017 15:12:52 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 8E486129B88 for ; Mon, 13 Mar 2017 15:12:49 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id w124so20942680itb.1 for ; Mon, 13 Mar 2017 15:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=FphrnN4SvsqVAa7kvjAYLf7BxCH8stJt89K4V3nhaSI=; b=S8YQVqQcXny5vrC0C8IxWw/enZLUed9CrvqIy4MmOxM/Kb0lXBjayB3/G5tMVs8hRW ATJtlqsTJlS8JIMjLMSjd/oEaAG6bdyjA1muWnOB7UAKgHc9F0/MiaFwoZsLJB6+lWa4 rOkf14V4x8X4ACgQ6wLkh7kXkECBs6xJ1Mx+Q= 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:from:message-id:date :user-agent:mime-version:in-reply-to; bh=FphrnN4SvsqVAa7kvjAYLf7BxCH8stJt89K4V3nhaSI=; b=f+mTNwQ07pBT4VNDC3+pukmLwm+SeCrc4MAt+WfQQ9bgqx8nDOST+PGeMn6GtUkaNs TIpRfZBd0xx5VbD3YuhbaL0U2mM3D6fn9FDZemcFTLwiejw60tFpO1ZRXtd8VguQl3DD jfgsYkNPWxhEWue7GAHcpblgvm/WMt5w4VPkW2bGfFu6AbPuVXcKkav4vbtsojWd9Nm5 QffTA+sN1X5W7khGocn6ZqJ7bahnXSDzvtIqi2UHkg/CR0vjmxtj5kaEsMmFTCXA83b2 bU3taGqYzuoPAc5tmMtpXAAyJxBlrfiEfw+zRJAaH3a9nCQ/ibkD7e3LU2Q/UFCZzJMN ObDA== X-Gm-Message-State: AFeK/H0GHLXf4szXUDpUjYStXCpS7ilfr8Pfjd4fpG53H9Zeb8YOGg2c7mfq94/LMCmNOWLY X-Received: by 10.36.22.209 with SMTP id a200mr12278467ita.117.1489443168794; Mon, 13 Mar 2017 15:12:48 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable067.31-56-74.mc.videotron.ca. [74.56.31.67]) by smtp.gmail.com with ESMTPSA id j2sm4228600itj.30.2017.03.13.15.12.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 15:12:48 -0700 (PDT) To: Drew Allen , Mark Harris , Jan Skoglund , "codec@ietf.org" References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> From: Jean-Marc Valin Message-ID: <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> Date: Mon, 13 Mar 2017 18:12:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jTres7V6Gb6mrmnJ1cnQnq6cKEUC2D53F" Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:12:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jTres7V6Gb6mrmnJ1cnQnq6cKEUC2D53F Content-Type: multipart/mixed; boundary="x4vwb73fxQX0qrBMQxOtNxOm8rVXbtgKH"; protected-headers="v1" From: Jean-Marc Valin To: Drew Allen , Mark Harris , Jan Skoglund , "codec@ietf.org" Message-ID: <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> In-Reply-To: --x4vwb73fxQX0qrBMQxOtNxOm8rVXbtgKH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/03/17 06:04 PM, Drew Allen wrote: > so just to be clear, if a user, say, wants to encode some mixed order > ambisonics using ch253, how does the decoder know what ambisonic > channels it has received and know how to render them correctly? Well, each line of the matrix would correspond to a channel in the ambisonics channel order. If that channel isn't encoded, then the line would have only zeros. The only way to avoid that situations would be to encode a separate D value (D <=3D C) for the number of non-zero channels among the C ambisonics channels possible. Then you'd store C values in the channel mapping array (equivalent to a CxD permutation matrix), followed by a Dx(M+N) weight matrix that would no longer have entire lines of zeros. The result would be more compact in the case of sparse representation, but IMO it'd be pretty ugly and prone to implementation errors. And if you force D=3D=3DC and don't code the D (which is what I'm proposing), th= en the channel mapping permutation automatically becomes redundant. Cheers, Jean-Marc > On Mon, Mar 13, 2017 at 3:00 PM Drew Allen > wrote: >=20 > Got it. In that case, it certainly seems reasonable if I understand= > correctly. Thanks for clearing that up! >=20 > On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin > wrote: >=20 > On 13/03/17 05:44 PM, Drew Allen wrote: > > I think the issue is that the number of total channels rises > > quadratically in respect to the ambisonic order (N + 1)^2. If= > a user > > wants to use just the horizontal channels, it is only 2 * N += > 1. If they > > wish to code very high-order (>10th order) horizontal > channels, they > > would be artifically limited by all the zero channels being > produced, > > no? Or can this handled without actually creating all those > empty channels? >=20 > As far as I understand, the current draft already has all the > limitations you're describing. The channel mapping array is > basically > equivalent to a CxC permutation matrix that multiplies the Cx(N= +M) > weight matrix. The result is still a Cx(N+M) matrix, so using t= he > resulting matrix as weights can still do everything without the= > need for > the channel mapping to do the permutations. >=20 > Cheers, >=20 > Jean-Marc >=20 > > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris > > > >> wrot= e: > > > > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund > > > >> wrote: > > > Hey, > > > > > > Thanks for your comments > > > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris > > > >> > wrote: > > >> > > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin > > > >> > > >> wrote: > > >> > 3.2. Channel Mapping Family 3 > > >> > > > >> > I would suggest removing the "Output Channel > Numbering" field > > because it > > >> > is fully equivalent to simply permuting lines of the= > matrix. > > Also, I > > >> > believe that the size of the matrix was meant to be > "32*(N+M)*C > > bits" > > >> > rather than "32*N*C bits". > > >> > > >> To expand on this a bit, a mapping family maps M+N > decoded channels > > >> (corresponding to the actual order of the coupled and > uncoupled > > >> channels in the bitstream) to C output channels > (channels with a > > >> specific semantic meaning). The additional "Output Ch= annel > > Numbering" > > >> table confuses things by adding an additional mapping > from the output > > >> channel numbers to a different set of numbers with > actual semantic > > >> meaning, leaving the output channel numbers with no > apparent meaning. > > >> > > >> This does have a potential benefit as a matrix > compression technique, > > >> to reduce the size of the matrix when it would contain= > rows that are > > >> all zero. However considering that the matrix occurs > only once, and > > >> mapping family 2 already offers a way to compress the > matrix, this > > >> alone does not seem worth the complexity of another > level of > > >> indirection. If matrix compression is desired it woul= d > probably be > > >> less confusing to describe it in those terms and keep > the semantic > > >> meaning tied to the output channels. > > >> > > >> > > >> The description of the Output Channel Numbering also > does not specify > > >> the intended behavior if the same value appears in the= > table multiple > > >> times. > > >> > > >> Additionally, section 4.2 describes how to perform a s= tereo > > downmix of > > >> mapping family 3, but makes assumptions about the > output channel > > >> numbering. This seems harmful and likely to promote > implementations > > >> that make similar assumptions. If it is necessary to > apply the > > output > > >> channel numbering described in section 3.2 in order to= > implement a > > >> correct stereo downmix, then it would be better to > simply use the > > >> output channels from section 3 as input to the downmix= , > consolidating > > >> sections 4.1 and 4.2, rather than specify new formulas= > that make > > >> assumptions about the mapping. That would also greatl= y > simplify > > >> section 4. > > >> > > >> Eliminating the Output Channel Numbering table as > Jean-Marc suggests > > >> should resolve these concerns. > > > > > > > > > The problem is that once we allow mixed orders there is= > no unique > > way for a > > > receiver/decoder > > > to resolve the mapping to ACNs from just a number of > total output > > channels. > > > > > > In mapping family 2, the channel count (C) is the number > of channels > > in the fully periphonic configuration, but it is not > necessary to > > encode them all. The channel mapping table can map each > ACN to a > > specific decoded channel or to silence. For mixed order,= > some of the > > ACNs will be mapped to silence and will not be encoded. > > > > In mapping family 3, the matrix can do everything that th= e > channel > > mapping table can do and more. Why not treat C in the > same manner, as > > the number of channels in the fully periphonic > configuration, even if > > some are silent? > > > > - Mark > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > >=20 --x4vwb73fxQX0qrBMQxOtNxOm8rVXbtgKH-- --jTres7V6Gb6mrmnJ1cnQnq6cKEUC2D53F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYxxlfAAoJEF5d2aNvkYnIsfwP/3Mk0e3DYMmf6telS9gdN1f8 MEkXudmmIDASlku3xnlyXhCCrUO8CTrvHMS/dWKiGvgRu9SV/AGRgmqmexp42zFA LpdgsGJY3L2SJwvJdpOXB5PBN4xBShdCcI70tJFqAc0HTMGI+FLfeEiW/4B/yOzS 7vKj91JjawBlj9VgE/3f1HmqGU83ivkDQmtgoeO9qm7mjJO1vQYGQrWto05Tezr3 vNMT8XkT9jpB4gfaLaRk4SvVpO6QX3kPrt/3QDlIihW5GoDCSYQxXYpsx0VYJ5pb qcf1YbZuRrOwIKSM+lFxtcyyaTIImAr9Dg4++j/fjY//h6B4CZo1OI9runrEVA4i vN7uMbhwqswvIn6T3GooH7n9jnbadG0Y7uVMmpxL4XOOP4PSXYlYbCMProUOIESn b3HE+xbWfTMx6lOGAbjntGP9jSbAjHtZognkOCR8OqqhpdzyNVbtMWl2VvNJGWVl oadACuaGkgXkD0qmWwif3WF/7p4wSwyzc4BfXDhsLY3gGz/lqtY7SJs0YfhGuyYe i4322apJXWR/rzUeSu+ukkTLDG3SzPWFQICpY2oadR4VtQtWovQ5LGxXg/sO+ywa 32ww7Dq+sd8Sg1B4k52HQhhVHDZPl62uRikE9ylHjh7y3A843Cm3MDgN65ksa1lc XHqwP5qUpEMLqff7KFGW =Wiak -----END PGP SIGNATURE----- --jTres7V6Gb6mrmnJ1cnQnq6cKEUC2D53F-- From nobody Mon Mar 13 15:17:50 2017 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 A6A80129415 for ; Mon, 13 Mar 2017 15:17:47 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 GtoexPt64cMq for ; Mon, 13 Mar 2017 15:17:45 -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 8194B129BBF for ; Mon, 13 Mar 2017 15:17:30 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p64so234842953qke.1 for ; Mon, 13 Mar 2017 15:17:30 -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; bh=ETxtTz9xGxd+albsOg25/xbZ9sjq8jspy2MnSxLt3Cw=; b=H7AMQ1hYJolacgTeswL2scgi5jnIpF2MdjVSpYsSLxLZ3LP+VlOHQkA2cI2Z9WGilQ y3iTy0vU5L5LUm0bs6oGv51UVQa5BiNZHq07ehJhQkLSC2ihGflmWioQvDIX1wXDoFlF ldw4Bbg8z6oU2cNi89PxL4yc3zVaf3wkotLfeytstAOkOvSN9eLsVkjTyNLruldqWe8d S81mo+pt9SD77kGIm0yjUSukmyLHHSNqg7k/q9oZpc2QKt29GRYwEJ5byYm2A1o8mTEU cYsVzyQ6lF0KWnlJIYdOMjy6k89B6nKXEepEXH3b4cDy8ekH3aCOtH5sSRfvlyKFzvXA kdyQ== 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; bh=ETxtTz9xGxd+albsOg25/xbZ9sjq8jspy2MnSxLt3Cw=; b=s4e14u+8n9aepnvzDXy2OcRFy5IQ+MbbEy1ktQkkfYPm9XrskXt/V24Qy1rILJqA/C JSoVQE1g88pLer5rmJLr9+Qt/HUTHRpe75ziwjIf0q0OVRECG8lfICRfrBOIor9kNC4r OA8SNkSRzLc9OIFY/VJgI42UwK8jouCk+VppjZTpqqV3yUUBiIQEOuRKqohQKTEPcGPg HCi1SbpDpcA660829JQuTQMFe+qqnJpWnf1xegsBICO9G6CuFS0FT3bkiC4PUY6iJXO/ WhGMifjFMsZk2sLaYDAi7TyuiXw+mf3QanUgF4fzYiHJozuiB6PV+I4hPFHqEqSGxmi6 w1hA== X-Gm-Message-State: AMke39n18wpBlJv1vBRMjaPKTqprtAtf+jVqJcBIhqmm3K+8yT4qSIUpX9H/THW3VvZD/XMfEQ0RT3l61E11r0Vl X-Received: by 10.55.80.135 with SMTP id e129mr32210849qkb.192.1489443449424; Mon, 13 Mar 2017 15:17:29 -0700 (PDT) MIME-Version: 1.0 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> In-Reply-To: <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> From: Jan Skoglund Date: Mon, 13 Mar 2017 22:17:18 +0000 Message-ID: To: Jean-Marc Valin , Drew Allen , Mark Harris , "codec@ietf.org" Content-Type: multipart/alternative; boundary=001a114a6b4eb7b9b2054aa4135b Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:17:47 -0000 --001a114a6b4eb7b9b2054aa4135b Content-Type: text/plain; charset=UTF-8 Hey, Our idea was to avoid a mapping table, potentially sparse, completely for family 2, and replacing it with a channel numbering list for family 3. Cheers, Jan On Mon, Mar 13, 2017 at 3:12 PM Jean-Marc Valin wrote: > On 13/03/17 06:04 PM, Drew Allen wrote: > > so just to be clear, if a user, say, wants to encode some mixed order > > ambisonics using ch253, how does the decoder know what ambisonic > > channels it has received and know how to render them correctly? > > Well, each line of the matrix would correspond to a channel in the > ambisonics channel order. If that channel isn't encoded, then the line > would have only zeros. > > The only way to avoid that situations would be to encode a separate D > value (D <= C) for the number of non-zero channels among the C > ambisonics channels possible. Then you'd store C values in the channel > mapping array (equivalent to a CxD permutation matrix), followed by a > Dx(M+N) weight matrix that would no longer have entire lines of zeros. > The result would be more compact in the case of sparse representation, > but IMO it'd be pretty ugly and prone to implementation errors. And if > you force D==C and don't code the D (which is what I'm proposing), then > the channel mapping permutation automatically becomes redundant. > > Cheers, > > Jean-Marc > > > On Mon, Mar 13, 2017 at 3:00 PM Drew Allen > > wrote: > > > > Got it. In that case, it certainly seems reasonable if I understand > > correctly. Thanks for clearing that up! > > > > On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin > > wrote: > > > > On 13/03/17 05:44 PM, Drew Allen wrote: > > > I think the issue is that the number of total channels rises > > > quadratically in respect to the ambisonic order (N + 1)^2. If > > a user > > > wants to use just the horizontal channels, it is only 2 * N + > > 1. If they > > > wish to code very high-order (>10th order) horizontal > > channels, they > > > would be artifically limited by all the zero channels being > > produced, > > > no? Or can this handled without actually creating all those > > empty channels? > > > > As far as I understand, the current draft already has all the > > limitations you're describing. The channel mapping array is > > basically > > equivalent to a CxC permutation matrix that multiplies the > Cx(N+M) > > weight matrix. The result is still a Cx(N+M) matrix, so using the > > resulting matrix as weights can still do everything without the > > need for > > the channel mapping to do the permutations. > > > > Cheers, > > > > Jean-Marc > > > > > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris > > > > > >> > wrote: > > > > > > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund > > > > > >> wrote: > > > > Hey, > > > > > > > > Thanks for your comments > > > > > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris > > > > > >> > > wrote: > > > >> > > > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin > > > > > >> > > > >> wrote: > > > >> > 3.2. Channel Mapping Family 3 > > > >> > > > > >> > I would suggest removing the "Output Channel > > Numbering" field > > > because it > > > >> > is fully equivalent to simply permuting lines of the > > matrix. > > > Also, I > > > >> > believe that the size of the matrix was meant to be > > "32*(N+M)*C > > > bits" > > > >> > rather than "32*N*C bits". > > > >> > > > >> To expand on this a bit, a mapping family maps M+N > > decoded channels > > > >> (corresponding to the actual order of the coupled and > > uncoupled > > > >> channels in the bitstream) to C output channels > > (channels with a > > > >> specific semantic meaning). The additional "Output > Channel > > > Numbering" > > > >> table confuses things by adding an additional mapping > > from the output > > > >> channel numbers to a different set of numbers with > > actual semantic > > > >> meaning, leaving the output channel numbers with no > > apparent meaning. > > > >> > > > >> This does have a potential benefit as a matrix > > compression technique, > > > >> to reduce the size of the matrix when it would contain > > rows that are > > > >> all zero. However considering that the matrix occurs > > only once, and > > > >> mapping family 2 already offers a way to compress the > > matrix, this > > > >> alone does not seem worth the complexity of another > > level of > > > >> indirection. If matrix compression is desired it would > > probably be > > > >> less confusing to describe it in those terms and keep > > the semantic > > > >> meaning tied to the output channels. > > > >> > > > >> > > > >> The description of the Output Channel Numbering also > > does not specify > > > >> the intended behavior if the same value appears in the > > table multiple > > > >> times. > > > >> > > > >> Additionally, section 4.2 describes how to perform a > stereo > > > downmix of > > > >> mapping family 3, but makes assumptions about the > > output channel > > > >> numbering. This seems harmful and likely to promote > > implementations > > > >> that make similar assumptions. If it is necessary to > > apply the > > > output > > > >> channel numbering described in section 3.2 in order to > > implement a > > > >> correct stereo downmix, then it would be better to > > simply use the > > > >> output channels from section 3 as input to the downmix, > > consolidating > > > >> sections 4.1 and 4.2, rather than specify new formulas > > that make > > > >> assumptions about the mapping. That would also greatly > > simplify > > > >> section 4. > > > >> > > > >> Eliminating the Output Channel Numbering table as > > Jean-Marc suggests > > > >> should resolve these concerns. > > > > > > > > > > > > The problem is that once we allow mixed orders there is > > no unique > > > way for a > > > > receiver/decoder > > > > to resolve the mapping to ACNs from just a number of > > total output > > > channels. > > > > > > > > > In mapping family 2, the channel count (C) is the number > > of channels > > > in the fully periphonic configuration, but it is not > > necessary to > > > encode them all. The channel mapping table can map each > > ACN to a > > > specific decoded channel or to silence. For mixed order, > > some of the > > > ACNs will be mapped to silence and will not be encoded. > > > > > > In mapping family 3, the matrix can do everything that the > > channel > > > mapping table can do and more. Why not treat C in the > > same manner, as > > > the number of channels in the fully periphonic > > configuration, even if > > > some are silent? > > > > > > - Mark > > > > > > _______________________________________________ > > > codec mailing list > > > codec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > > > _______________________________________________ > > > codec mailing list > > > codec@ietf.org > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > --001a114a6b4eb7b9b2054aa4135b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey,

Our idea was to avoid a mapping ta= ble, potentially sparse, completely for family 2, and replacing it with a c= hannel numbering list for family 3.

Cheers,
<= div>Jan

On Mon, = Mar 13, 2017 at 3:12 PM Jean-Marc Valin <jmvalin@mozilla.com> wrote:
On 13/03/17 06:04 PM, Drew Allen wrote:
> so just to be clear, if a user, say, wants to encode some mixed order<= br class=3D"gmail_msg"> > ambisonics using ch253, how does the decoder know what ambisonic
> channels it has received and know how to render them correctly?

Well, each line of the matrix would correspond to a channel in the
ambisonics channel order. If that channel isn't encoded, then the line<= br class=3D"gmail_msg"> would have only zeros.

The only way to avoid that situations would be to encode a separate D
value (D <=3D C) for the number of non-zero channels among the C
ambisonics channels possible. Then you'd store C values in the channel<= br class=3D"gmail_msg"> mapping array (equivalent to a CxD permutation matrix), followed by a
Dx(M+N) weight matrix that would no longer have entire lines of zeros.
The result would be more compact in the case of sparse representation,
but IMO it'd be pretty ugly and prone to implementation errors. And if<= br class=3D"gmail_msg"> you force D=3D=3DC and don't code the D (which is what I'm proposin= g), then
the channel mapping permutation automatically becomes redundant.

Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc

> On Mon, Mar 13, 2017 at 3:00 PM Drew Allen <bitllama@google.com
> <mailto:bitllama@google.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Got it. In that case, it certainly seems reasonable= if I understand
>=C2=A0 =C2=A0 =C2=A0correctly. Thanks for clearing that up!
>
>=C2=A0 =C2=A0 =C2=A0On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin <= ;jmvalin@mozilla.com
>=C2=A0 =C2=A0 =C2=A0<mailto:jmvalin@mozilla.com>> wrote:=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 13/03/17 05:44 PM, Drew Allen wrot= e:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I think the issue is that the nu= mber of total channels rises
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> quadratically in respect to the = ambisonic order (N + 1)^2. If
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a user
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> wants to use just the horizontal= channels, it is only 2 * N +
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. If they
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> wish to code very high-order (&g= t;10th order) horizontal
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0channels, they
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> would be artifically limited by = all the zero channels being
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0produced,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> no? Or can this handled without = actually creating all those
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0empty channels?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As far as I understand, the current d= raft already has all the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limitations you're describing. Th= e channel mapping array is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0basically
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0equivalent to a CxC permutation matri= x that multiplies the Cx(N+M)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0weight matrix. The result is still a = Cx(N+M) matrix, so using the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resulting matrix as weights can still= do everything without the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the channel mapping to do the permuta= tions.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jean-Marc=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On Mon, Mar 13, 2017 at 2:41 PM = Mark Harris
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mark.hsj@gmail.com <mailt= o:mark.hsj@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> <mailto:mark.hsj@gmail.com <mailto:mark.hsj@gmail.com>>> wrote:
>=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=A0On Mon, Mar 1= 3, 2017 at 10:38 AM, Jan Skoglund
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<jks@google.com <mailto:jks@googl= e.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<mailto:jks@g= oogle.com <mailto:jks@google.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Hey,
>=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> Thanks f= or your comments
>=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> On Mon, = Mar 13, 2017 at 10:08 AM Mark Harris
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mark.hsj@gmail.com <mailt= o:mark.hsj@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<mailto:m= ark.hsj@gmail.com <mailto:mark.hsj@gmail.com>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>=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>> On F= ri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<jmvali= n@jmvalin.ca <mailto:jmvalin@jmvalin.ca>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:jmvalin@jmvalin.ca &l= t;mailto:jmvalin@jmvalin.ca>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> wrot= e:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> >= 3.2.=C2=A0 Channel Mapping Family 3
>=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>> >= I would suggest removing the "Output Channel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Numbering" field
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0because it >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> >= is fully equivalent to simply permuting lines of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matrix.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Also, I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> >= believe that the size of the matrix was meant to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"32*(N+M)*C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0bits" >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> >= rather than "32*N*C bits".
>=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>> To e= xpand on this a bit, a mapping family maps M+N
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decoded channels
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> (cor= responding to the actual order of the coupled and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uncoupled
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> chan= nels in the bitstream) to C output channels
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(channels with a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> spec= ific semantic meaning).=C2=A0 The additional "Output Channel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Numbering&quo= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> tabl= e confuses things by adding an additional mapping
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from the output
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> chan= nel numbers to a different set of numbers with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actual semantic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> mean= ing, leaving the output channel numbers with no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apparent meaning.
>=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>> This= does have a potential benefit as a matrix
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compression technique,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> to r= educe the size of the matrix when it would contain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rows that are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> all = zero.=C2=A0 However considering that the matrix occurs
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only once, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> mapp= ing family 2 already offers a way to compress the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matrix, this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> alon= e does not seem worth the complexity of another
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0level of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> indi= rection.=C2=A0 If matrix compression is desired it would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0probably be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> less= confusing to describe it in those terms and keep
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the semantic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> mean= ing tied to the output channels.
>=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>> The = description of the Output Channel Numbering also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0does not specify
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> the = intended behavior if the same value appears in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0table multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> time= s.
>=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>> Addi= tionally, section 4.2 describes how to perform a stereo
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0downmix of >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> mapp= ing family 3, but makes assumptions about the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0output channel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> numb= ering.=C2=A0 This seems harmful and likely to promote
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementations
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> that= make similar assumptions.=C2=A0 If it is necessary to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apply the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0output
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> chan= nel numbering described in section 3.2 in order to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implement a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> corr= ect stereo downmix, then it would be better to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simply use the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> outp= ut channels from section 3 as input to the downmix,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consolidating
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> sect= ions 4.1 and 4.2, rather than specify new formulas
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that make
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> assu= mptions about the mapping.=C2=A0 That would also greatly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simplify
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> sect= ion 4.
>=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>> Elim= inating the Output Channel Numbering table as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jean-Marc suggests
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> shou= ld resolve these concerns.
>=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> The prob= lem is that once we allow mixed orders there is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no unique
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0way for a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> receiver= /decoder
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> to resol= ve the mapping to ACNs from just a number of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0total output
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0channels.
>=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=A0In mapping fa= mily 2, the channel count (C) is the number
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of channels
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0in the fully = periphonic configuration, but it is not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0necessary to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0encode them a= ll.=C2=A0 The channel mapping table can map each
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACN to a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0specific deco= ded channel or to silence.=C2=A0 For mixed order,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0ACNs will be = mapped to silence and will not be encoded.
>=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=A0In mapping fa= mily 3, the matrix can do everything that the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0channel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0mapping table= can do and more.=C2=A0 Why not treat C in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0same manner, as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0the number of= channels in the fully periphonic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration, even if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0some are sile= nt?
>=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 - Mark
>=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=A0codec mailing= list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0codec@ietf.org <mailto:codec@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:codec@ietf.org <mailto= :co= dec@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/codec >=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> codec mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> codec@ietf.org <mailto:codec@ie= tf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/listinfo/codec
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>

--001a114a6b4eb7b9b2054aa4135b-- From nobody Mon Mar 13 15:20:11 2017 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 17E35129BCE for ; Mon, 13 Mar 2017 15:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 6ImBJdOtp9cv for ; Mon, 13 Mar 2017 15:20:08 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 DFF82129BDA for ; Mon, 13 Mar 2017 15:19:50 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id m27so37468227iti.0 for ; Mon, 13 Mar 2017 15:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jmvalin-ca.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=OEzbIx/sT/to5IGx24wiyP8yzeLdRNyfeAlgbOcIDi8=; b=uj1pvuMaCyQlkkcI929X3Ma2qhQ+JUSKdEymYZMC2EI1zMMN2qlI34M/Buj7JRNRV2 5VHw9YX1XpAU5Z0eEA+sRJhNpmAYa4NV+0ykajhAtH/V5RbNn9lRjSb8ZJZf2VjOBYtb OrHZwBmrLdHrpZpqKvHrWmr3tWziitYZ9ihujyfh4KH+ZWLP+nz5k/dKFgKr5d1Upzbm ihtCFyerDuQ8uUhreNJKsAUlP6C6f6KqOwvwvAb5RvGUxHbgjqtiRG5qSQ5nhb7mmYSD SEg4GBD483CF9MlZVthaRsLqxavQ8c1mWBQ9AtLeovPvkjaHozHggDw2O9UQPBTjwdn0 VbDw== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OEzbIx/sT/to5IGx24wiyP8yzeLdRNyfeAlgbOcIDi8=; b=HtCqACK+nupz4fmnHuUf6yLtHMLxVsvdSo+9LQb23bn5WUZ5UWlPRaZXS1a8xWzlhL QCTqayEKn9B/he43iWDqqkH8G9acokDd/ahFbgHEvtp0Yvq2qTi7d5qrX3t39RgYt4V3 VTwjOmz1idWk4jV43jgzNK8s3IYN4w9/Kfht26/4qqp4nWDKwg3AfCk/vZqR7QRgMqsu K1C+QYcURFomWe1IN9gQQNyCfqcAwSrW4PvMgygnEWeiQg+95OA5t4oGUmqoodBmhsIC IgXXehtFFQb9g51KSK+5fTPtExT4IMM2GgeTuzGcRMzMn8jrf+aVtnOnXxlmAb3aM4cf z5jg== X-Gm-Message-State: AFeK/H3rgH/XJV1YuzuERefgk6Joqviarvq096Shai9ggXJ7hcV6kTzqeP82qIZB+V85qw== X-Received: by 10.36.115.145 with SMTP id y139mr12802873itb.123.1489443590114; Mon, 13 Mar 2017 15:19:50 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable067.31-56-74.mc.videotron.ca. [74.56.31.67]) by smtp.gmail.com with ESMTPSA id f187sm4249517ita.28.2017.03.13.15.19.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 15:19:49 -0700 (PDT) To: Jan Skoglund , Jean-Marc Valin , Drew Allen , Mark Harris , "codec@ietf.org" References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> From: Jean-Marc Valin Message-ID: Date: Mon, 13 Mar 2017 18:19:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:20:10 -0000 On 13/03/17 06:17 PM, Jan Skoglund wrote: > Our idea was to avoid a mapping table, potentially sparse, completely > for family 2, and replacing it with a channel numbering list for family 3. Can you explain what you mean here by "avoid a mapping table" for family 2 and "channel numbering list" for family 3? Jean-Marc > Cheers, > Jan > > On Mon, Mar 13, 2017 at 3:12 PM Jean-Marc Valin > wrote: > > On 13/03/17 06:04 PM, Drew Allen wrote: > > so just to be clear, if a user, say, wants to encode some mixed order > > ambisonics using ch253, how does the decoder know what ambisonic > > channels it has received and know how to render them correctly? > > Well, each line of the matrix would correspond to a channel in the > ambisonics channel order. If that channel isn't encoded, then the line > would have only zeros. > > The only way to avoid that situations would be to encode a separate D > value (D <= C) for the number of non-zero channels among the C > ambisonics channels possible. Then you'd store C values in the channel > mapping array (equivalent to a CxD permutation matrix), followed by a > Dx(M+N) weight matrix that would no longer have entire lines of zeros. > The result would be more compact in the case of sparse representation, > but IMO it'd be pretty ugly and prone to implementation errors. And if > you force D==C and don't code the D (which is what I'm proposing), then > the channel mapping permutation automatically becomes redundant. > > Cheers, > > Jean-Marc > > > On Mon, Mar 13, 2017 at 3:00 PM Drew Allen > > >> wrote: > > > > Got it. In that case, it certainly seems reasonable if I > understand > > correctly. Thanks for clearing that up! > > > > On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin > > > >> wrote: > > > > On 13/03/17 05:44 PM, Drew Allen wrote: > > > I think the issue is that the number of total channels rises > > > quadratically in respect to the ambisonic order (N + > 1)^2. If > > a user > > > wants to use just the horizontal channels, it is only 2 > * N + > > 1. If they > > > wish to code very high-order (>10th order) horizontal > > channels, they > > > would be artifically limited by all the zero channels being > > produced, > > > no? Or can this handled without actually creating all those > > empty channels? > > > > As far as I understand, the current draft already has all the > > limitations you're describing. The channel mapping array is > > basically > > equivalent to a CxC permutation matrix that multiplies the > Cx(N+M) > > weight matrix. The result is still a Cx(N+M) matrix, so > using the > > resulting matrix as weights can still do everything > without the > > need for > > the channel mapping to do the permutations. > > > > Cheers, > > > > Jean-Marc > > > > > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris > > > > > > > > >>> wrote: > > > > > > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund > > > > > > > > >>> wrote: > > > > Hey, > > > > > > > > Thanks for your comments > > > > > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris > > > > > > > >>> > > wrote: > > > >> > > > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin > > > > > > > > >>> > > > >> wrote: > > > >> > 3.2. Channel Mapping Family 3 > > > >> > > > > >> > I would suggest removing the "Output Channel > > Numbering" field > > > because it > > > >> > is fully equivalent to simply permuting lines > of the > > matrix. > > > Also, I > > > >> > believe that the size of the matrix was meant to be > > "32*(N+M)*C > > > bits" > > > >> > rather than "32*N*C bits". > > > >> > > > >> To expand on this a bit, a mapping family maps M+N > > decoded channels > > > >> (corresponding to the actual order of the coupled and > > uncoupled > > > >> channels in the bitstream) to C output channels > > (channels with a > > > >> specific semantic meaning). The additional > "Output Channel > > > Numbering" > > > >> table confuses things by adding an additional mapping > > from the output > > > >> channel numbers to a different set of numbers with > > actual semantic > > > >> meaning, leaving the output channel numbers with no > > apparent meaning. > > > >> > > > >> This does have a potential benefit as a matrix > > compression technique, > > > >> to reduce the size of the matrix when it would > contain > > rows that are > > > >> all zero. However considering that the matrix occurs > > only once, and > > > >> mapping family 2 already offers a way to compress the > > matrix, this > > > >> alone does not seem worth the complexity of another > > level of > > > >> indirection. If matrix compression is desired it > would > > probably be > > > >> less confusing to describe it in those terms and keep > > the semantic > > > >> meaning tied to the output channels. > > > >> > > > >> > > > >> The description of the Output Channel Numbering also > > does not specify > > > >> the intended behavior if the same value appears > in the > > table multiple > > > >> times. > > > >> > > > >> Additionally, section 4.2 describes how to > perform a stereo > > > downmix of > > > >> mapping family 3, but makes assumptions about the > > output channel > > > >> numbering. This seems harmful and likely to promote > > implementations > > > >> that make similar assumptions. If it is necessary to > > apply the > > > output > > > >> channel numbering described in section 3.2 in > order to > > implement a > > > >> correct stereo downmix, then it would be better to > > simply use the > > > >> output channels from section 3 as input to the > downmix, > > consolidating > > > >> sections 4.1 and 4.2, rather than specify new > formulas > > that make > > > >> assumptions about the mapping. That would also > greatly > > simplify > > > >> section 4. > > > >> > > > >> Eliminating the Output Channel Numbering table as > > Jean-Marc suggests > > > >> should resolve these concerns. > > > > > > > > > > > > The problem is that once we allow mixed orders > there is > > no unique > > > way for a > > > > receiver/decoder > > > > to resolve the mapping to ACNs from just a number of > > total output > > > channels. > > > > > > > > > In mapping family 2, the channel count (C) is the number > > of channels > > > in the fully periphonic configuration, but it is not > > necessary to > > > encode them all. The channel mapping table can map each > > ACN to a > > > specific decoded channel or to silence. For mixed > order, > > some of the > > > ACNs will be mapped to silence and will not be encoded. > > > > > > In mapping family 3, the matrix can do everything > that the > > channel > > > mapping table can do and more. Why not treat C in the > > same manner, as > > > the number of channels in the fully periphonic > > configuration, even if > > > some are silent? > > > > > > - Mark > > > > > > _______________________________________________ > > > codec mailing list > > > codec@ietf.org > > > > > >> > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > > > _______________________________________________ > > > codec mailing list > > > codec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From nobody Mon Mar 13 15:31:11 2017 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 7E4121296D6 for ; Mon, 13 Mar 2017 15:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ZkbYsfOipr6P for ; Mon, 13 Mar 2017 15:31:02 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 0F4CD1293FB for ; Mon, 13 Mar 2017 15:25:14 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id p64so234961200qke.1 for ; Mon, 13 Mar 2017 15:25:14 -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; bh=OSJtCPeB0Kmz6pQslYk9tHhQXOzk7Rb14uZOkVlBfho=; b=XTZsVoXzK72ilcFjvbY1ZApr7vCKks/o6gooCHCaAVHPHromkWnm31l1jAoUBYt8sH ntvsSn0nxKjTrPUviRtxL99VoCK+PlievXrOAZw7G4/QyoVbi4Ax7E0y8cOMckBjri0z v3HTozjXKUEoWiZl5Ez4jzexama4Wa4TV/rqnh0NhXcaq8M6LVN4R8uRdXHwnkbFllv8 Pe9KlXzwVRxFXr1nxWCQhdmNOHmAQLIIPNmeBHt1yGB6AWqcRzTyu6xdPnyCpzrxJbvK OFow1xrSGwo3Oh7eCTFoQhbVGQaQTB06j5LxSdYkYTG3MWPvPob9hT3XF/WnV5KHxg3L ttDg== 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; bh=OSJtCPeB0Kmz6pQslYk9tHhQXOzk7Rb14uZOkVlBfho=; b=d34uUHxjANK/UPsjRfWB2qKEIa5RqTAXr8N+Qsrxm8zvQy5GcASKDmCr3KiI0hOdV7 qq/SWhDIuzTszYcYz1Tm1LKKjRtROhcem1mc8vs7PEYxvt9a3m0wtG/YAMEJAdilT4cr De48hBkKh1E+3DfP9vrsOxXpUZkSAPc0TKS/WjNGNBDzH+FolN45uXWe8oAdhw89/iKr DDS4OzjzfVFfaEHNO4AQfPeu/646oOaT0AUKBMZUHtpD9EqbqSOqpupC5JjI8BLkEgJ5 lynfi2wcFV8vbuDmYhnOTTwJnYCNwhOQ87bMvFtLGrFUZK6KqPmgRFwTMRq87ZjxNE80 ZPdg== X-Gm-Message-State: AFeK/H3uqh/pTPLJRMjIqDHSHSAwyya7OmplJSV3Qnoo2jWvOMLRIicG78yLm1A0Lil5nhOf8noJwKNpIGpHfp4d X-Received: by 10.55.127.2 with SMTP id a2mr33742552qkd.319.1489443912839; Mon, 13 Mar 2017 15:25:12 -0700 (PDT) MIME-Version: 1.0 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> In-Reply-To: From: Jan Skoglund Date: Mon, 13 Mar 2017 22:25:02 +0000 Message-ID: To: Jean-Marc Valin , Jean-Marc Valin , Drew Allen , Mark Harris , "codec@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c059f0256d910054aa42f10 Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:31:06 -0000 --94eb2c059f0256d910054aa42f10 Content-Type: text/plain; charset=UTF-8 Ha, sorry, wrong name! I meant avoiding permutation matrices. Jan On Mon, Mar 13, 2017 at 3:19 PM Jean-Marc Valin wrote: > On 13/03/17 06:17 PM, Jan Skoglund wrote: > > Our idea was to avoid a mapping table, potentially sparse, completely > > for family 2, and replacing it with a channel numbering list for family > 3. > > Can you explain what you mean here by "avoid a mapping table" for family > 2 and "channel numbering list" for family 3? > > Jean-Marc > > > Cheers, > > Jan > > > > On Mon, Mar 13, 2017 at 3:12 PM Jean-Marc Valin > > wrote: > > > > On 13/03/17 06:04 PM, Drew Allen wrote: > > > so just to be clear, if a user, say, wants to encode some mixed > order > > > ambisonics using ch253, how does the decoder know what ambisonic > > > channels it has received and know how to render them correctly? > > > > Well, each line of the matrix would correspond to a channel in the > > ambisonics channel order. If that channel isn't encoded, then the > line > > would have only zeros. > > > > The only way to avoid that situations would be to encode a separate D > > value (D <= C) for the number of non-zero channels among the C > > ambisonics channels possible. Then you'd store C values in the > channel > > mapping array (equivalent to a CxD permutation matrix), followed by a > > Dx(M+N) weight matrix that would no longer have entire lines of > zeros. > > The result would be more compact in the case of sparse > representation, > > but IMO it'd be pretty ugly and prone to implementation errors. And > if > > you force D==C and don't code the D (which is what I'm proposing), > then > > the channel mapping permutation automatically becomes redundant. > > > > Cheers, > > > > Jean-Marc > > > > > On Mon, Mar 13, 2017 at 3:00 PM Drew Allen > > > > >> wrote: > > > > > > Got it. In that case, it certainly seems reasonable if I > > understand > > > correctly. Thanks for clearing that up! > > > > > > On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin > > > > > >> > wrote: > > > > > > On 13/03/17 05:44 PM, Drew Allen wrote: > > > > I think the issue is that the number of total channels > rises > > > > quadratically in respect to the ambisonic order (N + > > 1)^2. If > > > a user > > > > wants to use just the horizontal channels, it is only 2 > > * N + > > > 1. If they > > > > wish to code very high-order (>10th order) horizontal > > > channels, they > > > > would be artifically limited by all the zero channels > being > > > produced, > > > > no? Or can this handled without actually creating all > those > > > empty channels? > > > > > > As far as I understand, the current draft already has all > the > > > limitations you're describing. The channel mapping array is > > > basically > > > equivalent to a CxC permutation matrix that multiplies the > > Cx(N+M) > > > weight matrix. The result is still a Cx(N+M) matrix, so > > using the > > > resulting matrix as weights can still do everything > > without the > > > need for > > > the channel mapping to do the permutations. > > > > > > Cheers, > > > > > > Jean-Marc > > > > > > > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris > > > > > > > > > > > > >>> wrote: > > > > > > > > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund > > > > > > > > > > > > >>> wrote: > > > > > Hey, > > > > > > > > > > Thanks for your comments > > > > > > > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris > > > > > > > > > > > > >>> > > > wrote: > > > > >> > > > > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin > > > > > > > > > > > > >>> > > > > >> wrote: > > > > >> > 3.2. Channel Mapping Family 3 > > > > >> > > > > > >> > I would suggest removing the "Output Channel > > > Numbering" field > > > > because it > > > > >> > is fully equivalent to simply permuting lines > > of the > > > matrix. > > > > Also, I > > > > >> > believe that the size of the matrix was meant > to be > > > "32*(N+M)*C > > > > bits" > > > > >> > rather than "32*N*C bits". > > > > >> > > > > >> To expand on this a bit, a mapping family maps M+N > > > decoded channels > > > > >> (corresponding to the actual order of the coupled > and > > > uncoupled > > > > >> channels in the bitstream) to C output channels > > > (channels with a > > > > >> specific semantic meaning). The additional > > "Output Channel > > > > Numbering" > > > > >> table confuses things by adding an additional > mapping > > > from the output > > > > >> channel numbers to a different set of numbers with > > > actual semantic > > > > >> meaning, leaving the output channel numbers with > no > > > apparent meaning. > > > > >> > > > > >> This does have a potential benefit as a matrix > > > compression technique, > > > > >> to reduce the size of the matrix when it would > > contain > > > rows that are > > > > >> all zero. However considering that the matrix > occurs > > > only once, and > > > > >> mapping family 2 already offers a way to compress > the > > > matrix, this > > > > >> alone does not seem worth the complexity of > another > > > level of > > > > >> indirection. If matrix compression is desired it > > would > > > probably be > > > > >> less confusing to describe it in those terms and > keep > > > the semantic > > > > >> meaning tied to the output channels. > > > > >> > > > > >> > > > > >> The description of the Output Channel Numbering > also > > > does not specify > > > > >> the intended behavior if the same value appears > > in the > > > table multiple > > > > >> times. > > > > >> > > > > >> Additionally, section 4.2 describes how to > > perform a stereo > > > > downmix of > > > > >> mapping family 3, but makes assumptions about the > > > output channel > > > > >> numbering. This seems harmful and likely to > promote > > > implementations > > > > >> that make similar assumptions. If it is > necessary to > > > apply the > > > > output > > > > >> channel numbering described in section 3.2 in > > order to > > > implement a > > > > >> correct stereo downmix, then it would be better to > > > simply use the > > > > >> output channels from section 3 as input to the > > downmix, > > > consolidating > > > > >> sections 4.1 and 4.2, rather than specify new > > formulas > > > that make > > > > >> assumptions about the mapping. That would also > > greatly > > > simplify > > > > >> section 4. > > > > >> > > > > >> Eliminating the Output Channel Numbering table as > > > Jean-Marc suggests > > > > >> should resolve these concerns. > > > > > > > > > > > > > > > The problem is that once we allow mixed orders > > there is > > > no unique > > > > way for a > > > > > receiver/decoder > > > > > to resolve the mapping to ACNs from just a number > of > > > total output > > > > channels. > > > > > > > > > > > > In mapping family 2, the channel count (C) is the > number > > > of channels > > > > in the fully periphonic configuration, but it is not > > > necessary to > > > > encode them all. The channel mapping table can map > each > > > ACN to a > > > > specific decoded channel or to silence. For mixed > > order, > > > some of the > > > > ACNs will be mapped to silence and will not be > encoded. > > > > > > > > In mapping family 3, the matrix can do everything > > that the > > > channel > > > > mapping table can do and more. Why not treat C in > the > > > same manner, as > > > > the number of channels in the fully periphonic > > > configuration, even if > > > > some are silent? > > > > > > > > - Mark > > > > > > > > _______________________________________________ > > > > codec mailing list > > > > codec@ietf.org > > > > > > > > >> > > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > > > > > > > _______________________________________________ > > > > codec mailing list > > > > codec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > --94eb2c059f0256d910054aa42f10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ha, sorry, wrong name! I meant avoiding permutation matric= es.

Jan

On Mon, Mar 13, 2017 at 3:19 PM Jean-Marc Valin <jmvalin@jmvalin.ca> wrote:
On 13/03/17 06:17 PM, Jan Skoglund wrote:
> Our idea was to avoid a mapping table, potentially sparse, completely<= br class=3D"gmail_msg"> > for family 2, and replacing it with a channel numbering list for famil= y 3.

Can you explain what you mean here by "avoid a mapping table" for= family
2 and "channel numbering list" for family 3?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc

> Cheers,
> Jan
>
> On Mon, Mar 13, 2017 at 3:12 PM Jean-Marc Valin <jmvalin@mozilla.= com
> <mailto:jmvalin@mozilla.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 13/03/17 06:04 PM, Drew Allen wrote:
>=C2=A0 =C2=A0 =C2=A0> so just to be clear, if a user, say, wants to = encode some mixed order
>=C2=A0 =C2=A0 =C2=A0> ambisonics using ch253, how does the decoder k= now what ambisonic
>=C2=A0 =C2=A0 =C2=A0> channels it has received and know how to rende= r them correctly?
>
>=C2=A0 =C2=A0 =C2=A0Well, each line of the matrix would correspond to a= channel in the
>=C2=A0 =C2=A0 =C2=A0ambisonics channel order. If that channel isn't= encoded, then the line
>=C2=A0 =C2=A0 =C2=A0would have only zeros.
>
>=C2=A0 =C2=A0 =C2=A0The only way to avoid that situations would be to e= ncode a separate D
>=C2=A0 =C2=A0 =C2=A0value (D <=3D C) for the number of non-zero chan= nels among the C
>=C2=A0 =C2=A0 =C2=A0ambisonics channels possible. Then you'd store = C values in the channel
>=C2=A0 =C2=A0 =C2=A0mapping array (equivalent to a CxD permutation matr= ix), followed by a
>=C2=A0 =C2=A0 =C2=A0Dx(M+N) weight matrix that would no longer have ent= ire lines of zeros.
>=C2=A0 =C2=A0 =C2=A0The result would be more compact in the case of spa= rse representation,
>=C2=A0 =C2=A0 =C2=A0but IMO it'd be pretty ugly and prone to implem= entation errors. And if
>=C2=A0 =C2=A0 =C2=A0you force D=3D=3DC and don't code the D (which = is what I'm proposing), then
>=C2=A0 =C2=A0 =C2=A0the channel mapping permutation automatically becom= es redundant.
>
>=C2=A0 =C2=A0 =C2=A0Cheers,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jean-Marc
>
>=C2=A0 =C2=A0 =C2=A0> On Mon, Mar 13, 2017 at 3:00 PM Drew Allen <= ;bitllama@google.com
>=C2=A0 =C2=A0 =C2=A0<mailto:bitllama@google.com>
>=C2=A0 =C2=A0 =C2=A0> <mailto:bitllama@google.com <mailt= o:bitllama@google.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Got it. In that case, it ce= rtainly seems reasonable if I
>=C2=A0 =C2=A0 =C2=A0understand
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0correctly. Thanks for clear= ing that up!
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On Mon, Mar 13, 2017 at 2:5= 5 PM Jean-Marc Valin
>=C2=A0 =C2=A0 =C2=A0<jmvalin@mozilla.com <mailto:jmvalin@= mozilla.com>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<mailto:jmvalin@mozill= a.com <mailto:jmvalin@mozilla.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 13/03/17 0= 5:44 PM, Drew Allen wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I think = the issue is that the number of total channels rises
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> quadrati= cally in respect to the ambisonic order (N +
>=C2=A0 =C2=A0 =C2=A01)^2. If
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a user
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> wants to= use just the horizontal channels, it is only 2
>=C2=A0 =C2=A0 =C2=A0* N +
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. If they >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> wish to = code very high-order (>10th order) horizontal
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0channels, the= y
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> would be= artifically limited by all the zero channels being
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0produced,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> no? Or c= an this handled without actually creating all those
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0empty channel= s?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As far as I u= nderstand, the current draft already has all the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limitations y= ou're describing. The channel mapping array is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0basically
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0equivalent to= a CxC permutation matrix that multiplies the
>=C2=A0 =C2=A0 =C2=A0Cx(N+M)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0weight matrix= . The result is still a Cx(N+M) matrix, so
>=C2=A0 =C2=A0 =C2=A0using the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resulting mat= rix as weights can still do everything
>=C2=A0 =C2=A0 =C2=A0without the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need for
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the channel m= apping to do the permutations.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers,
>=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=A0Jean-Marc
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On Mon, = Mar 13, 2017 at 2:41 PM Mark Harris
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mark.h= sj@gmail.com <mailto:mark.hsj@gmail.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:mark.hsj@gmail.com <mailto:mark= .hsj@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> <mail= to:mark.hsj@gmail.com <mailto:mark.hsj@gmail.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:mark.hsj@gmail.com <mailto:mark= .hsj@gmail.com>>>> wrote:
>=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=A0On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<jks@google= .com <mailto:jks@google.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:jks@google.com <mailto:jks@google.com<= /a>>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0<mailto:jks@google.com <mailto:jks@google.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:jks@google.com <mailto:jks@google.com<= /a>>>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Hey,
>=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> Thanks for your comments
>=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> On Mon, Mar 13, 2017 at 10:08 AM Mark Harris
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mark.h= sj@gmail.com <mailto:mark.hsj@gmail.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:mark.hsj@gmail.com <mailto:mark= .hsj@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0<mailto:mark.hsj@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:mark.hsj@gmail.com> <mailto:<= a href=3D"mailto:mark.hsj@gmail.com" class=3D"gmail_msg" target=3D"_blank">= mark.hsj@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:mark.hsj@gmail.com>>>><= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>=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>> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc Valin
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0<jmvalin@jmvalin.ca <mailto:jmvalin@jmvalin.ca= >
>=C2=A0 =C2=A0 =C2=A0<mailto:jmvalin@jmvalin.ca <mailto:jmva= lin@jmvalin.ca>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:j= mvalin@jmvalin.ca <mailto:jmvalin@jmvalin.ca>
>=C2=A0 =C2=A0 =C2=A0<mailto:jmvalin@jmvalin.ca <mailto:jmva= lin@jmvalin.ca>>>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> > 3.2.=C2=A0 Channel Mapping Family 3
>=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>> > I would suggest removing the "Output Channe= l
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Numbering&quo= t; field
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0because it
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> > is fully equivalent to simply permuting lines >=C2=A0 =C2=A0 =C2=A0of the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matrix.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0Also, I
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> > believe that the size of the matrix was meant to= be
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"32*(N+M= )*C
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0bits"
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> > rather than "32*N*C bits".
>=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>> To expand on this a bit, a mapping family maps M+N >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decoded chann= els
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> (corresponding to the actual order of the coupled and=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uncoupled
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> channels in the bitstream) to C output channels
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(channels wit= h a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> specific semantic meaning).=C2=A0 The additional
>=C2=A0 =C2=A0 =C2=A0"Output Channel
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0Numbering"
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> table confuses things by adding an additional mapping=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from the outp= ut
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> channel numbers to a different set of numbers with >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actual semant= ic
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> meaning, leaving the output channel numbers with no >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apparent mean= ing.
>=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>> This does have a potential benefit as a matrix
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compression t= echnique,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> to reduce the size of the matrix when it would
>=C2=A0 =C2=A0 =C2=A0contain
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rows that are=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> all zero.=C2=A0 However considering that the matrix o= ccurs
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only once, an= d
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> mapping family 2 already offers a way to compress the=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matrix, this<= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> alone does not seem worth the complexity of another >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0level of
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> indirection.=C2=A0 If matrix compression is desired i= t
>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0probably be >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> less confusing to describe it in those terms and keep=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the semantic<= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> meaning tied to the output channels.
>=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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> The description of the Output Channel Numbering also<= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0does not spec= ify
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> the intended behavior if the same value appears
>=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0table multipl= e
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> times.
>=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>> Additionally, section 4.2 describes how to
>=C2=A0 =C2=A0 =C2=A0perform a stereo
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0downmix of
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> mapping family 3, but makes assumptions about the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0output channe= l
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> numbering.=C2=A0 This seems harmful and likely to pro= mote
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementatio= ns
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> that make similar assumptions.=C2=A0 If it is necessa= ry to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apply the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0output
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> channel numbering described in section 3.2 in
>=C2=A0 =C2=A0 =C2=A0order to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implement a >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> correct stereo downmix, then it would be better to >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simply use th= e
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> output channels from section 3 as input to the
>=C2=A0 =C2=A0 =C2=A0downmix,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consolidating=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> sections 4.1 and 4.2, rather than specify new
>=C2=A0 =C2=A0 =C2=A0formulas
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that make
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> assumptions about the mapping.=C2=A0 That would also<= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0greatly
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simplify
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> section 4.
>=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>> Eliminating the Output Channel Numbering table as
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jean-Marc sug= gests
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>> should resolve these concerns.
>=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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> The problem is that once we allow mixed orders
>=C2=A0 =C2=A0 =C2=A0there is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no unique
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0way for a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> receiver/decoder
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> to resolve the mapping to ACNs from just a number of
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0total output<= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0channels.
>=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=A0In mapping family 2, the channel count (C) is the number
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of channels >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0in the fully periphonic configuration, but it is not
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0necessary to<= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0encode them all.=C2=A0 The channel mapping table can map each<= br class=3D"gmail_msg"> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACN to a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0specific decoded channel or to silence.=C2=A0 For mixed
>=C2=A0 =C2=A0 =C2=A0order,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some of the >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0ACNs will be mapped to silence and will not be encoded.
>=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=A0In mapping family 3, the matrix can do everything
>=C2=A0 =C2=A0 =C2=A0that the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0channel
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0mapping table can do and more.=C2=A0 Why not treat C in the >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0same manner, = as
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0the number of channels in the fully periphonic
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration= , even if
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0some are silent?
>=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 - Mark
>=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 = =C2=A0 =C2=A0codec mailing list
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0codec@ietf.org <mailto:codec@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:codec@ietf.org <mailto:codec@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:codec= @ietf.org <mailto:codec@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:codec@ietf.org <mailto:codec@ietf.org<= /a>>>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0https://www.ietf.org/mai= lman/listinfo/codec
>=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ________= _______________________________________
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> codec ma= iling list
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> codec@ietf= .org <mailto:codec@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:codec@ietf.org <mailto:codec@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/listinfo/code= c
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/codec
>
--94eb2c059f0256d910054aa42f10-- From nobody Mon Mar 13 15:35:26 2017 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 D1245129B4C for ; Mon, 13 Mar 2017 15:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 IYgful63RfPq for ; Mon, 13 Mar 2017 15:35:21 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 13F98129AF4 for ; Mon, 13 Mar 2017 15:35:21 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id f84so92565413ioj.0 for ; Mon, 13 Mar 2017 15:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=WSZsYq1XMw5m8h62T5E+P4tyZbHJGEHgrS8JqkVdhZY=; b=F0T0y8XqC2oQ3LJFwUgCGl2vGKyvb3ZE+GcANX303BqmQ0GlK4/NGvllrymsfkEkB3 9kehxjCYomjLZlpWKQI56KHNSDFemg6aG5A4bT3Nf2+cw7JVBzELXUeSB+n/5eQuirMu rRHkeD4Aaet6/FNGmDS9vmQUpUWzOjQ56WpqE= 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:from:message-id:date :user-agent:mime-version:in-reply-to; bh=WSZsYq1XMw5m8h62T5E+P4tyZbHJGEHgrS8JqkVdhZY=; b=bkWN24pMerhp4xbpPvi1yULguS55v6bHjR461DfiOa/VKOqXiuIeKkkEVEf97wqKaE J2zDbQtza7AEudqrJN/U68HjfMOJycfz7s5VAWRuz0PAFj5vUYHkdNUlXpfQ3Xt/O2xm saT+9Moz7WTciA/CUDSjHHtFFob1DHlQoQdXVrGnqD0m8j4hGv+L4gxd5bFN0xSsiHWP 2IMwCkeCMNyuSqXwqVUXJnqzamlJNOVUfRL5M+1i2ECOvUpQHbo7jRD2WZ/28d5ivaH1 gAcQp0cIsMSxEbUYKsiwp9hS+gwS7q/YNxImzl3u3ib+BslzIbJ6Ulk3DBmnlrC7bBE7 Dy/g== X-Gm-Message-State: AMke39k9xev1Vz7L8CVBz2w+d9398IfFbJnfss3M2oonUCQxEZWn07oWE+dyz+BUQNRNb0w8 X-Received: by 10.107.46.85 with SMTP id i82mr28349357ioo.85.1489444520236; Mon, 13 Mar 2017 15:35:20 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable067.31-56-74.mc.videotron.ca. [74.56.31.67]) by smtp.gmail.com with ESMTPSA id z5sm4268794ita.6.2017.03.13.15.35.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 15:35:19 -0700 (PDT) To: Jan Skoglund , Jean-Marc Valin , Drew Allen , Mark Harris , "codec@ietf.org" References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> From: Jean-Marc Valin Message-ID: <2480dd55-eaef-9376-c88a-d764d777dfad@mozilla.com> Date: Mon, 13 Mar 2017 18:35:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jcpt5ssN7hfslbFoA4o1DHSCCkpECvFb4" Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:35:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jcpt5ssN7hfslbFoA4o1DHSCCkpECvFb4 Content-Type: multipart/mixed; boundary="3kaoOv09wgOIwkG938s7C94PN5vge9Aj9"; protected-headers="v1" From: Jean-Marc Valin To: Jan Skoglund , Jean-Marc Valin , Drew Allen , Mark Harris , "codec@ietf.org" Message-ID: <2480dd55-eaef-9376-c88a-d764d777dfad@mozilla.com> Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> In-Reply-To: --3kaoOv09wgOIwkG938s7C94PN5vge9Aj9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Well, for family 2 is makes sense to have just a mapping table (1-D array of size C) and no matrix. Note that in previous comments, I was using the term "permutation matrix" only in the sense that the 1-D array is mathematically equivalent to a (sparse) permutation matrix. For family 3, if you already have a Cx(N+M) weight matrix, then the mapping table becomes completely redundant. Jean-Marc On 13/03/17 06:25 PM, Jan Skoglund wrote: > Ha, sorry, wrong name! I meant avoiding permutation matrices. >=20 > Jan >=20 > On Mon, Mar 13, 2017 at 3:19 PM Jean-Marc Valin > wrote: >=20 > On 13/03/17 06:17 PM, Jan Skoglund wrote: > > Our idea was to avoid a mapping table, potentially sparse, comple= tely > > for family 2, and replacing it with a channel numbering list for > family 3. >=20 > Can you explain what you mean here by "avoid a mapping table" for f= amily > 2 and "channel numbering list" for family 3? >=20 > Jean-Marc >=20 > > Cheers, > > Jan > > > > On Mon, Mar 13, 2017 at 3:12 PM Jean-Marc Valin > > > >> wrote:= > > > > On 13/03/17 06:04 PM, Drew Allen wrote: > > > so just to be clear, if a user, say, wants to encode some > mixed order > > > ambisonics using ch253, how does the decoder know what ambi= sonic > > > channels it has received and know how to render them correc= tly? > > > > Well, each line of the matrix would correspond to a channel i= n the > > ambisonics channel order. If that channel isn't encoded, then= > the line > > would have only zeros. > > > > The only way to avoid that situations would be to encode a > separate D > > value (D <=3D C) for the number of non-zero channels among th= e C > > ambisonics channels possible. Then you'd store C values in th= e > channel > > mapping array (equivalent to a CxD permutation matrix), > followed by a > > Dx(M+N) weight matrix that would no longer have entire lines > of zeros. > > The result would be more compact in the case of sparse > representation, > > but IMO it'd be pretty ugly and prone to implementation > errors. And if > > you force D=3D=3DC and don't code the D (which is what I'm > proposing), then > > the channel mapping permutation automatically becomes redunda= nt. > > > > Cheers, > > > > Jean-Marc > > > > > On Mon, Mar 13, 2017 at 3:00 PM Drew Allen > > > > > > > > >>> wrote: > > > > > > Got it. In that case, it certainly seems reasonable if = I > > understand > > > correctly. Thanks for clearing that up! > > > > > > On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin > > > > > > > > >>> wrote: > > > > > > On 13/03/17 05:44 PM, Drew Allen wrote: > > > > I think the issue is that the number of total > channels rises > > > > quadratically in respect to the ambisonic order (= N + > > 1)^2. If > > > a user > > > > wants to use just the horizontal channels, it is > only 2 > > * N + > > > 1. If they > > > > wish to code very high-order (>10th order) horizo= ntal > > > channels, they > > > > would be artifically limited by all the zero > channels being > > > produced, > > > > no? Or can this handled without actually creating= > all those > > > empty channels? > > > > > > As far as I understand, the current draft already > has all the > > > limitations you're describing. The channel mapping > array is > > > basically > > > equivalent to a CxC permutation matrix that > multiplies the > > Cx(N+M) > > > weight matrix. The result is still a Cx(N+M) matrix= , so > > using the > > > resulting matrix as weights can still do everything= > > without the > > > need for > > > the channel mapping to do the permutations. > > > > > > Cheers, > > > > > > Jean-Marc > > > > > > > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris > > > > > > > > >> > > > > > > > > >>>> wrote: > > > > > > > > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglun= d > > > > > > > > >> > > > > > > > > > >>>> wrote: > > > > > Hey, > > > > > > > > > > Thanks for your comments > > > > > > > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harri= s > > > > > > > > >> > > > > > > > > > > >>>> > > > wrote: > > > > >> > > > > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc= > Valin > > > > > > > > >> > > > > > > > >>>> > > > > >> wrote: > > > > >> > 3.2. Channel Mapping Family 3 > > > > >> > > > > > >> > I would suggest removing the "Output Cha= nnel > > > Numbering" field > > > > because it > > > > >> > is fully equivalent to simply permuting = lines > > of the > > > matrix. > > > > Also, I > > > > >> > believe that the size of the matrix was > meant to be > > > "32*(N+M)*C > > > > bits" > > > > >> > rather than "32*N*C bits". > > > > >> > > > > >> To expand on this a bit, a mapping family > maps M+N > > > decoded channels > > > > >> (corresponding to the actual order of the > coupled and > > > uncoupled > > > > >> channels in the bitstream) to C output cha= nnels > > > (channels with a > > > > >> specific semantic meaning). The additiona= l > > "Output Channel > > > > Numbering" > > > > >> table confuses things by adding an > additional mapping > > > from the output > > > > >> channel numbers to a different set of > numbers with > > > actual semantic > > > > >> meaning, leaving the output channel number= s > with no > > > apparent meaning. > > > > >> > > > > >> This does have a potential benefit as a ma= trix > > > compression technique, > > > > >> to reduce the size of the matrix when it w= ould > > contain > > > rows that are > > > > >> all zero. However considering that the > matrix occurs > > > only once, and > > > > >> mapping family 2 already offers a way to > compress the > > > matrix, this > > > > >> alone does not seem worth the complexity o= f > another > > > level of > > > > >> indirection. If matrix compression is > desired it > > would > > > probably be > > > > >> less confusing to describe it in those > terms and keep > > > the semantic > > > > >> meaning tied to the output channels. > > > > >> > > > > >> > > > > >> The description of the Output Channel > Numbering also > > > does not specify > > > > >> the intended behavior if the same value ap= pears > > in the > > > table multiple > > > > >> times. > > > > >> > > > > >> Additionally, section 4.2 describes how to= > > perform a stereo > > > > downmix of > > > > >> mapping family 3, but makes assumptions > about the > > > output channel > > > > >> numbering. This seems harmful and likely > to promote > > > implementations > > > > >> that make similar assumptions. If it is > necessary to > > > apply the > > > > output > > > > >> channel numbering described in section 3.2= in > > order to > > > implement a > > > > >> correct stereo downmix, then it would be > better to > > > simply use the > > > > >> output channels from section 3 as input to= the > > downmix, > > > consolidating > > > > >> sections 4.1 and 4.2, rather than specify = new > > formulas > > > that make > > > > >> assumptions about the mapping. That would= also > > greatly > > > simplify > > > > >> section 4. > > > > >> > > > > >> Eliminating the Output Channel Numbering > table as > > > Jean-Marc suggests > > > > >> should resolve these concerns. > > > > > > > > > > > > > > > The problem is that once we allow mixed ord= ers > > there is > > > no unique > > > > way for a > > > > > receiver/decoder > > > > > to resolve the mapping to ACNs from just a > number of > > > total output > > > > channels. > > > > > > > > > > > > In mapping family 2, the channel count (C) is= > the number > > > of channels > > > > in the fully periphonic configuration, but it= > is not > > > necessary to > > > > encode them all. The channel mapping table > can map each > > > ACN to a > > > > specific decoded channel or to silence. For = mixed > > order, > > > some of the > > > > ACNs will be mapped to silence and will not b= e > encoded. > > > > > > > > In mapping family 3, the matrix can do everyt= hing > > that the > > > channel > > > > mapping table can do and more. Why not treat= > C in the > > > same manner, as > > > > the number of channels in the fully periphoni= c > > > configuration, even if > > > > some are silent? > > > > > > > > - Mark > > > > > > > > _____________________________________________= __ > > > > codec mailing list > > > > codec@ietf.org > > > > > >> > > > > > > > > >>> > > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > > > > > > > _______________________________________________ > > > > codec mailing list > > > > codec@ietf.org > > > > > >> > > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > >=20 --3kaoOv09wgOIwkG938s7C94PN5vge9Aj9-- --jcpt5ssN7hfslbFoA4o1DHSCCkpECvFb4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYxx6mAAoJEF5d2aNvkYnIiVQP/jDYZSdaAz5uxjlrQc8eR4Ci ZKlkQYLtf80nDWRVjDLHKvE898U26y9GQzmjNTZDhRImbGtvAq5ssYfmhJFVjHPY yC8rhVsB+6TzYoJc4aHEUzHodcPlBUhnI2gzTpDP+44MOpOpqNzUbiJbOUwcuqYc 2JHpwtuZ//thatf/mcGxVdy3AfacZq50fRi2kQ7aNfKq9iZeViywouwuzwN6pF8b X74NjsiquOHseb6LTmVTHN9cPXXNNrhFHJD6+kLKuRhvvN7XFr/NnaEnzMStHj7S t4wLNUsE8UlDczNiqvQBkAbkiFmZNhgxd045XLxmW2SvuHnSWgyJ9RvpJXOYKyQ/ Hnz1a95EXkaM9xm39MYbD9Pgc6ADSREwayIp93gb8lQIIul8gCWWRzUlgksQl9el o9VM8+8yHIHqOFktW17s9G22p9FDC/NbsRgGTirefIm5g9OJ7Yr5XaUdYAaO/X2F etVMkQxBSmHXNLWtIVwv4gjS1NZShWWKHAmvlSOHrU4ToD2Dh739QauU2jXZ0Z2M nyDdEmXo4IJA53trVcffCbo5y4wz5+i2zZtQ3o0drtQlyzkHvZ6KmPdCR5gzhtKv zdO66vJpOznNWFWge10KHDY3Vgfm4m3ZGQhsG9hmZv3Vy2Z3Bf5zr1U7771ulW3V nXXn/7lmNZ7ikT1qtZTE =baN0 -----END PGP SIGNATURE----- --jcpt5ssN7hfslbFoA4o1DHSCCkpECvFb4-- From nobody Mon Mar 13 16:07:08 2017 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 409BF129BEB for ; Mon, 13 Mar 2017 16:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 X1hlWWOIHZyU for ; Mon, 13 Mar 2017 16:07:04 -0700 (PDT) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (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 8794D129BCE for ; Mon, 13 Mar 2017 16:06:55 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 60C84C1792; Mon, 13 Mar 2017 23:06:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEi3ODegR-xn; Mon, 13 Mar 2017 23:06:55 +0000 (UTC) Received: from [10.252.26.5] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 3951CC1764; Mon, 13 Mar 2017 23:06:55 +0000 (UTC) Message-ID: <58C7260F.6030506@xiph.org> Date: Mon, 13 Mar 2017 16:06:55 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: Jean-Marc Valin , Jan Skoglund , Jean-Marc Valin , Drew Allen , Mark Harris , "codec@ietf.org" References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> <2480dd55-eaef-9376-c88a-d764d777dfad@mozilla.com> In-Reply-To: <2480dd55-eaef-9376-c88a-d764d777dfad@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:07:06 -0000 Jean-Marc Valin wrote: > For family 3, if you already have a Cx(N+M) weight matrix, then the > mapping table becomes completely redundant. I think the issue boils down to whether it's worth it to have a table of size C to allow a matrix of size Kx(N+M) instead of Cx(N+M) in the headers where D is some number smaller than C (probably D=N+M). If more than 80% of your matrix is filled with zeros (100 out of 121 rows for 10th order with only horizontal channels), that could be seen as a little wasteful. That said, we very intentionally chose the direction of the channel mapping table for RFC 7845: one value per output channel that says which decoded channel to use. That makes it impossible to send multiple decoded channels (mixed channels after multiplying by the weight matrix in this draft) to the same speaker (ACN number in this draft). As Mark Harris points out, this is a failure case the current draft doesn't specify how to deal with. By doing the mapping in the same direction as RFC 7845, the worst failure case is that someone specifies a channel index larger than what's actually available, but that's easily detectable (i.e., you can tell without having to look at any other values in the mapping table). You also don't need to handle the diegetic channels separately. There is a special case for silent channels, but as a benefit it become easy (O(1)) to tell if a channel isn't used. Having the mapping work in this direction would also be more consistent with Channel Mapping Family 2. From nobody Mon Mar 13 16:39:25 2017 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 EA8FF129C14 for ; Mon, 13 Mar 2017 16:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 QGmC9ZpFtPTE for ; Mon, 13 Mar 2017 16:39:19 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 65CEE129673 for ; Mon, 13 Mar 2017 16:39:19 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id i34so44426662qtc.0 for ; Mon, 13 Mar 2017 16:39:19 -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; bh=7uzmxfKS4WBesmaPUiVt199yq+hE/45KWWZZmOLsipY=; b=d7j5l6+FVAfxaF61rNCcjf8bfFp6wO/yAPCcTkT+Dgd3GrZa+p1vAIyc15hxpl3Qls VFOQSElx2At0P17OG0gTn7X4UMnFsi11FQTHGLdV4kvyi1oaOOKcgCrSBi/wnuB5MDl5 JO9xNWzS2+SNjCISkBr+5O0p4pZAYX50UfhUpFVs8JL2rxpFoLNTN4L6Gp9Npi2UYxIZ civKRimDII08uHr3CwFbf50mK8UJSQ9szbN2BfvfZ9/9CsvY2206vDGQrediKlm6El22 HX73kQOxCuoluFukPK+ZRBB8JJe9rOKcLZVHyLJKEHhK7nIeFMZYVvYXEMdEQ43cwriW evNg== 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; bh=7uzmxfKS4WBesmaPUiVt199yq+hE/45KWWZZmOLsipY=; b=RctmkUAJAOyL9In7C/NAlHCjbVshgg4rWvB2Z28Td0a6OlkVyeLVe8n/QLJdzt+V4Q XY7vBpyp7lNvriJs4kHwPZUokcVgvG4szQQxcKLF9a1UoJBQg/mOH3OAAS0ZdB6GRKy5 hBP0cqYYm1G6/XSP2xOPA7T65T07/2MvefMeiJQH7g8bayJlpkASvKqltVHgvj+zZyqW 95cB6FOXcGW7RimgSKx52wCLqHAg11EQBhLmEzaxPQwfvs4kEX6rRNCjW+sQvi9k+yhz s23wACOokFEhZqNyxBeWHRJVg49tjxdvhPgURCnSa2WZLP7yWjqfex5quVUONmlPqHNS YDOQ== X-Gm-Message-State: AMke39mh4suj1SksEavZBCMdEcBNbpxHPUBVgFJodUD+oSKa7d6RICkBIpD4HFC408aIvcHAiQWXIw4mdvsPts/x X-Received: by 10.237.57.164 with SMTP id m33mr37098754qte.293.1489448358361; Mon, 13 Mar 2017 16:39:18 -0700 (PDT) MIME-Version: 1.0 References: <2f534e1b-b1af-266a-50ef-36f1739d878b@jmvalin.ca> <52f5a570-e9f4-ea49-515e-498f0ed4f1bb@mozilla.com> <17622007-e5ce-0a08-67df-98c30a51e5a8@mozilla.com> <2480dd55-eaef-9376-c88a-d764d777dfad@mozilla.com> <58C7260F.6030506@xiph.org> In-Reply-To: <58C7260F.6030506@xiph.org> From: Jan Skoglund Date: Mon, 13 Mar 2017 23:39:07 +0000 Message-ID: To: "Timothy B. Terriberry" , Jean-Marc Valin , Jean-Marc Valin , Drew Allen , Mark Harris , "codec@ietf.org" Content-Type: multipart/alternative; boundary=001a11410306501867054aa538a9 Archived-At: Subject: Re: [codec] Comments on draft-ietf-codec-ambisonics-01 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:39:24 -0000 --001a11410306501867054aa538a9 Content-Type: text/plain; charset=UTF-8 Thanks Mark, Jean-Marc, and Tim, It makes sense to use the table already defined in RFC 7845, which then automatically allows mixed order also for family 2. We'll remove the "channel numbering table" for family 3. Cheers, Jan On Mon, Mar 13, 2017 at 4:06 PM Timothy B. Terriberry wrote: > Jean-Marc Valin wrote: > > For family 3, if you already have a Cx(N+M) weight matrix, then the > > mapping table becomes completely redundant. > > I think the issue boils down to whether it's worth it to have a table of > size C to allow a matrix of size Kx(N+M) instead of Cx(N+M) in the > headers where D is some number smaller than C (probably D=N+M). If more > than 80% of your matrix is filled with zeros (100 out of 121 rows for > 10th order with only horizontal channels), that could be seen as a > little wasteful. > > That said, we very intentionally chose the direction of the channel > mapping table for RFC 7845: one value per output channel that says which > decoded channel to use. That makes it impossible to send multiple > decoded channels (mixed channels after multiplying by the weight matrix > in this draft) to the same speaker (ACN number in this draft). As Mark > Harris points out, this is a failure case the current draft doesn't > specify how to deal with. By doing the mapping in the same direction as > RFC 7845, the worst failure case is that someone specifies a channel > index larger than what's actually available, but that's easily > detectable (i.e., you can tell without having to look at any other > values in the mapping table). You also don't need to handle the diegetic > channels separately. There is a special case for silent channels, but as > a benefit it become easy (O(1)) to tell if a channel isn't used. > > Having the mapping work in this direction would also be more consistent > with Channel Mapping Family 2. > > --001a11410306501867054aa538a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Mark, Jean-Marc, and Tim,

It mak= es sense to use the table already defined in RFC 7845, which then automatic= ally allows mixed order also for family 2. We'll remove the "chann= el numbering table" for family 3.

Cheers,=
Jan



On Mon, Mar 13, 2017 at 4:06 PM Timothy B. Ter= riberry <tterribe@xiph.org> = wrote:
Jean-Marc Valin wrote:
> For family 3, if you already have a Cx(N+M) weight matrix, then the > mapping table becomes completely redundant.

I think the issue boils down to whether it's worth it to have a table o= f
size C to allow a matrix of size Kx(N+M) instead of Cx(N+M) in the
headers where D is some number smaller than C (probably D=3DN+M). If more than 80% of your matrix is filled with zeros (100 out of 121 rows for
10th order with only horizontal channels), that could be seen as a
little wasteful.

That said, we very intentionally chose the direction of the channel
mapping table for RFC 7845: one value per output channel that says which decoded channel to use. That makes it impossible to send multiple
decoded channels (mixed channels after multiplying by the weight matrix
in this draft) to the same speaker (ACN number in this draft). As Mark
Harris points out, this is a failure case the current draft doesn't
specify how to deal with. By doing the mapping in the same direction as
RFC 7845, the worst failure case is that someone specifies a channel
index larger than what's actually available, but that's easily
detectable (i.e., you can tell without having to look at any other
values in the mapping table). You also don't need to handle the diegeti= c
channels separately. There is a special case for silent channels, but as a benefit it become easy (O(1)) to tell if a channel isn't used.

Having the mapping work in this direction would also be more consistent
with Channel Mapping Family 2.

--001a11410306501867054aa538a9-- From nobody Thu Mar 23 13:52:18 2017 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 32851128959 for ; Thu, 23 Mar 2017 13:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 017YuWDgwKDk for ; Thu, 23 Mar 2017 13:52:12 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 8B4FB1296BE for ; Thu, 23 Mar 2017 13:52:11 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p22so51614820qka.3 for ; Thu, 23 Mar 2017 13:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jZ6yu8eeLnwxzfQe+HQ7E9/7y4ThTny4lO3AiIQ52NM=; b=EleCXYkKrzNUNZRhFbvirm86cQMkKJP7aiGegj9IADqxmVY6Cxa6GK4SbT83Id9aZa 9axxni7Hgfq+v1glVbxWS1uJ2hkAdRo8SpYccwLBDO/+50iNr26Na2sXZDieD+Jeeiz9 0BH5lLT6XIvCNvY1PH1tNNHn6XVtulLRqREMUd6r5uBPKJXsFnAxM+Z+UjCV8QXSalOu XsShNhj/P4ivpR6n0mksLALWptpoXGqYDpDhW7ZIURinPufOVXGelajS4UyKFr0B9bCi av3vSnZomfGueAbGCaRxKsmzaALahH8RybtoBhMRcvyd3MaymsjZp1a8bK6H/e+uv5LR JJWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jZ6yu8eeLnwxzfQe+HQ7E9/7y4ThTny4lO3AiIQ52NM=; b=qaQpynkKLiko3PeoVJP7wLJXhp5N5Ag9WluBbtUyXCugRr5mwVMRmtdtid2SWaN73k 84PKmkApPOomTB0YffuL7QpsDn34IyAqD2RW7Ud//MWT0wgD92XF/PaYXE6gqsaBMSej /+cqON+Or2I1fd2wwBlVFmaq9U03T3aQ6gIi32zCUh7Tq+gpk51X+rWZC/rdCs2GBvj3 d07xarx5tk8/js9WiwGx0gxFieuPPiCZk353RFYhxSI20qseisUSV+g0pBcHyo6inzZX yDqFZEyTByAiWctiU4Chbs+R7tzLI3CyqjNIN7ssQ9iIeYbHKBTHDPHiBMR1Ui9C6qM8 mwHw== X-Gm-Message-State: AFeK/H1TdAm2RxrJ0Jaa8qwIcXD5jzxhV5v1yo1FQfU6iTbEMnXSXmMJqsqd8UrG/1tAVhzbhHguGiDAa6rHB5fN X-Received: by 10.55.141.195 with SMTP id p186mr4150673qkd.183.1490302330089; Thu, 23 Mar 2017 13:52:10 -0700 (PDT) MIME-Version: 1.0 From: Jan Skoglund Date: Thu, 23 Mar 2017 20:51:59 +0000 Message-ID: To: IETF - CoDec Content-Type: multipart/mixed; boundary=94eb2c08340c00420d054b6c0d63 Archived-At: Subject: [codec] Upcoming new version of draft-ietf-codec-ambisonics X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 20:52:17 -0000 --94eb2c08340c00420d054b6c0d63 Content-Type: multipart/alternative; boundary=94eb2c08340c004209054b6c0d61 --94eb2c08340c004209054b6c0d61 Content-Type: text/plain; charset=UTF-8 Folks, We have a new revision of this draft (attached). Unfortunately it wasn't ready in time for the submission cut-off prior to the IETF meeting next week but we still want to focus the discussion at the session, and afterwards, based on this new revision. We realize that due to the short notice not everyone will have a chance to read it before the session and apologize for the inconvenience. Cheers, Jan --94eb2c08340c004209054b6c0d61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,=C2=A0

We have a new revision of this draft (attached).= Unfortunately it wasn't ready in time for the submission cut-off prior= to the IETF meeting next week but we still want to focus the discussion at= the session, and afterwards, based on this new revision. We realize that d= ue to the short notice not everyone will have a chance to read it before th= e session and apologize for the inconvenience.=C2=A0

Cheers,
Jan
--94eb2c08340c004209054b6c0d61-- --94eb2c08340c00420d054b6c0d63 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-codec-ambisonics-02.txt" Content-Disposition: attachment; filename="draft-ietf-codec-ambisonics-02.txt" Content-Transfer-Encoding: base64 Content-ID: <15af7f78d01f459b92d1> X-Attachment-Id: 15af7f78d01f459b92d1 CgoKCmNvZGVjICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBKLiBTa29nbHVuZApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE0uIEdyYWN6eWsKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdvb2dsZSBJbmMuCkV4cGly ZXM6IFNlcHRlbWJlciAxOCwgMjAxNyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJj aCAxNywgMjAxNwoKCiAgICAgICAgICAgICAgICAgIEFtYmlzb25pY3MgaW4gYW4gT2dnIE9wdXMg Q29udGFpbmVyCiAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtY29kZWMtYW1iaXNvbmlj cy0wMgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbnNpb24gdG8g dGhlIE9nZyBmb3JtYXQgdG8gZW5jYXBzdWxhdGUKICAgYW1iaXNvbmljcyBjb2RlZCB1c2luZyB0 aGUgT3B1cyBhdWRpbyBjb2RlYy4KClN0YXR1cyBvZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJu ZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJv dmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2Ug KElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJh ZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVw bGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJ dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDE4LCAy MDE3LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDE3IElFVEYgVHJ1c3Qg YW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBB bGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3 OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElF VEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGlu IGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAg UGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2Ny aWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMg ZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBt dXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHBy b3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlLgoKCgoKCgpTa29nbHVuZCAmIEdyYWN6eWsgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDE4LCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgIE9wdXMgQW1iaXNvbmljcyAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTcKCgpU YWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBUZXJtaW5vbG9neSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAzLiAg QW1iaXNvbmljcyBXaXRoIE9nZyBPcHVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDMKICAgICAzLjEuICBDaGFubmVsIE1hcHBpbmcgRmFtaWx5IDIgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMy4yLiAgQ2hhbm5lbCBNYXBwaW5nIEZhbWls eSAzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICA0LiAgRG93bm1peGlu ZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUK ICAgNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA2CiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICA3LiAgQWNrbm93bGVkZ21lbnRzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgOC4gIFJl ZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA3CiAgICAgOC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgQXV0aG9ycycgQWRkcmVz c2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4Cgox LiAgSW50cm9kdWN0aW9uCgogICBBbWJpc29uaWNzIGlzIGEgcmVwcmVzZW50YXRpb24gZm9ybWF0 IGZvciB0aHJlZSBkaW1lbnNpb25hbCBzb3VuZAogICBmaWVsZHMgd2hpY2ggY2FuIGJlIHVzZWQg Zm9yIHN1cnJvdW5kIHNvdW5kIGFuZCBpbW1lcnNpdmUgdmlydHVhbAogICByZWFsaXR5IHBsYXli YWNrLiAgU2VlIFtnZXJ6b243NV0gYW5kIFtkYW5pZWwwNF0gZm9yIHRlY2huaWNhbAogICBkZXRh aWxzIG9uIHRoZSBhbWJpc29uaWNzIGZvcm1hdC4gIEZvciB0aGUgcHVycG9zZXMgb2YgdGhpcyBk b2N1bWVudCwKICAgYW1iaXNvbmljcyBjYW4gYmUgY29uc2lkZXJlZCBhIG11bHRpY2hhbm5lbCBh dWRpbyBzdHJlYW0uICBBIHNlcGFyYXRlCiAgIHN0ZXJlbyBzdHJlYW0gY2FuIGJlIHVzZWQgYWxv bmdzaWRlIHRoZSBhbWJpc29uaWNzIGluIGEgaGVhZC10cmFja2VkCiAgIHZpcnR1YWwgcmVhbGl0 eSBleHBlcmllbmNlIHRvIHByb3ZpZGUgc28tY2FsbGVkIG5vbi1kaWVnZXRpYyBhdWRpbyAtCiAg IGF1ZGlvIHdoaWNoIHNob3VsZCByZW1haW4gdW5jaGFuZ2VkIGJ5IGxpc3RlbmVyIGhlYWQgcm90 YXRpb247IGUuZy4sCiAgIG5hcnJhdGlvbiBvciBzdGVyZW8gbXVzaWMuICBPZ2cgaXMgYSBnZW5l cmFsIHB1cnBvc2UgY29udGFpbmVyLAogICBzdXBwb3J0aW5nIGF1ZGlvLCB2aWRlbywgYW5kIG90 aGVyIG1lZGlhLiAgSXQgY2FuIGJlIHVzZWQgdG8KICAgZW5jYXBzdWxhdGUgYXVkaW8gc3RyZWFt cyBjb2RlZCB1c2luZyB0aGUgT3B1cyBjb2RlYy4gIFNlZSBbUkZDNjcxNl0KICAgYW5kIFtSRkM3 ODQ1XSBmb3IgdGVjaG5pY2FsIGRldGFpbHMgb24gdGhlIE9wdXMgY29kZWMgYW5kIGl0cwogICBl bmNhcHN1bGF0aW9uIGluIHRoZSBPZ2cgY29udGFpbmVyIHJlc3BlY3RpdmVseS4KCiAgIFRoaXMg ZG9jdW1lbnQgZXh0ZW5kcyB0aGUgT2dnIGZvcm1hdCBieSBkZWZpbmluZyB0d28gbmV3IGNoYW5u ZWwKICAgbWFwcGluZyBmYW1pbGllcyBmb3IgZW5jb2RpbmcgYW1iaXNvbmljcy4gIFRoZSBPZ2cg T3B1cyBmb3JtYXQgaXMKICAgZXh0ZW5kZWQgaW5kaXJlY3RseSBieSBhZGRpbmcgYW4gaXRlbSB3 aXRoIHZhbHVlIDIgb3IgMyB0byB0aGUgSUFOQQogICAiT3B1cyBDaGFubmVsIE1hcHBpbmcgRmFt aWxpZXMiIHJlZ2lzdHJ5LiAgV2hlbiAyIG9yIDMgYXJlIHVzZWQgYXMKICAgdGhlIENoYW5uZWwg TWFwcGluZyBGYW1pbHkgTnVtYmVyIGluIGFuIE9nZyBzdHJlYW0sIHRoZSBzZW1hbnRpYwogICBt ZWFuaW5nIG9mIHRoZSBjaGFubmVscyBpbiB0aGUgbXVsdGljaGFubmVsIE9wdXMgc3RyZWFtIGlz IG9uZSBvZiB0aGUKICAgYW1iaXNvbmljcyBsYXlvdXRzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dC4gIFRoaXMgbWFwcGluZyBjYW4gYWxzbwogICBiZSB1c2VkIGluIG90aGVyIGNvbnRleHRzIHdo aWNoIG1ha2UgdXNlIG9mIHRoZSBjaGFubmVsIG1hcHBpbmdzCiAgIGRlZmluZWQgYnkgdGhlIE9w dXMgQ2hhbm5lbCBNYXBwaW5nIEZhbWlsaWVzIHJlZ2lzdHJ5LgoKMi4gIFRlcm1pbm9sb2d5Cgog ICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwg IlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJO T1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kCiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVu dCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluCiAgIFtSRkMyMTE5XS4KCgoK U2tvZ2x1bmQgJiBHcmFjenlrICAgICBFeHBpcmVzIFNlcHRlbWJlciAxOCwgMjAxNyAgICAgICAg ICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBPcHVzIEFtYmlz b25pY3MgICAgICAgICAgICAgICAgICBNYXJjaCAyMDE3CgoKMy4gIEFtYmlzb25pY3MgV2l0aCBP Z2cgT3B1cwoKICAgQW1iaXNvbmljcyBjYW4gYmUgZW5jYXBzdWxhdGVkIGluIHRoZSBPZ2cgZm9y bWF0IGJ5IGVuY29kaW5nIHdpdGggdGhlCiAgIE9wdXMgY29kZWMgYW5kIHNldHRpbmcgdGhlIGNo YW5uZWwgbWFwcGluZyBmYW1pbHkgdmFsdWUgdG8gMiBvciAzIGluCiAgIHRoZSBPZ2cgaWRlbnRp ZmljYXRpb24gaGVhZGVyIChJRCkuICBBIGRlbXV4ZXIgaW1wbGVtZW50YXRpb24KICAgZW5jb3Vu dGVyaW5nIENoYW5uZWwgTWFwcGluZyBGYW1pbHkgMiBvciBGYW1pbHkgMyBNVVNUIGludGVycHJl dCB0aGUKICAgT3B1cyBzdHJlYW0gYXMgY29udGFpbmluZyBhbWJpc29uaWNzIHdpdGggdGhlIGZv cm1hdCBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiAzLjEgb3IgU2VjdGlvbiAzLjIsIHJlc3BlY3Rp dmVseS4KCjMuMS4gIENoYW5uZWwgTWFwcGluZyBGYW1pbHkgMgoKICAgQWxsb3dlZCBudW1iZXJz IG9mIGNoYW5uZWxzOiAoMSArIG4pXjIgKyAyaiBmb3IgbiA9IDAuLi4xNCBhbmQgaiA9IDAKICAg b3IgMSwgd2hlcmUgbiBkZW5vdGVzIHRoZSAoaGlnaGVzdCkgYW1iaXNvbmljIG9yZGVyIGFuZCBq IHdoZXRoZXIgb3IKICAgbm90IHRoZXJlIGlzIGEgc2VwYXJhdGUgbm9uLWRpZWdldGljIHN0ZXJl byBzdHJlYW0uICBUaGlzIGNvcnJlc3BvbmRzCiAgIHRvIHBlcmlwaG9uaWMgYW1iaXNvbmljcyBm cm9tIHplcm90aCB0byBmb3VydGVlbnRoIG9yZGVyIHBsdXMKICAgcG90ZW50aWFsbHkgdHdvIGNo YW5uZWxzIG9mIG5vbi1kaWVnZXRpYyBzdGVyZW8uICBFeHBsaWNpdGx5IHRoZQogICBhbGxvd2Vk IG51bWJlciBvZiBjaGFubmVscyBhcmUgMSwgMywgNCwgNiwgOSwgMTEsIDE2LCAxOCwgMjUsIDI3 LCAzNiwKICAgMzgsIDQ5LCA1MSwgNjQsIDY2LCA4MSwgODMsIDEwMCwgMTAyLCAxMjEsIDEyMywg MTQ0LCAxNDYsIDE2OSwgMTcxLAogICAxOTYsIDE5OCwgMjI1LCAyMjcuCgogICBUaGlzIGNoYW5u ZWwgbWFwcGluZyB1c2VzIHRoZSBzYW1lIGNoYW5uZWwgbWFwcGluZyB0YWJsZSBmb3JtYXQgdXNl ZAogICBieSBjaGFubmVsIG1hcHBpbmcgZmFtaWx5IDEuICBUaGUgb3V0cHV0IGNoYW5uZWxzIGFy ZSBhbWJpc29uaWMKICAgY29tcG9uZW50cyBvcmRlcmVkIGluIEFtYmlzb25pYyBDaGFubmVsIE51 bWJlciAoQUNOKSBvcmRlciwgZGVmaW5lZAogICBpbiBGaWd1cmUgMSwgZm9sbG93ZWQgYnkgdHdv IG9wdGlvbmFsIGNoYW5uZWxzIG9mIG5vbi1kaWVnZXRpYyBzdGVyZW8KICAgaW5kZXhlZCAobGVm dCwgcmlnaHQpLgoKICAgICAgICAgICAgICAgICAgICAgICAgIEFDTiA9IG4gKiAobiArIDEpICsg bSwKICAgICAgICAgICAgICAgICAgICAgICAgIGZvciBvcmRlciBuIGFuZCBkZWdyZWUgbS4KCiAg ICAgICAgICAgICAgICAgRmlndXJlIDE6IEFtYmlzb25pYyBDaGFubmVsIE51bWJlciAoQUNOKQoK ICAgRm9yIHRoZSBhbWJpc29uaWMgY2hhbm5lbHMgdGhlIEFDTiBjb21wb25lbnQgY29ycmVzcG9u ZHMgdG8gY2hhbm5lbAogICBpbmRleCBhcyBrID0gQUNOLiAgVGhlIHJldmVyc2UgY29ycmVzcG9u ZGVuY2UgY2FuIGFsc28gYmUgY29tcHV0ZWQKICAgZm9yIGFuIGFtYmlzb25pYyBjaGFubmVsIHdp dGggaW5kZXggay4KCiAgICAgICAgICAgICAgICAgICAgICAgb3JkZXIgICBuID0gZmxvb3Ioc3Fy dChrKSksCiAgICAgICAgICAgICAgICAgICAgICAgZGVncmVlICBtID0gayAtIG4gKiAobiArIDEp LgoKICAgICAgICAgICAgICAgRmlndXJlIDI6IEFtYmlzb25pYyBEZWdyZWUgYW5kIE9yZGVyIGZy b20gQUNOCgogICBOb3RlIHRoYXQgY2hhbm5lbCBtYXBwaW5nIGZhbWlseSAyIGFsbG93cyBmb3Ig c28tY2FsbGVkIG1peGVkIG9yZGVyCiAgIGFtYmlzb25pYyByZXByZXNlbnRhdGlvbnMgd2hlcmUg b25seSBhIHN1YnNldCBvZiB0aGUgZnVsbCBhbWJpc29uaWMKICAgb3JkZXIgbnVtYmVyIG9mIGNo YW5uZWxzIGlzIHVzZWQuICBCeSBzcGVjaWZ5aW5nIHRoZSBmdWxsIG51bWJlciBpbgogICB0aGUg Y2hhbm5lbCBjb3VudCBmaWVsZCwgdGhlIGluYWN0aXZlIEFDTnMgY2FuIHRoZW4gYmUgaW5kaWNh dGVkIGluCiAgIHRoZSBjaGFubmVsIG1hcHBpbmcgZmllbGQgdXNpbmcgdGhlIGluZGV4IDI1NS4K CiAgIEFtYmlzb25pYyBjaGFubmVscyBhcmUgZXhwZWN0ZWQgdG8gYmUgbm9ybWFsaXplZCB3aXRo IFNjaG1pZHQgU2VtaS0KICAgTm9ybWFsaXphdGlvbiAoU04zRCkuICBUaGUgaW50ZXJwcmV0YXRp b24gb2YgdGhlIGFtYmlzb25pY3Mgc2lnbmFsIGFzCgoKClNrb2dsdW5kICYgR3JhY3p5ayAgICAg RXhwaXJlcyBTZXB0ZW1iZXIgMTgsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgT3B1cyBBbWJpc29uaWNzICAgICAgICAgICAgICAgICAg TWFyY2ggMjAxNwoKCiAgIHdlbGwgYXMgZGV0YWlsZWQgZGVmaW5pdGlvbnMgb2YgQUNOIGNoYW5u ZWwgb3JkZXJpbmcgYW5kIFNOM0QKICAgbm9ybWFsaXphdGlvbiBhcmUgZGVzY3JpYmVkIGluIFth bWJpeF0gU2VjdGlvbiAyLjEuCgozLjIuICBDaGFubmVsIE1hcHBpbmcgRmFtaWx5IDMKCiAgIEFs bG93ZWQgbnVtYmVycyBvZiBjaGFubmVsczogKDEgKyBuKV4yICsgMmogZm9yIG4gPSAwLi4uMTIg YW5kIGogPSAwCiAgIG9yIDEsIHdoZXJlIG4gZGVub3RlcyB0aGUgKGhpZ2hlc3QpIGFtYmlzb25p YyBvcmRlciBhbmQgaiB3aGV0aGVyIG9yCiAgIG5vdCB0aGVyZSBpcyBhIHNlcGFyYXRlIG5vbi1k aWVnZXRpYyBzdGVyZW8gc3RyZWFtLiAgVGhpcyBjb3JyZXNwb25kcwogICB0byBwZXJpcGhvbmlj IGFtYmlzb25pY3MgZnJvbSB6ZXJvdGggdG8gdHdlbGZ0aCBvcmRlciBwbHVzCiAgIHBvdGVudGlh bGx5IHR3byBjaGFubmVscyBvZiBub24tZGllZ2V0aWMgc3RlcmVvLiAgRXhwbGljaXRseSB0aGUK ICAgYWxsb3dlZCBudW1iZXIgb2YgY2hhbm5lbHMgYXJlIDEsIDMsIDQsIDYsIDksIDExLCAxNiwg MTgsIDI1LCAyNywgMzYsCiAgIDM4LCA0OSwgNTEsIDY0LCA2NiwgODEsIDgzLCAxMDAsIDEwMiwg MTIxLCAxMjMsIDE0NCwgMTQ2LCAxNjksIDE3MS4KCiAgIEluIHRoaXMgbWFwcGluZywgQyBvdXRw dXQgY2hhbm5lbHMgKHRoZSBjaGFubmVsIGNvdW50KSBhcmUgZ2VuZXJhdGVkCiAgIGF0IHRoZSBk ZWNvZGVyIGJ5IG11bHRpcGx5aW5nIEsgPSBOICsgTSBkZWNvZGVkIGNoYW5uZWxzIHdpdGggYQog ICBkZXNpZ25hdGVkIGRlbWl4aW5nIG1hdHJpeCwgRCwgaGF2aW5nIEMgcm93cyBhbmQgSyBjb2x1 bW5zLiAgSGVyZSwgTgogICBkZW5vdGVzIHRoZSBudW1iZXIgb2Ygc3RyZWFtcyBlbmNvZGVkIGFu ZCBNIHRoZSBudW1iZXIgb2YgdGhlc2Ugd2hpY2gKICAgYXJlIGNvdXBsZWQgdG8gcHJvZHVjZSB0 d28gY2hhbm5lbHMuICBBcyBmb3IgY2hhbm5lbCBtYXBwaW5nIGZhbWlseSAyCiAgIHRoaXMgbWFw cGluZyBmYW1pbHkgYWxzbyBhbGxvd3MgZm9yIGVuY29kaW5nIGFuZCBkZWNvZGluZyBvZiBmdWxs CiAgIG9yZGVyIGFtYmlzb25pY3MsIG1peGVkIG9yZGVyIGFtYmlzb25pY3MsIGFuZCBmb3Igbm9u LWRpZWdldGljIHN0ZXJlbwogICBjaGFubmVscywgYnV0IGFsc28gaGFzIHRoZSBhZGRlZCBmbGV4 aWJpbGl0eSBvZiBtaXhpbmcgY2hhbm5lbHMuICBMZXQKICAgWCBkZW5vdGUgYSBjb2x1bW4gdmVj dG9yIGNvbnRhaW5pbmcgSyBkZWNvZGVkIGNoYW5uZWxzIFgxLCBYMiwgLi4uLAogICBYSyAoZnJv bSBOIHN0cmVhbXMpLCBhbmQgbGV0IFMgZGVub3RlIGEgY29sdW1uIHZlY3RvciBjb250YWluaW5n IEMKICAgb3V0cHV0IHN0cmVhbXMgUzEsIFMyLCAuLi4sIFNDLiAgVGhlbiBTID0gRCBYLCBpLmUu LAoKICAgICAgICAgICAgICAgICAgLyAgICAgXCAgIC8gICAgICAgICAgICAgICAgICAgXCAvICAg ICBcCiAgICAgICAgICAgICAgICAgIHwgUzEgIHwgICB8IEQxMSAgRDEyICAuLi4gRDFLIHwgfCBY MSAgfAogICAgICAgICAgICAgICAgICB8IFMyICB8ICAgfCBEMjEgIEQyMiAgLi4uIEQySyB8IHwg WDIgIHwKICAgICAgICAgICAgICAgICAgfCAuLi4gfCA9IHwgLi4uICAuLi4gIC4uLiAuLi4gfCB8 IC4uLiB8CiAgICAgICAgICAgICAgICAgIHwgU0MgIHwgICB8IERDMSAgREMyICAuLi4gRENLIHwg fCBYSyAgfAogICAgICAgICAgICAgICAgICBcICAgICAvICAgXCAgICAgICAgICAgICAgICAgICAv IFwgICAgIC8KCiAgICAgICAgICAgICAgRmlndXJlIDM6IERlbWl4aW5nIGluIENoYW5uZWwgTWFw cGluZyBGYW1pbHkgMwoKICAgVGhlIG1hdHJpeCBNVVNUIGJlIHByb3ZpZGVkIGFzIHNpZGUgaW5m b3JtYXRpb24gYW5kIE1VU1QgYmUgc3RvcmVkIGluCiAgIHRoZSBjaGFubmVsIG1hcHBpbmcgdGFi bGUgcGFydCBvZiB0aGUgaWRlbnRpZmljYXRpb24gaGVhZGVyLCBjLmYuCiAgIHNlY3Rpb24gNS4x LjEgaW4gW1JGQzc4NDVdLiAgVGhlIG1hdHJpeCByZXBsYWNlcyB0aGUgbmVlZCBmb3IgYQogICBj aGFubmVsIG1hcHBpbmcgZmllbGQgYW5kIGZvciBjaGFubmVsIG1hcHBpbmcgZmFtaWx5IDMgdGhl IG1hcHBpbmcKICAgdGFibGUgaGFzIHRoZSBmb2xsb3dpbmcgbGF5b3V0OgoKCgoKCgoKCgoKCgpT a29nbHVuZCAmIEdyYWN6eWsgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE4LCAyMDE3ICAgICAgICAg ICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIE9wdXMgQW1iaXNv bmljcyAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTcKCgogICAgICAwICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAgIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst Ky0rLSstKy0rLSstKy0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCBTdHJlYW0gQ291bnQgIHwKICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgIHwgQ291cGxl ZCBDb3VudCB8IERlbWl4aW5nIE1hdHJpeCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6 CiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsKCgogICAgICAgRmlndXJlIDQ6IENoYW5uZWwgTWFwcGluZyBUYWJsZSBm b3IgQ2hhbm5lbCBNYXBwaW5nIEZhbWlseSAzCgogICBUaGUgZmllbGRzIGluIHRoZSBjaGFubmVs IG1hcHBpbmcgdGFibGUgaGF2ZSB0aGUgZm9sbG93aW5nIG1lYW5pbmc6CgogICAxLiAgU3RyZWFt IENvdW50ICdOJyAoOCBiaXRzLCB1bnNpZ25lZCk6CgogICAgICAgVGhpcyBpcyB0aGUgdG90YWwg bnVtYmVyIG9mIHN0cmVhbXMgZW5jb2RlZCBpbiBlYWNoIE9nZyBwYWNrZXQuCgoKCiAgIDIuICBD b3VwbGVkIFN0cmVhbSBDb3VudCAnTScgKDggYml0cywgdW5zaWduZWQpOgoKICAgICAgIFRoaXMg aXMgdGhlIG51bWJlciBvZiB0aGUgTiBzdHJlYW1zIHdob3NlIGRlY29kZXJzIGFyZSB0byBiZQog ICAgICAgY29uZmlndXJlZCB0byBwcm9kdWNlIHR3byBjaGFubmVscyAoc3RlcmVvKS4KCgoKICAg My4gIERlbWl4aW5nIE1hdHJpeCAoMTYqSypDIGJpdHMsIHNpZ25lZCk6CgogICAgICAgVGhlIGNv ZWZmaWNpZW50cyBvZiB0aGUgZGVtaXhpbmcgbWF0cml4IHN0b3JlZCBjb2x1bW4td2lzZSBhcwog ICAgICAgMTYtYml0LCBzaWduZWQsIHR3bydzIGNvbXBsZW1lbnQgZml4ZWQtcG9pbnQgdmFsdWVz IHdpdGggMTUKICAgICAgIGZyYWN0aW9uYWwgYml0cyAoUTE1KS4gIElmIG5lZWRlZCwgdGhlIG91 dHB1dCBnYWluIGZpZWxkIGNhbiBiZQogICAgICAgdXNlZCBmb3IgYSBub3JtYWxpemF0aW9uIHNj YWxlLiAgRm9yIG1peGVkIG9yZGVyIGFtYmlzb25pYwogICAgICAgcmVwcmVzZW50YXRpb25zLCB0 aGUgc2lsZW50IEFDTiBjaGFubmVscyBhcmUgaW5kaWNhdGVkIGJ5IGFsbAogICAgICAgemVyb3Mg aW4gdGhlIGNvcnJlc3BvbmRpbmcgcm93cyBvZiB0aGUgZGVtaXhpbmcgbWF0cml4LgoKICAgTm90 ZSB0aGF0IFtSRkM3ODQ1XSBzcGVjaWZpZXMgdGhhdCB0aGUgaWRlbnRpZmljYXRpb24gaGVhZGVy IGNhbm5vdAogICBleGNlZWQgb25lICJwYWdlIiwgd2hpY2ggaXMgNjUsMDI1IG9jdGV0cy4gIFRo aXMgbGltaXRzIHRoZSBhbWJpc29uaWMKICAgb3JkZXIgdG8gYmUgbG93ZXIgdGhhbiAxMi4gIEFs c28gbm90ZSB0aGF0IHRoZSB0b3RhbCBvdXRwdXQgY2hhbm5lbAogICBudW1iZXIsIEMsIE1VU1Qg YmUgc2V0IGluIHRoZSAzcmQgZmllbGQgb2YgdGhlIGlkZW50aWZpY2F0aW9uIGhlYWRlci4KCjQu ICBEb3dubWl4aW5nCgogICBBbiBPZ2cgT3B1cyBwbGF5ZXIgTUFZIHVzZSB0aGUgbWF0cml4IGlu IEZpZ3VyZSA1IHRvIGltcGxlbWVudAogICBkb3dubWl4aW5nIGZyb20gbXVsdGljaGFubmVsIGZp bGVzIHVzaW5nIGNoYW5uZWwgbWFwcGluZyBmYW1pbHkgMiBhbmQKICAgMywgd2hlbiB0aGVyZSBp cyBubyBub24tZGllZ2V0aWMgc3RlcmVvLiAgVGhpcyBkb3dubWl4aW5nIGlzIGtub3duIHRvCiAg IGdpdmUgYWNjZXB0YWJsZSByZXN1bHRzIGZvciBzdGVyZW8gZG93bm1peGluZyBmcm9tIGFtYmlz b25pY3MuICBUaGUKICAgZmlyc3QgYW5kIHNlY29uZCBhbWJpc29uaWMgY2hhbm5lbHMgYXJlIGtu b3duIGFzICJXIiBhbmQgIlkiCiAgIHJlc3BlY3RpdmVseS4KCgoKU2tvZ2x1bmQgJiBHcmFjenlr ICAgICBFeHBpcmVzIFNlcHRlbWJlciAxOCwgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDVdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBPcHVzIEFtYmlzb25pY3MgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDE3CgoKICAgICAgICAgICAgICAgICAgIC8gICBcICAgLyAgICAgICAgICAg ICAgICAgIFwgLyAgICAgXAogICAgICAgICAgICAgICAgICAgfCBMIHwgICB8IDAuNSAgMC41IDAu MCAuLi4gfCB8ICBXICB8CiAgICAgICAgICAgICAgICAgICB8IFIgfCA9IHwgMC41IC0wLjUgMC4w IC4uLiB8IHwgIFkgIHwKICAgICAgICAgICAgICAgICAgIFwgICAvICAgXCAgICAgICAgICAgICAg ICAgIC8gfCAuLi4gfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBcICAgICAvCgogICBGaWd1cmUgNTogU3RlcmVvIERvd25taXhpbmcgTWF0cml4IGZvciBD aGFubmVsIE1hcHBpbmcgRmFtaWx5IDIgYW5kIDMKICAgICAgICAgICAgICAgICAgICAgICAgIC0g b25seSBBbWJpc29uaWMgQ2hhbm5lbHMKCiAgIFRoZSBmaXJzdCBhbWJpc29uaWMgY2hhbm5lbCAo VykgaXMgYSBtb25vIGF1ZGlvIHN0cmVhbSB3aGljaAogICByZXByZXNlbnRzIHRoZSBhdmVyYWdl IGF1ZGlvIHNpZ25hbCBvdmVyIGFsbCBkaXJlY3Rpb25zLiAgU2luY2UgVyBpcwogICBub3QgZGly ZWN0aW9uYWwsIE9nZyBPcHVzIHBsYXllcnMgTUFZIHVzZSBXIGRpcmVjdGx5IGZvciBtb25vCiAg IHBsYXliYWNrLgoKICAgSWYgYSBub24tZGllZ2V0aWMgc3RlcmVvIHRyYWNrIGlzIHByZXNlbnQs IHRoZSBwbGF5ZXIgTUFZIHVzZSB0aGUKICAgbWF0cml4IGluIEZpZ3VyZSA2IGZvciBkb3dubWl4 aW5nLiAgTHMgYW5kIFJzIGRlbm90ZSB0aGUgdHdvIG5vbi0KICAgZGllZ2V0aWMgc3RlcmVvIGNo YW5uZWxzLgoKICAgICAgICAgICAgICAvICAgXCAgIC8gICAgICAgICAgICAgICAgICAgICAgICAg ICAgXCAgLyAgICAgXAogICAgICAgICAgICAgIHwgTCB8ICAgfCAwLjI1ICAwLjI1IDAuMCAuLi4g MC41IDAuMCB8ICB8ICBXICB8CiAgICAgICAgICAgICAgfCBSIHwgPSB8IDAuMjUgLTAuMjUgMC4w IC4uLiAwLjAgMC41IHwgIHwgIFkgIHwKICAgICAgICAgICAgICBcICAgLyAgIFwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLyAgfCAuLi4gfAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBMcyB8CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFJzIHwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgLwoKICAgRmlndXJlIDY6 IFN0ZXJlbyBEb3dubWl4aW5nIE1hdHJpeCBmb3IgQ2hhbm5lbCBNYXBwaW5nIEZhbWlseSAyIGFu ZCAzCiAgICAgICAgICAtIEFtYmlzb25pYyBDaGFubmVscyBQbHVzIGEgTm9uLWRpZWdldGljIFN0 ZXJlbyBTdHJlYW0KCjUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgSW1wbGVtZW50YXRp b25zIG9mIHRoZSBPZ2cgY29udGFpbmVyIG5lZWQgdGFrZSBhcHByb3ByaWF0ZSBzZWN1cml0eQog ICBjb25zaWRlcmF0aW9ucyBpbnRvIGFjY291bnQsIGFzIG91dGxpbmVkIGluIFNlY3Rpb24gMTAg b2YgW1JGQzc4NDVdLgogICBUaGUgZXh0ZW5zaW9uIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBy ZXF1aXJlcyB0aGF0IHNlbWFudGljIG1lYW5pbmcKICAgYmUgYXNzaWduZWQgdG8gbW9yZSBjaGFu bmVscyB0aGFuIHRoZSBleGlzdGluZyBPZ2cgZm9ybWF0IHJlcXVpcmVzLgogICBTaW5jZSBtb3Jl IGFsbG9jYXRpb25zIHdpbGwgYmUgcmVxdWlyZWQgdG8gZW5jb2RlIGFuZCBkZWNvZGUgdGhlc2UK ICAgc2VtYW50aWNhbGx5IG1lYW5pbmdmdWwgY2hhbm5lbHMsIGNhcmUgc2hvdWxkIGJlIHRha2Vu IGluIGFueSBuZXcKICAgYWxsb2NhdGlvbiBwYXRocy4gIEltcGxlbWVudGF0aW9ucyBNVVNUIE5P VCBvdmVycnVuIHRoZWlyIGFsbG9jYXRlZAogICBtZW1vcnkgbm9yIHJlYWQgZnJvbSB1bmluaXRp YWxpemVkIG1lbW9yeSB3aGVuIG1hbmFnaW5nIHRoZSBhbWJpc29uaWMKICAgY2hhbm5lbCBtYXBw aW5nLgoKNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0 aGUgSUFOQSBNZWRpYSBUeXBlcyByZWdpc3RyeSAiT3B1cyBDaGFubmVsCiAgIE1hcHBpbmcgRmFt aWxpZXMiIHRvIGFkZCB0d28gbmV3IGFzc2lnbm1lbnRzLgoKCgoKCgpTa29nbHVuZCAmIEdyYWN6 eWsgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE4LCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgNl0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIE9wdXMgQW1iaXNvbmljcyAgICAgICAgICAg ICAgICAgIE1hcmNoIDIwMTcKCgogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgfCBWYWx1ZSB8IFJlZmVyZW5j ZSAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgfCAyICAgICB8IFRoaXMgRG9j dW1lbnQgU2VjdGlvbiAzLjEgfAogICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgfCAzICAgICB8IFRoaXMgRG9j dW1lbnQgU2VjdGlvbiAzLjIgfAogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwoKNy4gIEFja25vd2xlZGdtZW50cwoKICAgVGhhbmtzIHRvIFRp bW90aHkgVGVycmliZXJyeSwgSmVhbi1NYXJjIFZhbGluLCBNYXJrIEhhcnJpcywgTWFyY2luCiAg IEdvcnplbCBhbmQgQW5kcmV3IEFsbGVuIGZvciB0aGVpciBndWlkYW5jZSBhbmQgdmFsdWFibGUg Y29udHJpYnV0aW9ucwogICB0byB0aGlzIGRvY3VtZW50LgoKOC4gIFJlZmVyZW5jZXMKCjguMS4g IE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdv cmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50 IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JG QzIxMTksIE1hcmNoIDE5OTcsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvaW5mby9yZmMyMTE5Pi4KCiAgIFtSRkM2NzE2XSAgVmFsaW4sIEpNLiwgVm9zLCBLLiwgYW5k IFQuIFRlcnJpYmVycnksICJEZWZpbml0aW9uIG9mIHRoZQogICAgICAgICAgICAgIE9wdXMgQXVk aW8gQ29kZWMiLCBSRkMgNjcxNiwgRE9JIDEwLjE3NDg3L1JGQzY3MTYsCiAgICAgICAgICAgICAg U2VwdGVtYmVyIDIwMTIsIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjcxNj4u CgogICBbUkZDNzg0NV0gIFRlcnJpYmVycnksIFQuLCBMZWUsIFIuLCBhbmQgUi4gR2lsZXMsICJP Z2cgRW5jYXBzdWxhdGlvbgogICAgICAgICAgICAgIGZvciB0aGUgT3B1cyBBdWRpbyBDb2RlYyIs IFJGQyA3ODQ1LCBET0kgMTAuMTc0ODcvUkZDNzg0NSwKICAgICAgICAgICAgICBBcHJpbCAyMDE2 LCA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc4NDU+LgoKICAgW2FtYml4XSAg ICBOYWNoYmFyLCBDLiwgWm90dGVyLCBGLiwgRGVsZWZsaWUsIEUuLCBhbmQgQS4gU29udGFjY2hp LAogICAgICAgICAgICAgICJBTUJJWCAtIEEgU1VHR0VTVEVEIEFNQklTT05JQ1MgRk9STUFUIiwg SnVuZSAyMDExLAogICAgICAgICAgICAgIDxodHRwOi8vaWVtLmt1Zy5hYy5hdC9maWxlYWRtaW4v bWVkaWEvaWVtL3Byb2plY3RzLzIwMTEvCiAgICAgICAgICAgICAgYW1iaXNvbmljczExX25hY2hi YXJfem90dGVyX3NvbnRhY2NoaV9kZWxlZmxpZS5wZGY+LgoKOC4yLiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcwoKICAgW2dlcnpvbjc1XQogICAgICAgICAgICAgIEdlcnpvbiwgTS4sICJBbWJpc29u aWNzLiBQYXJ0IG9uZTogR2VuZXJhbCBzeXN0ZW0KICAgICAgICAgICAgICBkZXNjcmlwdGlvbiIs IEF1Z3VzdCAxOTc1LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3Lm1pY2hhZWxnZXJ6b25waG90 b3Mub3JnLnVrL2FydGljbGVzLwogICAgICAgICAgICAgIEFtYmlzb25pY3MlMjAxLnBkZj4uCgoK CgoKCgoKU2tvZ2x1bmQgJiBHcmFjenlrICAgICBFeHBpcmVzIFNlcHRlbWJlciAxOCwgMjAxNyAg ICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBPcHVz IEFtYmlzb25pY3MgICAgICAgICAgICAgICAgICBNYXJjaCAyMDE3CgoKICAgW2RhbmllbDA0XQog ICAgICAgICAgICAgIERhbmllbCwgSi4gYW5kIFMuIE1vcmVhdSwgIkZ1cnRoZXIgU3R1ZHkgb2Yg U291bmQgRmllbGQKICAgICAgICAgICAgICBDb2Rpbmcgd2l0aCBIaWdoZXIgT3JkZXIgQW1iaXNv bmljcyIsIE1heSAyMDA0LAogICAgICAgICAgICAgIDxodHRwOi8vcGNmYXJpbmEuZW5nLnVuaXBy Lml0L1B1YmxpYy9waGQtdGhlc2lzLwogICAgICAgICAgICAgIGFlczExNiUyMGhpZ2gtcGFzc2Vk JTIwaG9hLnBkZj4uCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIEphbiBTa29nbHVuZAogICBHb29n bGUgSW5jLgogICAxNjAwIEFtcGhpdGhlYXRyZSBQYXJrd2F5CiAgIE1vdW50YWluIFZpZXcsIENB ICA5NDA0MwogICBVU0EKCiAgIEVtYWlsOiBqa3NAZ29vZ2xlLmNvbQoKCiAgIE1pY2hhZWwgR3Jh Y3p5awogICBHb29nbGUgSW5jLgogICAxNjAwIEFtcGhpdGhlYXRyZSBQYXJrd2F5CiAgIE1vdW50 YWluIFZpZXcsIENBICA5NDA0MwogICBVU0EKCiAgIEVtYWlsOiBtZ3JhY3p5a0Bnb29nbGUuY29t CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClNrb2dsdW5kICYgR3JhY3p5ayAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMTgsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSA4XQo= --94eb2c08340c00420d054b6c0d63 Content-Type: text/html; charset=US-ASCII; name="draft-ietf-codec-ambisonics-02.html" Content-Disposition: attachment; filename="draft-ietf-codec-ambisonics-02.html" Content-Transfer-Encoding: base64 Content-ID: <15af7f78d2d96d7e88e2> X-Attachment-Id: 15af7f78d2d96d7e88e2 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3RyaWN0Ly9FTiIg CiAgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXN0cmljdC5kdGQiPgoK PGh0bWwgbGFuZz0iZW4iIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWw6 bGFuZz0iZW4iPgo8aGVhZCBwcm9maWxlPSJodHRwOi8vd3d3LnczLm9yZy8yMDA2LzAzL2hjYXJk IGh0dHA6Ly9kdWJsaW5jb3JlLm9yZy9kb2N1bWVudHMvMjAwOC8wOC8wNC9kYy1odG1sLyI+CiAg PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXMtYXNjaWkiIC8+CgogIDx0aXRsZT5BbWJpc29uaWNzIGluIGFuIE9nZyBPcHVzIENvbnRh aW5lcjwvdGl0bGU+CgogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgdGl0bGU9IlhtbDJSZmMgKHNh bnMgc2VyaWYpIj4KICAvKjwhW0NEQVRBWyovCgkgIGEgewoJICB0ZXh0LWRlY29yYXRpb246IG5v bmU7CgkgIH0KICAgICAgLyogaW5mbyBjb2RlIGZyb20gU2FudGFLbGF1c3MgYXQgaHR0cDovL3d3 dy5tYWRhYm91dHN0eWxlLmNvbS90b29sdGlwMi5odG1sICovCiAgICAgIGEuaW5mbyB7CiAgICAg ICAgICAvKiBUaGlzIGlzIHRoZSBrZXkuICovCiAgICAgICAgICBwb3NpdGlvbjogcmVsYXRpdmU7 CiAgICAgICAgICB6LWluZGV4OiAyNDsKICAgICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsK ICAgICAgfQogICAgICBhLmluZm86aG92ZXIgewogICAgICAgICAgei1pbmRleDogMjU7CiAgICAg ICAgICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogIzkwMDsKICAgICAgfQogICAgICBh LmluZm8gc3BhbiB7IGRpc3BsYXk6IG5vbmU7IH0KICAgICAgYS5pbmZvOmhvdmVyIHNwYW4uaW5m byB7CiAgICAgICAgICAvKiBUaGUgc3BhbiB3aWxsIGRpc3BsYXkganVzdCBvbiA6aG92ZXIgc3Rh dGUuICovCiAgICAgICAgICBkaXNwbGF5OiBibG9jazsKICAgICAgICAgIHBvc2l0aW9uOiBhYnNv bHV0ZTsKICAgICAgICAgIGZvbnQtc2l6ZTogc21hbGxlcjsKICAgICAgICAgIHRvcDogMmVtOyBs ZWZ0OiAtNWVtOyB3aWR0aDogMTVlbTsKICAgICAgICAgIHBhZGRpbmc6IDJweDsgYm9yZGVyOiAx cHggc29saWQgIzMzMzsKICAgICAgICAgIGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAj RUVFOwogICAgICAgICAgdGV4dC1hbGlnbjogbGVmdDsKICAgICAgfQoJICBhLnNtcGwgewoJICBj b2xvcjogYmxhY2s7CgkgIH0KCSAgYTpob3ZlciB7CgkgIHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOwoJICB9CgkgIGE6YWN0aXZlIHsKCSAgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Cgkg IH0KCSAgYWRkcmVzcyB7CgkgIG1hcmdpbi10b3A6IDFlbTsKCSAgbWFyZ2luLWxlZnQ6IDJlbTsK CSAgZm9udC1zdHlsZTogbm9ybWFsOwoJICB9CgkgIGJvZHkgewoJICBjb2xvcjogYmxhY2s7Cgkg IGZvbnQtZmFtaWx5OiB2ZXJkYW5hLCBoZWx2ZXRpY2EsIGFyaWFsLCBzYW5zLXNlcmlmOwoJICBm b250LXNpemU6IDEwcHQ7CgkgIG1heC13aWR0aDogNTVlbTsKCSAgCgkgIH0KCSAgY2l0ZSB7Cgkg IGZvbnQtc3R5bGU6IG5vcm1hbDsKCSAgfQoJICBkZCB7CgkgIG1hcmdpbi1yaWdodDogMmVtOwoJ ICB9CgkgIGRsIHsKCSAgbWFyZ2luLWxlZnQ6IDJlbTsKCSAgfQoJCgkgIHVsLmVtcHR5IHsKCSAg bGlzdC1zdHlsZS10eXBlOiBub25lOwoJICB9CgkgIHVsLmVtcHR5IGxpIHsKCSAgbWFyZ2luLXRv cDogLjVlbTsKCSAgfQoJICBkbCBwIHsKCSAgbWFyZ2luLWxlZnQ6IDBlbTsKCSAgfQoJICBkdCB7 CgkgIG1hcmdpbi10b3A6IC41ZW07CgkgIH0KCSAgaDEgewoJICBmb250LXNpemU6IDE0cHQ7Cgkg IGxpbmUtaGVpZ2h0OiAyMXB0OwoJICBwYWdlLWJyZWFrLWFmdGVyOiBhdm9pZDsKCSAgfQoJICBo MS5ucCB7CgkgIHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7CgkgIH0KCSAgaDEgYSB7CgkgIGNv bG9yOiAjMzMzMzMzOwoJICB9CgkgIGgyIHsKCSAgZm9udC1zaXplOiAxMnB0OwoJICBsaW5lLWhl aWdodDogMTVwdDsKCSAgcGFnZS1icmVhay1hZnRlcjogYXZvaWQ7CgkgIH0KCSAgaDMsIGg0LCBo NSwgaDYgewoJICBmb250LXNpemU6IDEwcHQ7CgkgIHBhZ2UtYnJlYWstYWZ0ZXI6IGF2b2lkOwoJ ICB9CgkgIGgyIGEsIGgzIGEsIGg0IGEsIGg1IGEsIGg2IGEgewoJICBjb2xvcjogYmxhY2s7Cgkg IH0KCSAgaW1nIHsKCSAgbWFyZ2luLWxlZnQ6IDNlbTsKCSAgfQoJICBsaSB7CgkgIG1hcmdpbi1s ZWZ0OiAyZW07CgkgIG1hcmdpbi1yaWdodDogMmVtOwoJICB9CgkgIG9sIHsKCSAgbWFyZ2luLWxl ZnQ6IDJlbTsKCSAgbWFyZ2luLXJpZ2h0OiAyZW07CgkgIH0KCSAgb2wgcCB7CgkgIG1hcmdpbi1s ZWZ0OiAwZW07CgkgIH0KCSAgcCB7CgkgIG1hcmdpbi1sZWZ0OiAyZW07CgkgIG1hcmdpbi1yaWdo dDogMmVtOwoJICB9CgkgIHByZSB7CgkgIG1hcmdpbi1sZWZ0OiAzZW07CgkgIGJhY2tncm91bmQt Y29sb3I6IGxpZ2h0eWVsbG93OwoJICBwYWRkaW5nOiAuMjVlbTsKCSAgfQoJICBwcmUudGV4dDIg ewoJICBib3JkZXItc3R5bGU6IGRvdHRlZDsKCSAgYm9yZGVyLXdpZHRoOiAxcHg7CgkgIGJhY2tn cm91bmQtY29sb3I6ICNmMGYwZjA7CgkgIHdpZHRoOiA2OWVtOwoJICB9CgkgIHByZS5pbmxpbmUg ewoJICBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsKCSAgcGFkZGluZzogMGVtOwoJICB9CgkgIHBy ZS50ZXh0IHsKCSAgYm9yZGVyLXN0eWxlOiBkb3R0ZWQ7CgkgIGJvcmRlci13aWR0aDogMXB4OwoJ ICBiYWNrZ3JvdW5kLWNvbG9yOiAjZjhmOGY4OwoJICB3aWR0aDogNjllbTsKCSAgfQoJICBwcmUu ZHJhd2luZyB7CgkgIGJvcmRlci1zdHlsZTogc29saWQ7CgkgIGJvcmRlci13aWR0aDogMXB4OwoJ ICBiYWNrZ3JvdW5kLWNvbG9yOiAjZjhmOGY4OwoJICBwYWRkaW5nOiAyZW07CgkgIH0KCSAgdGFi bGUgewoJICBtYXJnaW4tbGVmdDogMmVtOwoJICB9CgkgIHRhYmxlLnR0IHsKCSAgdmVydGljYWwt YWxpZ246IHRvcDsKCSAgfQoJICB0YWJsZS5mdWxsIHsKCSAgYm9yZGVyLXN0eWxlOiBvdXRzZXQ7 CgkgIGJvcmRlci13aWR0aDogMXB4OwoJICB9CgkgIHRhYmxlLmhlYWRlcnMgewoJICBib3JkZXIt c3R5bGU6IG91dHNldDsKCSAgYm9yZGVyLXdpZHRoOiAxcHg7CgkgIH0KCSAgdGFibGUudHQgdGQg ewoJICB2ZXJ0aWNhbC1hbGlnbjogdG9wOwoJICB9CgkgIHRhYmxlLmZ1bGwgdGQgewoJICBib3Jk ZXItc3R5bGU6IGluc2V0OwoJICBib3JkZXItd2lkdGg6IDFweDsKCSAgfQoJICB0YWJsZS50dCB0 aCB7CgkgIHZlcnRpY2FsLWFsaWduOiB0b3A7CgkgIH0KCSAgdGFibGUuZnVsbCB0aCB7CgkgIGJv cmRlci1zdHlsZTogaW5zZXQ7CgkgIGJvcmRlci13aWR0aDogMXB4OwoJICB9CgkgIHRhYmxlLmhl YWRlcnMgdGggewoJICBib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBpbnNldCBub25lOwoJICBib3Jk ZXItd2lkdGg6IDFweDsKCSAgfQoJICB0YWJsZS5sZWZ0IHsKCSAgbWFyZ2luLXJpZ2h0OiBhdXRv OwoJICB9CgkgIHRhYmxlLnJpZ2h0IHsKCSAgbWFyZ2luLWxlZnQ6IGF1dG87CgkgIH0KCSAgdGFi bGUuY2VudGVyIHsKCSAgbWFyZ2luLWxlZnQ6IGF1dG87CgkgIG1hcmdpbi1yaWdodDogYXV0bzsK CSAgfQoJICBjYXB0aW9uIHsKCSAgY2FwdGlvbi1zaWRlOiBib3R0b207CgkgIGZvbnQtd2VpZ2h0 OiBib2xkOwoJICBmb250LXNpemU6IDlwdDsKCSAgbWFyZ2luLXRvcDogLjVlbTsKCSAgfQoJCgkg IHRhYmxlLmhlYWRlciB7CgkgIGJvcmRlci1zcGFjaW5nOiAxcHg7CgkgIHdpZHRoOiA5NSU7Cgkg IGZvbnQtc2l6ZTogMTBwdDsKCSAgY29sb3I6IHdoaXRlOwoJICB9CgkgIHRkLnRvcCB7CgkgIHZl cnRpY2FsLWFsaWduOiB0b3A7CgkgIH0KCSAgdGQudG9wbm93cmFwIHsKCSAgdmVydGljYWwtYWxp Z246IHRvcDsKCSAgd2hpdGUtc3BhY2U6IG5vd3JhcDsgCgkgIH0KCSAgdGFibGUuaGVhZGVyIHRk IHsKCSAgYmFja2dyb3VuZC1jb2xvcjogZ3JheTsKCSAgd2lkdGg6IDUwJTsKCSAgfQoJICB0YWJs ZS5oZWFkZXIgYSB7CgkgIGNvbG9yOiB3aGl0ZTsKCSAgfQoJICB0ZC5yZWZlcmVuY2UgewoJICB2 ZXJ0aWNhbC1hbGlnbjogdG9wOwoJICB3aGl0ZS1zcGFjZTogbm93cmFwOwoJICBwYWRkaW5nLXJp Z2h0OiAxZW07CgkgIH0KCSAgdGhlYWQgewoJICBkaXNwbGF5OnRhYmxlLWhlYWRlci1ncm91cDsK CSAgfQoJICB1bC50b2MsIHVsLnRvYyB1bCB7CgkgIGxpc3Qtc3R5bGU6IG5vbmU7CgkgIG1hcmdp bi1sZWZ0OiAxLjVlbTsKCSAgbWFyZ2luLXJpZ2h0OiAwZW07CgkgIHBhZGRpbmctbGVmdDogMGVt OwoJICB9CgkgIHVsLnRvYyBsaSB7CgkgIGxpbmUtaGVpZ2h0OiAxNTAlOwoJICBmb250LXdlaWdo dDogYm9sZDsKCSAgZm9udC1zaXplOiAxMHB0OwoJICBtYXJnaW4tbGVmdDogMGVtOwoJICBtYXJn aW4tcmlnaHQ6IDBlbTsKCSAgfQoJICB1bC50b2MgbGkgbGkgewoJICBsaW5lLWhlaWdodDogbm9y bWFsOwoJICBmb250LXdlaWdodDogbm9ybWFsOwoJICBmb250LXNpemU6IDlwdDsKCSAgbWFyZ2lu LWxlZnQ6IDBlbTsKCSAgbWFyZ2luLXJpZ2h0OiAwZW07CgkgIH0KCSAgbGkuZXhjbHVkZWQgewoJ ICBmb250LXNpemU6IDBwdDsKCSAgfQoJICB1bCBwIHsKCSAgbWFyZ2luLWxlZnQ6IDBlbTsKCSAg fQoJCgkgIC5jb21tZW50IHsKCSAgYmFja2dyb3VuZC1jb2xvcjogeWVsbG93OwoJICB9CgkgIC5j ZW50ZXIgewoJICB0ZXh0LWFsaWduOiBjZW50ZXI7CgkgIH0KCSAgLmVycm9yIHsKCSAgY29sb3I6 IHJlZDsKCSAgZm9udC1zdHlsZTogaXRhbGljOwoJICBmb250LXdlaWdodDogYm9sZDsKCSAgfQoJ ICAuZmlndXJlIHsKCSAgZm9udC13ZWlnaHQ6IGJvbGQ7CgkgIHRleHQtYWxpZ246IGNlbnRlcjsK CSAgZm9udC1zaXplOiA5cHQ7CgkgIH0KCSAgLmZpbGVuYW1lIHsKCSAgY29sb3I6ICMzMzMzMzM7 CgkgIGZvbnQtd2VpZ2h0OiBib2xkOwoJICBmb250LXNpemU6IDEycHQ7CgkgIGxpbmUtaGVpZ2h0 OiAyMXB0OwoJICB0ZXh0LWFsaWduOiBjZW50ZXI7CgkgIH0KCSAgLmZuIHsKCSAgZm9udC13ZWln aHQ6IGJvbGQ7CgkgIH0KCSAgLmhpZGRlbiB7CgkgIGRpc3BsYXk6IG5vbmU7CgkgIH0KCSAgLmxl ZnQgewoJICB0ZXh0LWFsaWduOiBsZWZ0OwoJICB9CgkgIC5yaWdodCB7CgkgIHRleHQtYWxpZ246 IHJpZ2h0OwoJICB9CgkgIC50aXRsZSB7CgkgIGNvbG9yOiAjOTkwMDAwOwoJICBmb250LXNpemU6 IDE4cHQ7CgkgIGxpbmUtaGVpZ2h0OiAxOHB0OwoJICBmb250LXdlaWdodDogYm9sZDsKCSAgdGV4 dC1hbGlnbjogY2VudGVyOwoJICBtYXJnaW4tdG9wOiAzNnB0OwoJICB9CgkgIC52Y2FyZGxpbmUg ewoJICBkaXNwbGF5OiBibG9jazsKCSAgfQoJICAud2FybmluZyB7CgkgIGZvbnQtc2l6ZTogMTRw dDsKCSAgYmFja2dyb3VuZC1jb2xvcjogeWVsbG93OwoJICB9CgkKCQoJICBAbWVkaWEgcHJpbnQg ewoJICAubm9wcmludCB7CgkJZGlzcGxheTogbm9uZTsKCSAgfQoJCgkgIGEgewoJCWNvbG9yOiBi bGFjazsKCQl0ZXh0LWRlY29yYXRpb246IG5vbmU7CgkgIH0KCQoJICB0YWJsZS5oZWFkZXIgewoJ CXdpZHRoOiA5MCU7CgkgIH0KCQoJICB0ZC5oZWFkZXIgewoJCXdpZHRoOiA1MCU7CgkJY29sb3I6 IGJsYWNrOwoJCWJhY2tncm91bmQtY29sb3I6IHdoaXRlOwoJCXZlcnRpY2FsLWFsaWduOiB0b3A7 CgkJZm9udC1zaXplOiAxMnB0OwoJICB9CgkKCSAgdWwudG9jIGE6OmFmdGVyIHsKCQljb250ZW50 OiBsZWFkZXIoJy4nKSB0YXJnZXQtY291bnRlcihhdHRyKGhyZWYpLCBwYWdlKTsKCSAgfQoJCgkg IHVsLmluZCBsaSBsaSBhIHsKCQljb250ZW50OiB0YXJnZXQtY291bnRlcihhdHRyKGhyZWYpLCBw YWdlKTsKCSAgfQoJCgkgIC5wcmludDJjb2wgewoJCWNvbHVtbi1jb3VudDogMjsKCQktbW96LWNv bHVtbi1jb3VudDogMjsKCQljb2x1bW4tZmlsbDogYXV0bzsKCSAgfQoJICB9CgkKCSAgQHBhZ2Ug ewoJICBAdG9wLWxlZnQgewoJCSAgIGNvbnRlbnQ6ICJJbnRlcm5ldC1EcmFmdCI7IAoJICB9IAoJ ICBAdG9wLXJpZ2h0IHsKCQkgICBjb250ZW50OiAiRGVjZW1iZXIgMjAxMCI7IAoJICB9IAoJICBA dG9wLWNlbnRlciB7CgkJICAgY29udGVudDogIkFiYnJldmlhdGVkIFRpdGxlIjsKCSAgfSAKCSAg QGJvdHRvbS1sZWZ0IHsKCQkgICBjb250ZW50OiAiRG9lIjsgCgkgIH0gCgkgIEBib3R0b20tY2Vu dGVyIHsKCQkgICBjb250ZW50OiAiRXhwaXJlcyBKdW5lIDIwMTEiOyAKCSAgfSAKCSAgQGJvdHRv bS1yaWdodCB7CgkJICAgY29udGVudDogIltQYWdlICIgY291bnRlcihwYWdlKSAiXSI7IAoJICB9 IAoJICB9CgkKCSAgQHBhZ2U6Zmlyc3QgeyAKCQlAdG9wLWxlZnQgewoJCSAgY29udGVudDogbm9y bWFsOwoJCX0KCQlAdG9wLXJpZ2h0IHsKCQkgIGNvbnRlbnQ6IG5vcm1hbDsKCQl9CgkJQHRvcC1j ZW50ZXIgewoJCSAgY29udGVudDogbm9ybWFsOwoJCX0KCSAgfQogIC8qXV0+Ki8KICA8L3N0eWxl PgoKICA8bGluayBocmVmPSIjcmZjLnRvYyIgcmVsPSJDb250ZW50cyIvPgo8bGluayBocmVmPSIj cmZjLnNlY3Rpb24uMSIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iMSBJbnRyb2R1Y3Rpb24iLz4KPGxp bmsgaHJlZj0iI3JmYy5zZWN0aW9uLjIiIHJlbD0iQ2hhcHRlciIgdGl0bGU9IjIgVGVybWlub2xv Z3kiLz4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9uLjMiIHJlbD0iQ2hhcHRlciIgdGl0bGU9IjMg QW1iaXNvbmljcyBXaXRoIE9nZyBPcHVzIi8+CjxsaW5rIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjEi IHJlbD0iQ2hhcHRlciIgdGl0bGU9IjMuMSBDaGFubmVsIE1hcHBpbmcgRmFtaWx5IDIiLz4KPGxp bmsgaHJlZj0iI3JmYy5zZWN0aW9uLjMuMiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iMy4yIENoYW5u ZWwgTWFwcGluZyBGYW1pbHkgMyIvPgo8bGluayBocmVmPSIjcmZjLnNlY3Rpb24uNCIgcmVsPSJD aGFwdGVyIiB0aXRsZT0iNCBEb3dubWl4aW5nIi8+CjxsaW5rIGhyZWY9IiNyZmMuc2VjdGlvbi41 IiByZWw9IkNoYXB0ZXIiIHRpdGxlPSI1IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIi8+CjxsaW5r IGhyZWY9IiNyZmMuc2VjdGlvbi42IiByZWw9IkNoYXB0ZXIiIHRpdGxlPSI2IElBTkEgQ29uc2lk ZXJhdGlvbnMiLz4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9uLjciIHJlbD0iQ2hhcHRlciIgdGl0 bGU9IjcgQWNrbm93bGVkZ21lbnRzIi8+CjxsaW5rIGhyZWY9IiNyZmMucmVmZXJlbmNlcyIgcmVs PSJDaGFwdGVyIiB0aXRsZT0iOCBSZWZlcmVuY2VzIi8+CjxsaW5rIGhyZWY9IiNyZmMucmVmZXJl bmNlcy4xIiByZWw9IkNoYXB0ZXIiIHRpdGxlPSI4LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMiLz4K PGxpbmsgaHJlZj0iI3JmYy5yZWZlcmVuY2VzLjIiIHJlbD0iQ2hhcHRlciIgdGl0bGU9IjguMiBJ bmZvcm1hdGl2ZSBSZWZlcmVuY2VzIi8+CjxsaW5rIGhyZWY9IiNyZmMuYXV0aG9ycyIgcmVsPSJD aGFwdGVyIi8+CgoKICA8bWV0YSBuYW1lPSJnZW5lcmF0b3IiIGNvbnRlbnQ9InhtbDJyZmMgdmVy c2lvbiAyLjUuMiAtIGh0dHA6Ly90b29scy5pZXRmLm9yZy90b29scy94bWwycmZjIiAvPgogIDxs aW5rIHJlbD0ic2NoZW1hLmRjdCIgaHJlZj0iaHR0cDovL3B1cmwub3JnL2RjL3Rlcm1zLyIgLz4K CiAgPG1ldGEgbmFtZT0iZGN0LmNyZWF0b3IiIGNvbnRlbnQ9IlNrb2dsdW5kLCBKLiBhbmQgTS4g R3JhY3p5ayIgLz4KICA8bWV0YSBuYW1lPSJkY3QuaWRlbnRpZmllciIgY29udGVudD0idXJuOmll dGY6aWQ6ZHJhZnQtaWV0Zi1jb2RlYy1hbWJpc29uaWNzLTAyIiAvPgogIDxtZXRhIG5hbWU9ImRj dC5pc3N1ZWQiIHNjaGVtZT0iSVNPODYwMSIgY29udGVudD0iMjAxNy0zLTE3IiAvPgogIDxtZXRh IG5hbWU9ImRjdC5hYnN0cmFjdCIgY29udGVudD0iVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGV4 dGVuc2lvbiB0byB0aGUgT2dnIGZvcm1hdCB0byBlbmNhcHN1bGF0ZSBhbWJpc29uaWNzIGNvZGVk IHVzaW5nIHRoZSBPcHVzIGF1ZGlvIGNvZGVjLiAgIiAvPgogIDxtZXRhIG5hbWU9ImRlc2NyaXB0 aW9uIiBjb250ZW50PSJUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBP Z2cgZm9ybWF0IHRvIGVuY2Fwc3VsYXRlIGFtYmlzb25pY3MgY29kZWQgdXNpbmcgdGhlIE9wdXMg YXVkaW8gY29kZWMuICAiIC8+Cgo8L2hlYWQ+Cgo8Ym9keT4KCiAgPHRhYmxlIGNsYXNzPSJoZWFk ZXIiPgogICAgPHRib2R5PgogICAgCiAgICAJPHRyPgogIDx0ZCBjbGFzcz0ibGVmdCI+Y29kZWM8 L3RkPgogIDx0ZCBjbGFzcz0icmlnaHQiPkouIFNrb2dsdW5kPC90ZD4KPC90cj4KPHRyPgogIDx0 ZCBjbGFzcz0ibGVmdCI+SW50ZXJuZXQtRHJhZnQ8L3RkPgogIDx0ZCBjbGFzcz0icmlnaHQiPk0u IEdyYWN6eWs8L3RkPgo8L3RyPgo8dHI+CiAgPHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBzdGF0 dXM6IFN0YW5kYXJkcyBUcmFjazwvdGQ+CiAgPHRkIGNsYXNzPSJyaWdodCI+R29vZ2xlIEluYy48 L3RkPgo8L3RyPgo8dHI+CiAgPHRkIGNsYXNzPSJsZWZ0Ij5FeHBpcmVzOiBTZXB0ZW1iZXIgMTgs IDIwMTc8L3RkPgogIDx0ZCBjbGFzcz0icmlnaHQiPk1hcmNoIDE3LCAyMDE3PC90ZD4KPC90cj4K CiAgICAJCiAgICA8L3Rib2R5PgogIDwvdGFibGU+CgogIDxwIGNsYXNzPSJ0aXRsZSI+QW1iaXNv bmljcyBpbiBhbiBPZ2cgT3B1cyBDb250YWluZXI8YnIgLz4KICA8c3BhbiBjbGFzcz0iZmlsZW5h bWUiPmRyYWZ0LWlldGYtY29kZWMtYW1iaXNvbmljcy0wMjwvc3Bhbj48L3A+CiAgCiAgPGgxIGlk PSJyZmMuYWJzdHJhY3QiPgogIDxhIGhyZWY9IiNyZmMuYWJzdHJhY3QiPkFic3RyYWN0PC9hPgo8 L2gxPgo8cD5UaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBPZ2cgZm9y bWF0IHRvIGVuY2Fwc3VsYXRlIGFtYmlzb25pY3MgY29kZWQgdXNpbmcgdGhlIE9wdXMgYXVkaW8g Y29kZWMuICA8L3A+CjxoMSBpZD0icmZjLnN0YXR1cyI+CiAgPGEgaHJlZj0iI3JmYy5zdGF0dXMi PlN0YXR1cyBvZiBUaGlzIE1lbW88L2E+CjwvaDE+CjxwPlRoaXMgSW50ZXJuZXQtRHJhZnQgaXMg c3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1Ag NzggYW5kIEJDUCA3OS48L3A+CjxwPkludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVu dHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0 aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGlz IGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC9wPgo8cD5J bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90 aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvcD4KPHA+VGhpcyBJbnRlcm5ldC1EcmFm dCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1iZXIgMTgsIDIwMTcuPC9wPgo8aDEgaWQ9InJmYy5jb3B5 cmlnaHRub3RpY2UiPgogIDxhIGhyZWY9IiNyZmMuY29weXJpZ2h0bm90aWNlIj5Db3B5cmlnaHQg Tm90aWNlPC9hPgo8L2gxPgo8cD5Db3B5cmlnaHQgKGMpIDIwMTcgSUVURiBUcnVzdCBhbmQgdGhl IHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuPC9wPgo8cD5UaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0 aGUgSUVURiBUcnVzdCdzIExlZ2FsIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVu dHMgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRo ZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRo ZXNlIGRvY3VtZW50cyBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5k IHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9u ZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QgaW5jbHVkZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcyBk ZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuPC9wPgoKICAKICA8aHIgY2xh c3M9Im5vcHJpbnQiIC8+CiAgPGgxIGNsYXNzPSJucCIgaWQ9InJmYy50b2MiPjxhIGhyZWY9IiNy ZmMudG9jIj5UYWJsZSBvZiBDb250ZW50czwvYT48L2gxPgogIDx1bCBjbGFzcz0idG9jIj4KCiAg CTxsaT4xLiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi4xIj5JbnRyb2R1Y3Rpb248L2E+PC9saT4K PGxpPjIuICAgPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjIiPlRlcm1pbm9sb2d5PC9hPjwvbGk+Cjxs aT4zLiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zIj5BbWJpc29uaWNzIFdpdGggT2dnIE9wdXM8 L2E+PC9saT4KPHVsPjxsaT4zLjEuICAgPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjMuMSI+Q2hhbm5l bCBNYXBwaW5nIEZhbWlseSAyPC9hPjwvbGk+CjxsaT4zLjIuICAgPGEgaHJlZj0iI3JmYy5zZWN0 aW9uLjMuMiI+Q2hhbm5lbCBNYXBwaW5nIEZhbWlseSAzPC9hPjwvbGk+CjwvdWw+PGxpPjQuICAg PGEgaHJlZj0iI3JmYy5zZWN0aW9uLjQiPkRvd25taXhpbmc8L2E+PC9saT4KPGxpPjUuICAgPGEg aHJlZj0iI3JmYy5zZWN0aW9uLjUiPlNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC9hPjwvbGk+Cjxs aT42LiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi42Ij5JQU5BIENvbnNpZGVyYXRpb25zPC9hPjwv bGk+CjxsaT43LiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi43Ij5BY2tub3dsZWRnbWVudHM8L2E+ PC9saT4KPGxpPjguICAgPGEgaHJlZj0iI3JmYy5yZWZlcmVuY2VzIj5SZWZlcmVuY2VzPC9hPjwv bGk+Cjx1bD48bGk+OC4xLiAgIDxhIGhyZWY9IiNyZmMucmVmZXJlbmNlcy4xIj5Ob3JtYXRpdmUg UmVmZXJlbmNlczwvYT48L2xpPgo8bGk+OC4yLiAgIDxhIGhyZWY9IiNyZmMucmVmZXJlbmNlcy4y Ij5JbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPC9hPjwvbGk+CjwvdWw+PGxpPjxhIGhyZWY9IiNyZmMu YXV0aG9ycyI+QXV0aG9ycycgQWRkcmVzc2VzPC9hPjwvbGk+CgoKICA8L3VsPgoKICA8aDEgaWQ9 InJmYy5zZWN0aW9uLjEiPjxhIGhyZWY9IiNyZmMuc2VjdGlvbi4xIj4xLjwvYT4gPGEgaHJlZj0i I2ludHJvIiBpZD0iaW50cm8iPkludHJvZHVjdGlvbjwvYT48L2gxPgo8cCBpZD0icmZjLnNlY3Rp b24uMS5wLjEiPkFtYmlzb25pY3MgaXMgYSByZXByZXNlbnRhdGlvbiBmb3JtYXQgZm9yIHRocmVl IGRpbWVuc2lvbmFsIHNvdW5kIGZpZWxkcyB3aGljaCBjYW4gYmUgdXNlZCBmb3Igc3Vycm91bmQg c291bmQgYW5kIGltbWVyc2l2ZSB2aXJ0dWFsIHJlYWxpdHkgcGxheWJhY2suICBTZWUgPGEgaHJl Zj0iI2dlcnpvbjc1Ij5bZ2Vyem9uNzVdPC9hPiBhbmQgPGEgaHJlZj0iI2RhbmllbDA0Ij5bZGFu aWVsMDRdPC9hPiBmb3IgdGVjaG5pY2FsIGRldGFpbHMgb24gdGhlIGFtYmlzb25pY3MgZm9ybWF0 LiAgRm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIGRvY3VtZW50LCBhbWJpc29uaWNzIGNhbiBiZSBj b25zaWRlcmVkIGEgbXVsdGljaGFubmVsIGF1ZGlvIHN0cmVhbS4gIEEgc2VwYXJhdGUgc3RlcmVv IHN0cmVhbSBjYW4gYmUgdXNlZCBhbG9uZ3NpZGUgdGhlIGFtYmlzb25pY3MgaW4gYSBoZWFkLXRy YWNrZWQgdmlydHVhbCByZWFsaXR5IGV4cGVyaWVuY2UgdG8gcHJvdmlkZSBzby1jYWxsZWQgbm9u LWRpZWdldGljIGF1ZGlvIC0gYXVkaW8gd2hpY2ggc2hvdWxkIHJlbWFpbiB1bmNoYW5nZWQgYnkg bGlzdGVuZXIgaGVhZCByb3RhdGlvbjsgZS5nLiwgbmFycmF0aW9uIG9yIHN0ZXJlbyBtdXNpYy4g IE9nZyBpcyBhIGdlbmVyYWwgcHVycG9zZSBjb250YWluZXIsIHN1cHBvcnRpbmcgYXVkaW8sIHZp ZGVvLCBhbmQgb3RoZXIgbWVkaWEuICBJdCBjYW4gYmUgdXNlZCB0byBlbmNhcHN1bGF0ZSBhdWRp byBzdHJlYW1zIGNvZGVkIHVzaW5nIHRoZSBPcHVzIGNvZGVjLiAgU2VlIDxhIGhyZWY9IiNSRkM2 NzE2Ij5bUkZDNjcxNl08L2E+IGFuZCA8YSBocmVmPSIjUkZDNzg0NSI+W1JGQzc4NDVdPC9hPiBm b3IgdGVjaG5pY2FsIGRldGFpbHMgb24gdGhlIE9wdXMgY29kZWMgYW5kIGl0cyBlbmNhcHN1bGF0 aW9uIGluIHRoZSBPZ2cgY29udGFpbmVyIHJlc3BlY3RpdmVseS4gIDwvcD4KPHAgaWQ9InJmYy5z ZWN0aW9uLjEucC4yIj5UaGlzIGRvY3VtZW50IGV4dGVuZHMgdGhlIE9nZyBmb3JtYXQgYnkgZGVm aW5pbmcgdHdvIG5ldyBjaGFubmVsIG1hcHBpbmcgZmFtaWxpZXMgZm9yIGVuY29kaW5nIGFtYmlz b25pY3MuIFRoZSBPZ2cgT3B1cyBmb3JtYXQgaXMgZXh0ZW5kZWQgaW5kaXJlY3RseSBieSBhZGRp bmcgYW4gaXRlbSB3aXRoIHZhbHVlIDIgb3IgMyB0byB0aGUgSUFOQSAiT3B1cyBDaGFubmVsIE1h cHBpbmcgRmFtaWxpZXMiIHJlZ2lzdHJ5LiAgV2hlbiAyIG9yIDMgYXJlIHVzZWQgYXMgdGhlIENo YW5uZWwgTWFwcGluZyBGYW1pbHkgTnVtYmVyIGluIGFuIE9nZyBzdHJlYW0sIHRoZSBzZW1hbnRp YyBtZWFuaW5nIG9mIHRoZSBjaGFubmVscyBpbiB0aGUgbXVsdGljaGFubmVsIE9wdXMgc3RyZWFt IGlzIG9uZSBvZiB0aGUgYW1iaXNvbmljcyBsYXlvdXRzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dC4gVGhpcyBtYXBwaW5nIGNhbiBhbHNvIGJlIHVzZWQgaW4gb3RoZXIgY29udGV4dHMgd2hpY2gg bWFrZSB1c2Ugb2YgdGhlIGNoYW5uZWwgbWFwcGluZ3MgZGVmaW5lZCBieSB0aGUgT3B1cyBDaGFu bmVsIE1hcHBpbmcgRmFtaWxpZXMgcmVnaXN0cnkuICA8L3A+CjxoMSBpZD0icmZjLnNlY3Rpb24u MiI+PGEgaHJlZj0iI3JmYy5zZWN0aW9uLjIiPjIuPC9hPiA8YSBocmVmPSIjdGVybWlub2xvZ3ki IGlkPSJ0ZXJtaW5vbG9neSI+VGVybWlub2xvZ3k8L2E+PC9oMT4KPHAgaWQ9InJmYy5zZWN0aW9u LjIucC4xIj5UaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNI QUxMIiwgIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVu dCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIDxhIGhyZWY9IiNSRkMyMTE5 Ij5bUkZDMjExOV08L2E+LiAgPC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjMiPjxhIGhyZWY9IiNy ZmMuc2VjdGlvbi4zIj4zLjwvYT4gPGEgaHJlZj0iI29nZ19leHRlbnNpb24iIGlkPSJvZ2dfZXh0 ZW5zaW9uIj5BbWJpc29uaWNzIFdpdGggT2dnIE9wdXM8L2E+PC9oMT4KPHAgaWQ9InJmYy5zZWN0 aW9uLjMucC4xIj5BbWJpc29uaWNzIGNhbiBiZSBlbmNhcHN1bGF0ZWQgaW4gdGhlIE9nZyBmb3Jt YXQgYnkgZW5jb2Rpbmcgd2l0aCB0aGUgT3B1cyBjb2RlYyBhbmQgc2V0dGluZyB0aGUgY2hhbm5l bCBtYXBwaW5nIGZhbWlseSB2YWx1ZSB0byAyIG9yIDMgaW4gdGhlIE9nZyBpZGVudGlmaWNhdGlv biBoZWFkZXIgKElEKS4gQSBkZW11eGVyIGltcGxlbWVudGF0aW9uIGVuY291bnRlcmluZyBDaGFu bmVsIE1hcHBpbmcgRmFtaWx5IDIgb3IgRmFtaWx5IDMgTVVTVCBpbnRlcnByZXQgdGhlIE9wdXMg c3RyZWFtIGFzIGNvbnRhaW5pbmcgYW1iaXNvbmljcyB3aXRoIHRoZSBmb3JtYXQgZGVzY3JpYmVk IGluIDxhIGhyZWY9IiNjaGFubmVsX21hcHBpbmdfMiI+U2VjdGlvbiAzLjE8L2E+IG9yIDxhIGhy ZWY9IiNjaGFubmVsX21hcHBpbmdfMyI+U2VjdGlvbiAzLjI8L2E+LCByZXNwZWN0aXZlbHkuICA8 L3A+CjxoMSBpZD0icmZjLnNlY3Rpb24uMy4xIj48YSBocmVmPSIjcmZjLnNlY3Rpb24uMy4xIj4z LjEuPC9hPiA8YSBocmVmPSIjY2hhbm5lbF9tYXBwaW5nXzIiIGlkPSJjaGFubmVsX21hcHBpbmdf MiI+Q2hhbm5lbCBNYXBwaW5nIEZhbWlseSAyPC9hPjwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi4z LjEucC4xIj5BbGxvd2VkIG51bWJlcnMgb2YgY2hhbm5lbHM6ICgxICsgbileMiArIDJqIGZvciBu ID0gMC4uLjE0IGFuZCBqID0gMCBvciAxLCB3aGVyZSBuIGRlbm90ZXMgdGhlIChoaWdoZXN0KSBh bWJpc29uaWMgb3JkZXIgYW5kIGogd2hldGhlciBvciBub3QgdGhlcmUgaXMgYSBzZXBhcmF0ZSBu b24tZGllZ2V0aWMgc3RlcmVvIHN0cmVhbS4gIFRoaXMgY29ycmVzcG9uZHMgdG8gcGVyaXBob25p YyBhbWJpc29uaWNzIGZyb20gemVyb3RoIHRvIGZvdXJ0ZWVudGggb3JkZXIgcGx1cyBwb3RlbnRp YWxseSB0d28gY2hhbm5lbHMgb2Ygbm9uLWRpZWdldGljIHN0ZXJlby4gIEV4cGxpY2l0bHkgdGhl IGFsbG93ZWQgbnVtYmVyIG9mIGNoYW5uZWxzIGFyZSAxLCAzLCA0LCA2LCA5LCAxMSwgMTYsIDE4 LCAyNSwgMjcsIDM2LCAzOCwgNDksIDUxLCA2NCwgNjYsIDgxLCA4MywgMTAwLCAxMDIsIDEyMSwg MTIzLCAxNDQsIDE0NiwgMTY5LCAxNzEsIDE5NiwgMTk4LCAyMjUsIDIyNy4gIDwvcD4KPHAgaWQ9 InJmYy5zZWN0aW9uLjMuMS5wLjIiPlRoaXMgY2hhbm5lbCBtYXBwaW5nIHVzZXMgdGhlIHNhbWUg Y2hhbm5lbCBtYXBwaW5nIHRhYmxlIGZvcm1hdCB1c2VkIGJ5IGNoYW5uZWwgbWFwcGluZyBmYW1p bHkgMS4gVGhlIG91dHB1dCBjaGFubmVscyBhcmUgYW1iaXNvbmljIGNvbXBvbmVudHMgb3JkZXJl ZCBpbiBBbWJpc29uaWMgQ2hhbm5lbCBOdW1iZXIgKEFDTikgb3JkZXIsIGRlZmluZWQgaW4gPGEg aHJlZj0iI0FDTiI+RmlndXJlIDE8L2E+LCBmb2xsb3dlZCBieSB0d28gb3B0aW9uYWwgY2hhbm5l bHMgb2Ygbm9uLWRpZWdldGljIHN0ZXJlbyBpbmRleGVkIChsZWZ0LCByaWdodCkuICA8L3A+Cjxk aXYgaWQ9InJmYy5maWd1cmUuMSIvPgo8ZGl2IGlkPSJBQ04iLz4KPHByZT4KQUNOID0gbiAqIChu ICsgMSkgKyBtLApmb3Igb3JkZXIgbiBhbmQgZGVncmVlIG0uCjwvcHJlPgo8cCBjbGFzcz0iZmln dXJlIj5GaWd1cmUgMTogQW1iaXNvbmljIENoYW5uZWwgTnVtYmVyIChBQ04pPC9wPgo8cCBpZD0i cmZjLnNlY3Rpb24uMy4xLnAuMyI+Rm9yIHRoZSBhbWJpc29uaWMgY2hhbm5lbHMgdGhlIEFDTiBj b21wb25lbnQgY29ycmVzcG9uZHMgdG8gY2hhbm5lbCBpbmRleCBhcyBrID0gQUNOLiBUaGUgcmV2 ZXJzZSBjb3JyZXNwb25kZW5jZSBjYW4gYWxzbyBiZSBjb21wdXRlZCBmb3IgYW4gYW1iaXNvbmlj IGNoYW5uZWwgd2l0aCBpbmRleCBrLiAgPC9wPgo8ZGl2IGlkPSJyZmMuZmlndXJlLjIiLz4KPGRp diBpZD0iaW52ZXJzZUFDTiIvPgo8cHJlPgpvcmRlciAgIG4gPSBmbG9vcihzcXJ0KGspKSwKZGVn cmVlICBtID0gayAtIG4gKiAobiArIDEpLgo8L3ByZT4KPHAgY2xhc3M9ImZpZ3VyZSI+RmlndXJl IDI6IEFtYmlzb25pYyBEZWdyZWUgYW5kIE9yZGVyICAgZnJvbSBBQ048L3A+CjxwIGlkPSJyZmMu c2VjdGlvbi4zLjEucC40Ij5Ob3RlIHRoYXQgY2hhbm5lbCBtYXBwaW5nIGZhbWlseSAyIGFsbG93 cyBmb3Igc28tY2FsbGVkIG1peGVkIG9yZGVyIGFtYmlzb25pYyByZXByZXNlbnRhdGlvbnMgd2hl cmUgb25seSBhIHN1YnNldCBvZiB0aGUgZnVsbCBhbWJpc29uaWMgb3JkZXIgbnVtYmVyIG9mIGNo YW5uZWxzIGlzIHVzZWQuIEJ5IHNwZWNpZnlpbmcgdGhlIGZ1bGwgbnVtYmVyIGluIHRoZSBjaGFu bmVsIGNvdW50IGZpZWxkLCB0aGUgaW5hY3RpdmUgQUNOcyBjYW4gdGhlbiBiZSBpbmRpY2F0ZWQg aW4gdGhlIGNoYW5uZWwgbWFwcGluZyBmaWVsZCB1c2luZyB0aGUgaW5kZXggMjU1LjwvcD4KPHAg aWQ9InJmYy5zZWN0aW9uLjMuMS5wLjUiPkFtYmlzb25pYyBjaGFubmVscyBhcmUgZXhwZWN0ZWQg dG8gYmUgbm9ybWFsaXplZCB3aXRoIFNjaG1pZHQgU2VtaS1Ob3JtYWxpemF0aW9uIChTTjNEKS4g IFRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgYW1iaXNvbmljcyBzaWduYWwgYXMgd2VsbCBhcyBk ZXRhaWxlZCBkZWZpbml0aW9ucyBvZiBBQ04gY2hhbm5lbCBvcmRlcmluZyBhbmQgU04zRCBub3Jt YWxpemF0aW9uIGFyZSBkZXNjcmliZWQgaW4gPGEgaHJlZj0iI2FtYml4Ij5bYW1iaXhdPC9hPiBT ZWN0aW9uIDIuMS4gIDwvcD4KPGgxIGlkPSJyZmMuc2VjdGlvbi4zLjIiPjxhIGhyZWY9IiNyZmMu c2VjdGlvbi4zLjIiPjMuMi48L2E+IDxhIGhyZWY9IiNjaGFubmVsX21hcHBpbmdfMyIgaWQ9ImNo YW5uZWxfbWFwcGluZ18zIj5DaGFubmVsIE1hcHBpbmcgRmFtaWx5IDM8L2E+PC9oMT4KPHAgaWQ9 InJmYy5zZWN0aW9uLjMuMi5wLjEiPkFsbG93ZWQgbnVtYmVycyBvZiBjaGFubmVsczogKDEgKyBu KV4yICsgMmogZm9yIG4gPSAwLi4uMTIgYW5kIGogPSAwIG9yIDEsIHdoZXJlIG4gZGVub3RlcyB0 aGUgKGhpZ2hlc3QpIGFtYmlzb25pYyBvcmRlciBhbmQgaiB3aGV0aGVyIG9yIG5vdCB0aGVyZSBp cyBhIHNlcGFyYXRlIG5vbi1kaWVnZXRpYyBzdGVyZW8gc3RyZWFtLiAgVGhpcyBjb3JyZXNwb25k cyB0byBwZXJpcGhvbmljIGFtYmlzb25pY3MgZnJvbSB6ZXJvdGggdG8gdHdlbGZ0aCBvcmRlciBw bHVzIHBvdGVudGlhbGx5IHR3byBjaGFubmVscyBvZiBub24tZGllZ2V0aWMgc3RlcmVvLiAgRXhw bGljaXRseSB0aGUgYWxsb3dlZCBudW1iZXIgb2YgY2hhbm5lbHMgYXJlIDEsIDMsIDQsIDYsIDks IDExLCAxNiwgMTgsIDI1LCAyNywgMzYsIDM4LCA0OSwgNTEsIDY0LCA2NiwgODEsIDgzLCAxMDAs IDEwMiwgMTIxLCAxMjMsIDE0NCwgMTQ2LCAxNjksIDE3MS4gIDwvcD4KPHAgaWQ9InJmYy5zZWN0 aW9uLjMuMi5wLjIiPkluIHRoaXMgbWFwcGluZywgQyBvdXRwdXQgY2hhbm5lbHMgKHRoZSBjaGFu bmVsIGNvdW50KSBhcmUgZ2VuZXJhdGVkIGF0IHRoZSBkZWNvZGVyIGJ5IG11bHRpcGx5aW5nIEsg PSBOICsgTSBkZWNvZGVkIGNoYW5uZWxzIHdpdGggYSBkZXNpZ25hdGVkIGRlbWl4aW5nIG1hdHJp eCwgRCwgaGF2aW5nIEMgcm93cyBhbmQgSyBjb2x1bW5zLiBIZXJlLCBOIGRlbm90ZXMgdGhlIG51 bWJlciBvZiBzdHJlYW1zIGVuY29kZWQgYW5kIE0gdGhlIG51bWJlciBvZiB0aGVzZSB3aGljaCBh cmUgY291cGxlZCB0byBwcm9kdWNlIHR3byBjaGFubmVscy4gICBBcyBmb3IgY2hhbm5lbCBtYXBw aW5nIGZhbWlseSAyIHRoaXMgbWFwcGluZyBmYW1pbHkgYWxzbyBhbGxvd3MgZm9yIGVuY29kaW5n IGFuZCBkZWNvZGluZyBvZiBmdWxsIG9yZGVyIGFtYmlzb25pY3MsIG1peGVkIG9yZGVyIGFtYmlz b25pY3MsIGFuZCBmb3Igbm9uLWRpZWdldGljIHN0ZXJlbyBjaGFubmVscywgYnV0IGFsc28gaGFz IHRoZSBhZGRlZCBmbGV4aWJpbGl0eSBvZiBtaXhpbmcgY2hhbm5lbHMuICBMZXQgWCBkZW5vdGUg YSBjb2x1bW4gdmVjdG9yIGNvbnRhaW5pbmcgSyBkZWNvZGVkIGNoYW5uZWxzIFgxLCBYMiwgLi4u LCBYSyAoZnJvbSBOIHN0cmVhbXMpLCBhbmQgbGV0IFMgZGVub3RlIGEgY29sdW1uIHZlY3RvciBj b250YWluaW5nIEMgb3V0cHV0IHN0cmVhbXMgUzEsIFMyLCAuLi4sIFNDLiBUaGVuIFMgPSBEIFgs IGkuZS4sIDwvcD4KPGRpdiBpZD0icmZjLmZpZ3VyZS4zIi8+CjxkaXYgaWQ9ImRlbWl4aW5nIi8+ CjxwcmU+Ci8gICAgIFwgICAvICAgICAgICAgICAgICAgICAgIFwgLyAgICAgXAp8IFMxICB8ICAg fCBEMTEgIEQxMiAgLi4uIEQxSyB8IHwgWDEgIHwKfCBTMiAgfCAgIHwgRDIxICBEMjIgIC4uLiBE MksgfCB8IFgyICB8CnwgLi4uIHwgPSB8IC4uLiAgLi4uICAuLi4gLi4uIHwgfCAuLi4gfAp8IFND ICB8ICAgfCBEQzEgIERDMiAgLi4uIERDSyB8IHwgWEsgIHwKXCAgICAgLyAgIFwgICAgICAgICAg ICAgICAgICAgLyBcICAgICAvCjwvcHJlPgo8cCBjbGFzcz0iZmlndXJlIj5GaWd1cmUgMzogRGVt aXhpbmcgaW4gQ2hhbm5lbCBNYXBwaW5nIEZhbWlseSAzPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24u My4yLnAuMyI+VGhlIG1hdHJpeCBNVVNUIGJlIHByb3ZpZGVkIGFzIHNpZGUgaW5mb3JtYXRpb24g YW5kIE1VU1QgYmUgc3RvcmVkIGluIHRoZSBjaGFubmVsIG1hcHBpbmcgdGFibGUgcGFydCBvZiB0 aGUgaWRlbnRpZmljYXRpb24gaGVhZGVyLCBjLmYuIHNlY3Rpb24gNS4xLjEgaW4gPGEgaHJlZj0i I1JGQzc4NDUiPltSRkM3ODQ1XTwvYT4uIFRoZSBtYXRyaXggcmVwbGFjZXMgdGhlIG5lZWQgZm9y IGEgY2hhbm5lbCBtYXBwaW5nIGZpZWxkIGFuZCBmb3IgY2hhbm5lbCBtYXBwaW5nIGZhbWlseSAz IHRoZSBtYXBwaW5nIHRhYmxlIGhhcyB0aGUgZm9sbG93aW5nIGxheW91dDogPC9wPgo8ZGl2IGlk PSJyZmMuZmlndXJlLjQiLz4KPGRpdiBpZD0iY2hhbm5lbF9tYXBwaW5nIi8+CjxwcmU+CgogMCAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAg MwogMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstKy0rLSstKy0rLSstKy0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgU3RyZWFtIENvdW50ICB8CistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCnwgQ291cGxlZCBDb3VudCB8IERl bWl4aW5nIE1hdHJpeCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6CistKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgo8 L3ByZT4KPHAgY2xhc3M9ImZpZ3VyZSI+RmlndXJlIDQ6IENoYW5uZWwgTWFwcGluZyBUYWJsZSBm b3IgIENoYW5uZWwgTWFwcGluZyBGYW1pbHkgMzwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMi5w LjQiPlRoZSBmaWVsZHMgaW4gdGhlIGNoYW5uZWwgbWFwcGluZyB0YWJsZSBoYXZlIHRoZSBmb2xs b3dpbmcgbWVhbmluZzogPC9wPgoKPG9sPgogIDxsaT5TdHJlYW0gQ291bnQgJ04nICg4IGJpdHMs IHVuc2lnbmVkKTogPGJyLz48YnIvPiBUaGlzIGlzIHRoZSB0b3RhbCBudW1iZXIgb2Ygc3RyZWFt cyBlbmNvZGVkIGluIGVhY2ggT2dnIHBhY2tldC4gIDxici8+PGJyLz4gPC9saT4KICA8bGk+Q291 cGxlZCBTdHJlYW0gQ291bnQgJ00nICg4IGJpdHMsIHVuc2lnbmVkKTogPGJyLz48YnIvPiBUaGlz IGlzIHRoZSBudW1iZXIgb2YgdGhlIE4gc3RyZWFtcyB3aG9zZSBkZWNvZGVycyBhcmUgdG8gYmUg Y29uZmlndXJlZCB0byBwcm9kdWNlIHR3byBjaGFubmVscyAoc3RlcmVvKS4gIDxici8+PGJyLz4g PC9saT4KICA8bGk+RGVtaXhpbmcgTWF0cml4ICgxNipLKkMgYml0cywgc2lnbmVkKTogPGJyLz48 YnIvPiBUaGUgY29lZmZpY2llbnRzIG9mIHRoZSBkZW1peGluZyBtYXRyaXggc3RvcmVkIGNvbHVt bi13aXNlIGFzIDE2LWJpdCwgc2lnbmVkLCB0d28ncyBjb21wbGVtZW50IGZpeGVkLXBvaW50IHZh bHVlcyB3aXRoIDE1IGZyYWN0aW9uYWwgYml0cyAoUTE1KS4gSWYgbmVlZGVkLCB0aGUgb3V0cHV0 IGdhaW4gZmllbGQgY2FuIGJlIHVzZWQgZm9yIGEgbm9ybWFsaXphdGlvbiBzY2FsZS4gRm9yIG1p eGVkIG9yZGVyIGFtYmlzb25pYyByZXByZXNlbnRhdGlvbnMsIHRoZSBzaWxlbnQgQUNOIGNoYW5u ZWxzIGFyZSBpbmRpY2F0ZWQgYnkgYWxsIHplcm9zIGluIHRoZSBjb3JyZXNwb25kaW5nIHJvd3Mg b2YgdGhlIGRlbWl4aW5nIG1hdHJpeC4gPC9saT4KPC9vbD4KCjxwPiA8L3A+CjxwIGlkPSJyZmMu c2VjdGlvbi4zLjIucC41Ij5Ob3RlIHRoYXQgPGEgaHJlZj0iI1JGQzc4NDUiPltSRkM3ODQ1XTwv YT4gc3BlY2lmaWVzIHRoYXQgdGhlIGlkZW50aWZpY2F0aW9uIGhlYWRlciBjYW5ub3QgZXhjZWVk IG9uZSAicGFnZSIsIHdoaWNoIGlzIDY1LDAyNSBvY3RldHMuIFRoaXMgbGltaXRzIHRoZSBhbWJp c29uaWMgb3JkZXIgdG8gYmUgbG93ZXIgdGhhbiAxMi4gIEFsc28gbm90ZSB0aGF0IHRoZSB0b3Rh bCBvdXRwdXQgY2hhbm5lbCBudW1iZXIsIEMsIE1VU1QgYmUgc2V0IGluIHRoZSAzcmQgZmllbGQg b2YgdGhlIGlkZW50aWZpY2F0aW9uIGhlYWRlci4gIDwvcD4KPGgxIGlkPSJyZmMuc2VjdGlvbi40 Ij48YSBocmVmPSIjcmZjLnNlY3Rpb24uNCI+NC48L2E+IDxhIGhyZWY9IiNkb3dubWl4aW5nIiBp ZD0iZG93bm1peGluZyI+RG93bm1peGluZzwvYT48L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uNC5w LjEiPkFuIE9nZyBPcHVzIHBsYXllciBNQVkgdXNlIHRoZSBtYXRyaXggaW4gRmlndXJlIDxhIGhy ZWY9IiNzdGVyZW9fZG93bm1peF9tYXRyaXhfMSI+NTwvYT4gdG8gaW1wbGVtZW50IGRvd25taXhp bmcgZnJvbSBtdWx0aWNoYW5uZWwgZmlsZXMgdXNpbmcgY2hhbm5lbCBtYXBwaW5nIGZhbWlseSAy IGFuZCAzLCB3aGVuIHRoZXJlIGlzIG5vIG5vbi1kaWVnZXRpYyBzdGVyZW8uICBUaGlzIGRvd25t aXhpbmcgaXMga25vd24gdG8gZ2l2ZSBhY2NlcHRhYmxlIHJlc3VsdHMgZm9yIHN0ZXJlbyBkb3du bWl4aW5nIGZyb20gYW1iaXNvbmljcy4gVGhlIGZpcnN0IGFuZCBzZWNvbmQgYW1iaXNvbmljIGNo YW5uZWxzIGFyZSBrbm93biBhcyAiVyIgYW5kICJZIiByZXNwZWN0aXZlbHkuICA8L3A+CjxkaXYg aWQ9InJmYy5maWd1cmUuNSIvPgo8ZGl2IGlkPSJzdGVyZW9fZG93bm1peF9tYXRyaXhfMSIvPgo8 cHJlPgovICAgXCAgIC8gICAgICAgICAgICAgICAgICBcIC8gICAgIFwKfCBMIHwgICB8IDAuNSAg MC41IDAuMCAuLi4gfCB8ICBXICB8CnwgUiB8ID0gfCAwLjUgLTAuNSAwLjAgLi4uIHwgfCAgWSAg fApcICAgLyAgIFwgICAgICAgICAgICAgICAgICAvIHwgLi4uIHwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBcICAgICAvCjwvcHJlPgo8cCBjbGFzcz0iZmlndXJlIj5GaWd1cmUgNTogU3Rl cmVvIERvd25taXhpbmcgTWF0cml4IGZvciBDaGFubmVsIE1hcHBpbmcgRmFtaWx5IDIgYW5kIDMg LSAgIG9ubHkgQW1iaXNvbmljIENoYW5uZWxzPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uNC5wLjIi PlRoZSBmaXJzdCBhbWJpc29uaWMgY2hhbm5lbCAoVykgaXMgYSBtb25vIGF1ZGlvIHN0cmVhbSB3 aGljaCByZXByZXNlbnRzIHRoZSBhdmVyYWdlIGF1ZGlvIHNpZ25hbCBvdmVyIGFsbCBkaXJlY3Rp b25zLiBTaW5jZSBXIGlzIG5vdCBkaXJlY3Rpb25hbCwgT2dnIE9wdXMgcGxheWVycyBNQVkgdXNl IFcgZGlyZWN0bHkgZm9yIG1vbm8gcGxheWJhY2suICA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi40 LnAuMyI+SWYgYSBub24tZGllZ2V0aWMgc3RlcmVvIHRyYWNrIGlzIHByZXNlbnQsIHRoZSBwbGF5 ZXIgTUFZIHVzZSB0aGUgbWF0cml4IGluIEZpZ3VyZSA8YSBocmVmPSIjc3RlcmVvX2Rvd25taXhf bWF0cml4XzIiPjY8L2E+IGZvciBkb3dubWl4aW5nLiAgTHMgYW5kIFJzIGRlbm90ZSB0aGUgdHdv IG5vbi1kaWVnZXRpYyBzdGVyZW8gY2hhbm5lbHMuICA8L3A+CjxkaXYgaWQ9InJmYy5maWd1cmUu NiIvPgo8ZGl2IGlkPSJzdGVyZW9fZG93bm1peF9tYXRyaXhfMiIvPgo8cHJlPgovICAgXCAgIC8g ICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgLyAgICAgXAp8IEwgfCAgIHwgMC4yNSAgMC4y NSAwLjAgLi4uIDAuNSAwLjAgfCAgfCAgVyAgfAp8IFIgfCA9IHwgMC4yNSAtMC4yNSAwLjAgLi4u IDAuMCAwLjUgfCAgfCAgWSAgfApcICAgLyAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAg LyAgfCAuLi4gfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgTHMg fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgUnMgfAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgLwo8L3ByZT4KPHAgY2xhc3M9 ImZpZ3VyZSI+RmlndXJlIDY6IFN0ZXJlbyBEb3dubWl4aW5nIE1hdHJpeCBmb3IgQ2hhbm5lbCBN YXBwaW5nIEZhbWlseSAyIGFuZCAzIC0gICBBbWJpc29uaWMgQ2hhbm5lbHMgUGx1cyBhIE5vbi1k aWVnZXRpYyBTdGVyZW8gU3RyZWFtPC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjUiPjxhIGhyZWY9 IiNyZmMuc2VjdGlvbi41Ij41LjwvYT4gPGEgaHJlZj0iI3NlY3VyaXR5IiBpZD0ic2VjdXJpdHki PlNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC9hPjwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi41LnAu MSI+SW1wbGVtZW50YXRpb25zIG9mIHRoZSBPZ2cgY29udGFpbmVyIG5lZWQgdGFrZSBhcHByb3By aWF0ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbnRvIGFjY291bnQsIGFzIG91dGxpbmVkIGlu IFNlY3Rpb24gMTAgb2YgPGEgaHJlZj0iI1JGQzc4NDUiPltSRkM3ODQ1XTwvYT4uICBUaGUgZXh0 ZW5zaW9uIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCByZXF1aXJlcyB0aGF0IHNlbWFudGljIG1l YW5pbmcgYmUgYXNzaWduZWQgdG8gbW9yZSBjaGFubmVscyB0aGFuIHRoZSBleGlzdGluZyBPZ2cg Zm9ybWF0IHJlcXVpcmVzLiAgU2luY2UgbW9yZSBhbGxvY2F0aW9ucyB3aWxsIGJlIHJlcXVpcmVk IHRvIGVuY29kZSBhbmQgZGVjb2RlIHRoZXNlIHNlbWFudGljYWxseSBtZWFuaW5nZnVsIGNoYW5u ZWxzLCBjYXJlIHNob3VsZCBiZSB0YWtlbiBpbiBhbnkgbmV3IGFsbG9jYXRpb24gcGF0aHMuICBJ bXBsZW1lbnRhdGlvbnMgTVVTVCBOT1Qgb3ZlcnJ1biB0aGVpciBhbGxvY2F0ZWQgbWVtb3J5IG5v ciByZWFkIGZyb20gdW5pbml0aWFsaXplZCBtZW1vcnkgd2hlbiBtYW5hZ2luZyB0aGUgYW1iaXNv bmljIGNoYW5uZWwgbWFwcGluZy4gIDwvcD4KPGgxIGlkPSJyZmMuc2VjdGlvbi42Ij48YSBocmVm PSIjcmZjLnNlY3Rpb24uNiI+Ni48L2E+IDxhIGhyZWY9IiNpYW5hIiBpZD0iaWFuYSI+SUFOQSBD b25zaWRlcmF0aW9uczwvYT48L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uNi5wLjEiPlRoaXMgZG9j dW1lbnQgdXBkYXRlcyB0aGUgSUFOQSBNZWRpYSBUeXBlcyByZWdpc3RyeSAiT3B1cyBDaGFubmVs IE1hcHBpbmcgRmFtaWxpZXMiIHRvIGFkZCB0d28gbmV3IGFzc2lnbm1lbnRzLiAgPC9wPgo8dGFi bGUgY2VsbHBhZGRpbmc9IjMiIGNlbGxzcGFjaW5nPSIwIiBjbGFzcz0idHQgZnVsbCBjZW50ZXIi PgogIDx0aGVhZD4KICAgIDx0cj4KICAgICAgPHRoIGNsYXNzPSJsZWZ0Ij5WYWx1ZTwvdGg+CiAg ICAgIDx0aCBjbGFzcz0ibGVmdCI+UmVmZXJlbmNlPC90aD4KICAgIDwvdHI+CiAgPC90aGVhZD4K ICA8dGJvZHk+CiAgICA8dHI+CiAgICAgIDx0ZCBjbGFzcz0ibGVmdCI+MjwvdGQ+CiAgICAgIDx0 ZCBjbGFzcz0ibGVmdCI+VGhpcyBEb2N1bWVudCA8YSBocmVmPSIjY2hhbm5lbF9tYXBwaW5nXzIi PlNlY3Rpb24gMy4xPC9hPjwvdGQ+CiAgICA8L3RyPgogICAgPHRyPgogICAgICA8dGQgY2xhc3M9 ImxlZnQiPjM8L3RkPgogICAgICA8dGQgY2xhc3M9ImxlZnQiPlRoaXMgRG9jdW1lbnQgPGEgaHJl Zj0iI2NoYW5uZWxfbWFwcGluZ18zIj5TZWN0aW9uIDMuMjwvYT48L3RkPgogICAgPC90cj4KICA8 L3Rib2R5Pgo8L3RhYmxlPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjciPjxhIGhyZWY9IiNyZmMuc2Vj dGlvbi43Ij43LjwvYT4gPGEgaHJlZj0iI0Fja25vd2xlZGdtZW50cyIgaWQ9IkFja25vd2xlZGdt ZW50cyI+QWNrbm93bGVkZ21lbnRzPC9hPjwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi43LnAuMSI+ VGhhbmtzIHRvIFRpbW90aHkgVGVycmliZXJyeSwgSmVhbi1NYXJjIFZhbGluLCBNYXJrIEhhcnJp cywgTWFyY2luIEdvcnplbCBhbmQgQW5kcmV3IEFsbGVuIGZvciB0aGVpciBndWlkYW5jZSBhbmQg dmFsdWFibGUgY29udHJpYnV0aW9ucyB0byB0aGlzIGRvY3VtZW50LiAgPC9wPgo8aDEgaWQ9InJm Yy5yZWZlcmVuY2VzIj48YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMiPjguPC9hPiBSZWZlcmVuY2Vz PC9oMT4KPGgxIGlkPSJyZmMucmVmZXJlbmNlcy4xIj48YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMu MSI+OC4xLjwvYT4gTm9ybWF0aXZlIFJlZmVyZW5jZXM8L2gxPgo8dGFibGU+CiAgPHRib2R5Pgog ICAgPHRyPgogICAgICA8dGQgY2xhc3M9InJlZmVyZW5jZSI+CiAgICAgICAgPGIgaWQ9IlJGQzIx MTkiPltSRkMyMTE5XTwvYj4KICAgICAgPC90ZD4KICAgICAgPHRkIGNsYXNzPSJ0b3AiPjxhPkJy YWRuZXIsIFMuPC9hPiwgIjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIx MTkiPktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2 ZWxzPC9hPiIsIEJDUCAxNCwgUkZDIDIxMTksIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAx OTk3LjwvdGQ+CiAgICA8L3RyPgogICAgPHRyPgogICAgICA8dGQgY2xhc3M9InJlZmVyZW5jZSI+ CiAgICAgICAgPGIgaWQ9IlJGQzY3MTYiPltSRkM2NzE2XTwvYj4KICAgICAgPC90ZD4KICAgICAg PHRkIGNsYXNzPSJ0b3AiPjxhPlZhbGluLCBKTS48L2E+LCA8YT5Wb3MsIEsuPC9hPiBhbmQgPGE+ VC4gVGVycmliZXJyeTwvYT4sICI8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2NzE2Ij5EZWZpbml0aW9uIG9mIHRoZSBPcHVzIEF1ZGlvIENvZGVjPC9hPiIsIFJGQyA2NzE2 LCBET0kgMTAuMTc0ODcvUkZDNjcxNiwgU2VwdGVtYmVyIDIwMTIuPC90ZD4KICAgIDwvdHI+CiAg ICA8dHI+CiAgICAgIDx0ZCBjbGFzcz0icmVmZXJlbmNlIj4KICAgICAgICA8YiBpZD0iUkZDNzg0 NSI+W1JGQzc4NDVdPC9iPgogICAgICA8L3RkPgogICAgICA8dGQgY2xhc3M9InRvcCI+PGE+VGVy cmliZXJyeSwgVC48L2E+LCA8YT5MZWUsIFIuPC9hPiBhbmQgPGE+Ui4gR2lsZXM8L2E+LCAiPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzg0NSI+T2dnIEVuY2Fwc3VsYXRp b24gZm9yIHRoZSBPcHVzIEF1ZGlvIENvZGVjPC9hPiIsIFJGQyA3ODQ1LCBET0kgMTAuMTc0ODcv UkZDNzg0NSwgQXByaWwgMjAxNi48L3RkPgogICAgPC90cj4KICAgIDx0cj4KICAgICAgPHRkIGNs YXNzPSJyZWZlcmVuY2UiPgogICAgICAgIDxiIGlkPSJhbWJpeCI+W2FtYml4XTwvYj4KICAgICAg PC90ZD4KICAgICAgPHRkIGNsYXNzPSJ0b3AiPjxhPk5hY2hiYXIsIEMuPC9hPiwgPGE+Wm90dGVy LCBGLjwvYT4sIDxhPkRlbGVmbGllLCBFLjwvYT4gYW5kIDxhPkEuIFNvbnRhY2NoaTwvYT4sICI8 YSBocmVmPSJodHRwOi8vaWVtLmt1Zy5hYy5hdC9maWxlYWRtaW4vbWVkaWEvaWVtL3Byb2plY3Rz LzIwMTEvYW1iaXNvbmljczExX25hY2hiYXJfem90dGVyX3NvbnRhY2NoaV9kZWxlZmxpZS5wZGYi PkFNQklYIC0gQSBTVUdHRVNURUQgQU1CSVNPTklDUyBGT1JNQVQ8L2E+IiwgSnVuZSAyMDExLjwv dGQ+CiAgICA8L3RyPgogIDwvdGJvZHk+CjwvdGFibGU+CjxoMSBpZD0icmZjLnJlZmVyZW5jZXMu MiI+PGEgaHJlZj0iI3JmYy5yZWZlcmVuY2VzLjIiPjguMi48L2E+IEluZm9ybWF0aXZlIFJlZmVy ZW5jZXM8L2gxPgo8dGFibGU+CiAgPHRib2R5PgogICAgPHRyPgogICAgICA8dGQgY2xhc3M9InJl ZmVyZW5jZSI+CiAgICAgICAgPGIgaWQ9Imdlcnpvbjc1Ij5bZ2Vyem9uNzVdPC9iPgogICAgICA8 L3RkPgogICAgICA8dGQgY2xhc3M9InRvcCI+PGE+R2Vyem9uLCBNLjwvYT4sICI8YSBocmVmPSJo dHRwOi8vd3d3Lm1pY2hhZWxnZXJ6b25waG90b3Mub3JnLnVrL2FydGljbGVzL0FtYmlzb25pY3Ml MjAxLnBkZiI+QW1iaXNvbmljcy4gUGFydCBvbmU6IEdlbmVyYWwgc3lzdGVtIGRlc2NyaXB0aW9u PC9hPiIsIEF1Z3VzdCAxOTc1LjwvdGQ+CiAgICA8L3RyPgogICAgPHRyPgogICAgICA8dGQgY2xh c3M9InJlZmVyZW5jZSI+CiAgICAgICAgPGIgaWQ9ImRhbmllbDA0Ij5bZGFuaWVsMDRdPC9iPgog ICAgICA8L3RkPgogICAgICA8dGQgY2xhc3M9InRvcCI+PGE+RGFuaWVsLCBKLjwvYT4gYW5kIDxh PlMuIE1vcmVhdTwvYT4sICI8YSBocmVmPSJodHRwOi8vcGNmYXJpbmEuZW5nLnVuaXByLml0L1B1 YmxpYy9waGQtdGhlc2lzL2FlczExNiUyMGhpZ2gtcGFzc2VkJTIwaG9hLnBkZiI+RnVydGhlciBT dHVkeSBvZiBTb3VuZCBGaWVsZCBDb2Rpbmcgd2l0aCBIaWdoZXIgT3JkZXIgQW1iaXNvbmljczwv YT4iLCBNYXkgMjAwNC48L3RkPgogICAgPC90cj4KICA8L3Rib2R5Pgo8L3RhYmxlPgo8aDEgaWQ9 InJmYy5hdXRob3JzIj4KICA8YSBocmVmPSIjcmZjLmF1dGhvcnMiPkF1dGhvcnMnIEFkZHJlc3Nl czwvYT4KPC9oMT4KPGRpdiBjbGFzcz0iYXZvaWRicmVhayI+CiAgPGFkZHJlc3MgY2xhc3M9InZj YXJkIj4KCTxzcGFuIGNsYXNzPSJ2Y2FyZGxpbmUiPgoJICA8c3BhbiBjbGFzcz0iZm4iPkphbiBT a29nbHVuZDwvc3Bhbj4gCgkgIDxzcGFuIGNsYXNzPSJuIGhpZGRlbiI+CgkJPHNwYW4gY2xhc3M9 ImZhbWlseS1uYW1lIj5Ta29nbHVuZDwvc3Bhbj4KCSAgPC9zcGFuPgoJPC9zcGFuPgoJPHNwYW4g Y2xhc3M9Im9yZyB2Y2FyZGxpbmUiPkdvb2dsZSBJbmMuPC9zcGFuPgoJPHNwYW4gY2xhc3M9ImFk ciI+CgkgIDxzcGFuIGNsYXNzPSJ2Y2FyZGxpbmUiPjE2MDAgQW1waGl0aGVhdHJlIFBhcmt3YXk8 L3NwYW4+CgoJICA8c3BhbiBjbGFzcz0idmNhcmRsaW5lIj4KCQk8c3BhbiBjbGFzcz0ibG9jYWxp dHkiPk1vdW50YWluIFZpZXc8L3NwYW4+LCAgCgkJPHNwYW4gY2xhc3M9InJlZ2lvbiI+Q0E8L3Nw YW4+IAoJCTxzcGFuIGNsYXNzPSJjb2RlIj45NDA0Mzwvc3Bhbj4KCSAgPC9zcGFuPgoJICA8c3Bh biBjbGFzcz0iY291bnRyeS1uYW1lIHZjYXJkbGluZSI+VVNBPC9zcGFuPgoJPC9zcGFuPgoJPHNw YW4gY2xhc3M9InZjYXJkbGluZSI+RU1haWw6IDxhIGhyZWY9Im1haWx0bzpqa3NAZ29vZ2xlLmNv bSI+amtzQGdvb2dsZS5jb208L2E+PC9zcGFuPgoKICA8L2FkZHJlc3M+CjwvZGl2PjxkaXYgY2xh c3M9ImF2b2lkYnJlYWsiPgogIDxhZGRyZXNzIGNsYXNzPSJ2Y2FyZCI+Cgk8c3BhbiBjbGFzcz0i dmNhcmRsaW5lIj4KCSAgPHNwYW4gY2xhc3M9ImZuIj5NaWNoYWVsIEdyYWN6eWs8L3NwYW4+IAoJ ICA8c3BhbiBjbGFzcz0ibiBoaWRkZW4iPgoJCTxzcGFuIGNsYXNzPSJmYW1pbHktbmFtZSI+R3Jh Y3p5azwvc3Bhbj4KCSAgPC9zcGFuPgoJPC9zcGFuPgoJPHNwYW4gY2xhc3M9Im9yZyB2Y2FyZGxp bmUiPkdvb2dsZSBJbmMuPC9zcGFuPgoJPHNwYW4gY2xhc3M9ImFkciI+CgkgIDxzcGFuIGNsYXNz PSJ2Y2FyZGxpbmUiPjE2MDAgQW1waGl0aGVhdHJlIFBhcmt3YXk8L3NwYW4+CgoJICA8c3BhbiBj bGFzcz0idmNhcmRsaW5lIj4KCQk8c3BhbiBjbGFzcz0ibG9jYWxpdHkiPk1vdW50YWluIFZpZXc8 L3NwYW4+LCAgCgkJPHNwYW4gY2xhc3M9InJlZ2lvbiI+Q0E8L3NwYW4+IAoJCTxzcGFuIGNsYXNz PSJjb2RlIj45NDA0Mzwvc3Bhbj4KCSAgPC9zcGFuPgoJICA8c3BhbiBjbGFzcz0iY291bnRyeS1u YW1lIHZjYXJkbGluZSI+VVNBPC9zcGFuPgoJPC9zcGFuPgoJPHNwYW4gY2xhc3M9InZjYXJkbGlu ZSI+RU1haWw6IDxhIGhyZWY9Im1haWx0bzptZ3JhY3p5a0Bnb29nbGUuY29tIj5tZ3JhY3p5a0Bn b29nbGUuY29tPC9hPjwvc3Bhbj4KCiAgPC9hZGRyZXNzPgo8L2Rpdj4KCjwvYm9keT4KPC9odG1s Pgo= --94eb2c08340c00420d054b6c0d63 Content-Type: text/xml; charset=US-ASCII; name="draft-ietf-codec-ambisonics-02.xml" Content-Disposition: attachment; filename="draft-ietf-codec-ambisonics-02.xml" Content-Transfer-Encoding: base64 Content-ID: <15af7f78d41f459c6d43> X-Attachment-Id: 15af7f78d41f459c6d43 PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nYXNjaWknPz4KPCFET0NUWVBFIHJmYyBTWVNU RU0gInJmYzI2MjkuZHRkIj4KPD9yZmMgdG9jPSJ5ZXMiIHN5bXJlZnM9InllcyIgPz4KPHJmYyBp cHI9InRydXN0MjAwOTAyIiBjYXRlZ29yeT0ic3RkIiBkb2NOYW1lPSJkcmFmdC1pZXRmLWNvZGVj LWFtYmlzb25pY3MtMDIiIG9ic29sZXRlcz0iIiB1cGRhdGVzPSIiIHN1Ym1pc3Npb25UeXBlPSJJ RVRGIiB4bWw6bGFuZz0iZW4iPgogIDxmcm9udD4KICAgIDx0aXRsZSBhYmJyZXY9Ik9wdXMgQW1i aXNvbmljcyI+QW1iaXNvbmljcyBpbiBhbiBPZ2cgT3B1cyBDb250YWluZXI8L3RpdGxlPgogICAg PGF1dGhvciBpbml0aWFscz0iSi4iIHN1cm5hbWU9IlNrb2dsdW5kIiBmdWxsbmFtZT0iSmFuIFNr b2dsdW5kIj4KICAgICAgPG9yZ2FuaXphdGlvbj5Hb29nbGUgSW5jLjwvb3JnYW5pemF0aW9uPgog ICAgICA8YWRkcmVzcz4KICAgICAgICA8cG9zdGFsPgogICAgICAgICAgPHN0cmVldD4xNjAwIEFt cGhpdGhlYXRyZSBQYXJrd2F5PC9zdHJlZXQ+CiAgICAgICAgICA8Y2l0eT5Nb3VudGFpbiBWaWV3 PC9jaXR5PgogICAgICAgICAgPHJlZ2lvbj5DQTwvcmVnaW9uPgogICAgICAgICAgPGNvZGU+OTQw NDM8L2NvZGU+CiAgICAgICAgICA8Y291bnRyeT5VU0E8L2NvdW50cnk+CiAgICAgICAgPC9wb3N0 YWw+CiAgICAgICAgPGVtYWlsPmprc0Bnb29nbGUuY29tPC9lbWFpbD4KICAgICAgPC9hZGRyZXNz PgogICAgPC9hdXRob3I+CiAgICA8YXV0aG9yIGluaXRpYWxzPSJNLkcuIiBzdXJuYW1lPSJHcmFj enlrIiBmdWxsbmFtZT0iTWljaGFlbCBHcmFjenlrIj4KICAgICAgPG9yZ2FuaXphdGlvbj5Hb29n bGUgSW5jLjwvb3JnYW5pemF0aW9uPgogICAgICA8YWRkcmVzcz4KICAgICAgICA8cG9zdGFsPgog ICAgICAgICAgPHN0cmVldD4xNjAwIEFtcGhpdGhlYXRyZSBQYXJrd2F5PC9zdHJlZXQ+CiAgICAg ICAgICA8Y2l0eT5Nb3VudGFpbiBWaWV3PC9jaXR5PgogICAgICAgICAgPHJlZ2lvbj5DQTwvcmVn aW9uPgogICAgICAgICAgPGNvZGU+OTQwNDM8L2NvZGU+CiAgICAgICAgICA8Y291bnRyeT5VU0E8 L2NvdW50cnk+CiAgICAgICAgPC9wb3N0YWw+CiAgICAgICAgPGVtYWlsPm1ncmFjenlrQGdvb2ds ZS5jb208L2VtYWlsPgogICAgICA8L2FkZHJlc3M+CiAgICA8L2F1dGhvcj4KICAgIDxkYXRlIGRh eT0iMTciIG1vbnRoPSJNYXJjaCIgeWVhcj0iMjAxNyIvPgogICAgPGFyZWE+UkFJPC9hcmVhPgog ICAgPHdvcmtncm91cD5jb2RlYzwvd29ya2dyb3VwPgogICAgPGFic3RyYWN0PgogICAgICA8dD5U aGlzIGRvY3VtZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBPZ2cgZm9ybWF0IHRvIGVu Y2Fwc3VsYXRlIGFtYmlzb25pY3MgY29kZWQgdXNpbmcgdGhlIE9wdXMgYXVkaW8gY29kZWMuICA8 L3Q+CiAgICA8L2Fic3RyYWN0PgogIDwvZnJvbnQ+CiAgPG1pZGRsZT4KICAgIDxzZWN0aW9uIGFu Y2hvcj0iaW50cm8iIHRpdGxlPSJJbnRyb2R1Y3Rpb24iIHRvYz0iZGVmYXVsdCI+CiAgICAgIDx0 PkFtYmlzb25pY3MgaXMgYSByZXByZXNlbnRhdGlvbiBmb3JtYXQgZm9yIHRocmVlIGRpbWVuc2lv bmFsIHNvdW5kIGZpZWxkcyB3aGljaCBjYW4gYmUgdXNlZCBmb3Igc3Vycm91bmQgc291bmQgYW5k IGltbWVyc2l2ZSB2aXJ0dWFsIApyZWFsaXR5IHBsYXliYWNrLiAgU2VlIDx4cmVmIHRhcmdldD0i Z2Vyem9uNzUiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIvPiBhbmQgPHhyZWYgdGFy Z2V0PSJkYW5pZWwwNCIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0Ii8+CmZvciB0ZWNo bmljYWwgZGV0YWlscyBvbiB0aGUgYW1iaXNvbmljcyBmb3JtYXQuICBGb3IgdGhlIHB1cnBvc2Vz IG9mIHRoaXMgZG9jdW1lbnQsIGFtYmlzb25pY3MgY2FuIGJlIGNvbnNpZGVyZWQgYSBtdWx0aWNo YW5uZWwgYXVkaW8gc3RyZWFtLiAKIEEgc2VwYXJhdGUgc3RlcmVvIHN0cmVhbSBjYW4gYmUgdXNl ZCBhbG9uZ3NpZGUgdGhlIGFtYmlzb25pY3MgaW4gYSBoZWFkLXRyYWNrZWQgdmlydHVhbCByZWFs aXR5IGV4cGVyaWVuY2UgdG8gcHJvdmlkZSBzby1jYWxsZWQgbm9uLWRpZWdldGljIGF1ZGlvIC0g YXVkaW8gd2hpY2ggc2hvdWxkIHJlbWFpbiB1bmNoYW5nZWQgYnkgbGlzdGVuZXIgaGVhZCByb3Rh dGlvbjsgZS5nLiwgbmFycmF0aW9uIG9yIHN0ZXJlbyBtdXNpYy4gIE9nZyBpcyBhIGdlbmVyYWwg cHVycG9zZSBjb250YWluZXIsIHN1cHBvcnRpbmcgYXVkaW8sIHZpZGVvLCBhbmQgb3RoZXIgbWVk aWEuICAKSXQgY2FuIGJlIHVzZWQgdG8gZW5jYXBzdWxhdGUgYXVkaW8gc3RyZWFtcyBjb2RlZCB1 c2luZyB0aGUgT3B1cyBjb2RlYy4gIFNlZSA8eHJlZiB0YXJnZXQ9IlJGQzY3MTYiIHBhZ2Vubz0i ZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIvPiBhbmQgPHhyZWYgdGFyZ2V0PSJSRkM3ODQ1IiBwYWdl bm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiLz4gZm9yIHRlY2huaWNhbCBkZXRhaWxzIG9uIHRo ZSBPcHVzIGNvZGVjIGFuZCBpdHMgZW5jYXBzdWxhdGlvbiBpbiB0aGUgT2dnIGNvbnRhaW5lciBy ZXNwZWN0aXZlbHkuICA8L3Q+CiAgICAgIDx0PlRoaXMgZG9jdW1lbnQgZXh0ZW5kcyB0aGUgT2dn IGZvcm1hdCBieSBkZWZpbmluZyB0d28gbmV3IGNoYW5uZWwgbWFwcGluZyBmYW1pbGllcyBmb3Ig ZW5jb2RpbmcgYW1iaXNvbmljcy4gVGhlIE9nZyBPcHVzIGZvcm1hdCAKaXMgZXh0ZW5kZWQgaW5k aXJlY3RseSBieSBhZGRpbmcgYW4gaXRlbSB3aXRoIHZhbHVlIDIgb3IgMyB0byB0aGUgSUFOQSAi T3B1cyBDaGFubmVsIE1hcHBpbmcgRmFtaWxpZXMiIHJlZ2lzdHJ5LiAgV2hlbiAyIG9yIDMgYXJl IHVzZWQgCmFzIHRoZSBDaGFubmVsIE1hcHBpbmcgRmFtaWx5IE51bWJlciBpbiBhbiBPZ2cgc3Ry ZWFtLCB0aGUgc2VtYW50aWMgbWVhbmluZyBvZiB0aGUgY2hhbm5lbHMgaW4gdGhlIG11bHRpY2hh bm5lbCBPcHVzIHN0cmVhbSBpcyBvbmUgb2YgCnRoZSBhbWJpc29uaWNzIGxheW91dHMgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50LiBUaGlzIG1hcHBpbmcgY2FuIGFsc28gYmUgdXNlZCBpbiBvdGhl ciBjb250ZXh0cyB3aGljaCBtYWtlIHVzZSBvZiB0aGUgY2hhbm5lbCBtYXBwaW5ncwogZGVmaW5l ZCBieSB0aGUgT3B1cyBDaGFubmVsIE1hcHBpbmcgRmFtaWxpZXMgcmVnaXN0cnkuICA8L3Q+CiAg ICA8L3NlY3Rpb24+CiAgICA8c2VjdGlvbiBhbmNob3I9InRlcm1pbm9sb2d5IiB0aXRsZT0iVGVy bWlub2xvZ3kiIHRvYz0iZGVmYXVsdCI+CiAgICAgIDx0PlRoZSBrZXkgd29yZHMgIk1VU1QiLCAi TVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJT SE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQg Ik9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNj cmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyMTE5IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRl ZmF1bHQiLz4uICA8L3Q+CiAgICA8L3NlY3Rpb24+CiAgICA8c2VjdGlvbiBhbmNob3I9Im9nZ19l eHRlbnNpb24iIHRpdGxlPSJBbWJpc29uaWNzIFdpdGggT2dnIE9wdXMiIHRvYz0iZGVmYXVsdCI+ CiAgICAgIDx0PkFtYmlzb25pY3MgY2FuIGJlIGVuY2Fwc3VsYXRlZCBpbiB0aGUgT2dnIGZvcm1h dCBieSBlbmNvZGluZyB3aXRoIHRoZSBPcHVzIGNvZGVjIGFuZCBzZXR0aW5nIHRoZSBjaGFubmVs IG1hcHBpbmcgZmFtaWx5IHZhbHVlIHRvIDIgb3IgMyBpbiB0aGUgT2dnIGlkZW50aWZpY2F0aW9u IGhlYWRlciAoSUQpLiBBIGRlbXV4ZXIgaW1wbGVtZW50YXRpb24gZW5jb3VudGVyaW5nIENoYW5u ZWwgTWFwcGluZyBGYW1pbHkgMiBvciBGYW1pbHkgMyBNVVNUIGludGVycHJldCB0aGUgT3B1cyBz dHJlYW0gYXMgY29udGFpbmluZyBhbWJpc29uaWNzIHdpdGggdGhlIGZvcm1hdCBkZXNjcmliZWQg aW4gPHhyZWYgdGFyZ2V0PSJjaGFubmVsX21hcHBpbmdfMiIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0 PSJkZWZhdWx0Ii8+IG9yIDx4cmVmIHRhcmdldD0iY2hhbm5lbF9tYXBwaW5nXzMiIHBhZ2Vubz0i ZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIvPiwgcmVzcGVjdGl2ZWx5LiAgPC90PgogICAgICA8c2Vj dGlvbiBhbmNob3I9ImNoYW5uZWxfbWFwcGluZ18yIiB0aXRsZT0iQ2hhbm5lbCBNYXBwaW5nIEZh bWlseSAyIiB0b2M9ImRlZmF1bHQiPgogICAgICAgIDx0PkFsbG93ZWQgbnVtYmVycyBvZiBjaGFu bmVsczogKDEgKyBuKV4yICsgMmogZm9yIG4gPSAwLi4uMTQgYW5kIGogPSAwIG9yIDEsIHdoZXJl IG4gZGVub3RlcyB0aGUgKGhpZ2hlc3QpIGFtYmlzb25pYyBvcmRlciBhbmQgaiB3aGV0aGVyIG9y IG5vdCB0aGVyZSBpcyBhIHNlcGFyYXRlIG5vbi1kaWVnZXRpYyBzdGVyZW8gc3RyZWFtLiAgVGhp cyBjb3JyZXNwb25kcyB0byBwZXJpcGhvbmljIGFtYmlzb25pY3MgZnJvbSB6ZXJvdGggdG8gZm91 cnRlZW50aCBvcmRlciBwbHVzIHBvdGVudGlhbGx5IHR3byBjaGFubmVscyBvZiBub24tZGllZ2V0 aWMgc3RlcmVvLiAgRXhwbGljaXRseSB0aGUgYWxsb3dlZCBudW1iZXIgb2YgY2hhbm5lbHMgYXJl IDEsIDMsIDQsIDYsIDksIDExLCAxNiwgMTgsIDI1LCAyNywgMzYsIDM4LCA0OSwgNTEsIDY0LCA2 NiwgODEsIDgzLCAxMDAsIDEwMiwgMTIxLCAxMjMsIDE0NCwgMTQ2LCAxNjksIDE3MSwgMTk2LCAx OTgsIDIyNSwgMjI3LiAgPC90PgogICAgICAgIDx0PlRoaXMgY2hhbm5lbCBtYXBwaW5nIHVzZXMg dGhlIHNhbWUgY2hhbm5lbCBtYXBwaW5nIHRhYmxlIGZvcm1hdCB1c2VkIGJ5IGNoYW5uZWwgbWFw cGluZyBmYW1pbHkgMS4gVGhlIG91dHB1dCBjaGFubmVscyBhcmUgYW1iaXNvbmljIGNvbXBvbmVu dHMgb3JkZXJlZCBpbiBBbWJpc29uaWMgQ2hhbm5lbCBOdW1iZXIgKEFDTikgb3JkZXIsIGRlZmlu ZWQgaW4gPHhyZWYgdGFyZ2V0PSJBQ04iIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIv PiwgZm9sbG93ZWQgYnkgdHdvIG9wdGlvbmFsIGNoYW5uZWxzIG9mIG5vbi1kaWVnZXRpYyBzdGVy ZW8gaW5kZXhlZCAobGVmdCwgcmlnaHQpLiAgPC90PgogICAgICAgIDxmaWd1cmUgYW5jaG9yPSJB Q04iIHRpdGxlPSJBbWJpc29uaWMgQ2hhbm5lbCBOdW1iZXIgKEFDTikiIGFsaWduPSJjZW50ZXIi IHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj4KICAgICAg ICAgIDxhcnR3b3JrIGFsaWduPSJjZW50ZXIiIHhtbDpzcGFjZT0icHJlc2VydmUiIG5hbWU9IiIg dHlwZT0iIiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPgpBQ04gPSBuICogKG4gKyAxKSArIG0s CmZvciBvcmRlciBuIGFuZCBkZWdyZWUgbS4KPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgog ICAgICAgIDx0PkZvciB0aGUgYW1iaXNvbmljIGNoYW5uZWxzIHRoZSBBQ04gY29tcG9uZW50IGNv cnJlc3BvbmRzIHRvIGNoYW5uZWwgaW5kZXggYXMgayA9IEFDTi4gVGhlIHJldmVyc2UgY29ycmVz cG9uZGVuY2UgY2FuIGFsc28gYmUgY29tcHV0ZWQgZm9yIGFuIGFtYmlzb25pYyBjaGFubmVsIHdp dGggaW5kZXggay4gIDwvdD4KICAgICAgICA8ZmlndXJlIGFuY2hvcj0iaW52ZXJzZUFDTiIgdGl0 bGU9IkFtYmlzb25pYyBEZWdyZWUgYW5kIE9yZGVyICAgZnJvbSBBQ04iIGFsaWduPSJjZW50ZXIi IHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj4KICAgICAg ICAgIDxhcnR3b3JrIGFsaWduPSJjZW50ZXIiIHhtbDpzcGFjZT0icHJlc2VydmUiIG5hbWU9IiIg dHlwZT0iIiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPgpvcmRlciAgIG4gPSBmbG9vcihzcXJ0 KGspKSwKZGVncmVlICBtID0gayAtIG4gKiAobiArIDEpLgo8L2FydHdvcms+CiAgICAgICAgPC9m aWd1cmU+CiAgPHQ+IE5vdGUgdGhhdCBjaGFubmVsIG1hcHBpbmcgZmFtaWx5IDIgYWxsb3dzIGZv ciBzby1jYWxsZWQgbWl4ZWQgb3JkZXIgYW1iaXNvbmljIHJlcHJlc2VudGF0aW9ucyB3aGVyZSBv bmx5IGEgc3Vic2V0IG9mIHRoZSBmdWxsIGFtYmlzb25pYyBvcmRlciBudW1iZXIgb2YgY2hhbm5l bHMgaXMgdXNlZC4gQnkgc3BlY2lmeWluZyB0aGUgZnVsbCBudW1iZXIgaW4gdGhlIGNoYW5uZWwg Y291bnQgZmllbGQsIHRoZSBpbmFjdGl2ZSBBQ05zIGNhbiB0aGVuIGJlIGluZGljYXRlZCBpbiB0 aGUgY2hhbm5lbCBtYXBwaW5nIGZpZWxkIHVzaW5nIHRoZSBpbmRleCAyNTUuPC90PgogICAgICAg IDx0PkFtYmlzb25pYyBjaGFubmVscyBhcmUgZXhwZWN0ZWQgdG8gYmUgbm9ybWFsaXplZCB3aXRo IFNjaG1pZHQgU2VtaS1Ob3JtYWxpemF0aW9uIChTTjNEKS4gIFRoZSBpbnRlcnByZXRhdGlvbiBv ZiB0aGUgYW1iaXNvbmljcyBzaWduYWwgYXMgd2VsbCBhcyBkZXRhaWxlZCBkZWZpbml0aW9ucyBv ZiBBQ04gY2hhbm5lbCBvcmRlcmluZyBhbmQgU04zRCBub3JtYWxpemF0aW9uIGFyZSBkZXNjcmli ZWQgaW4gPHhyZWYgdGFyZ2V0PSJhbWJpeCIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0 Ii8+IFNlY3Rpb24gMi4xLiAgPC90PgogICAgICA8L3NlY3Rpb24+CiAgICAgIDxzZWN0aW9uIGFu Y2hvcj0iY2hhbm5lbF9tYXBwaW5nXzMiIHRpdGxlPSJDaGFubmVsIE1hcHBpbmcgRmFtaWx5IDMi IHRvYz0iZGVmYXVsdCI+CiAgICAgICAgPHQ+IEFsbG93ZWQgbnVtYmVycyBvZiBjaGFubmVsczog KDEgKyBuKV4yICsgMmogZm9yIG4gPSAwLi4uMTIgYW5kIGogPSAwIG9yIDEsIHdoZXJlIG4gZGVu b3RlcyB0aGUgKGhpZ2hlc3QpIGFtYmlzb25pYyBvcmRlciBhbmQgaiB3aGV0aGVyIG9yIG5vdCB0 aGVyZSBpcyBhIHNlcGFyYXRlIG5vbi1kaWVnZXRpYyBzdGVyZW8gc3RyZWFtLiAgVGhpcyBjb3Jy ZXNwb25kcyB0byBwZXJpcGhvbmljIGFtYmlzb25pY3MgZnJvbSB6ZXJvdGggdG8gdHdlbGZ0aCBv cmRlciBwbHVzIHBvdGVudGlhbGx5IHR3byBjaGFubmVscyBvZiBub24tZGllZ2V0aWMgc3RlcmVv LiAgRXhwbGljaXRseSB0aGUgYWxsb3dlZCBudW1iZXIgb2YgY2hhbm5lbHMgYXJlIDEsIDMsIDQs IDYsIDksIDExLCAxNiwgMTgsIDI1LCAyNywgMzYsIDM4LCA0OSwgNTEsIDY0LCA2NiwgODEsIDgz LCAxMDAsIDEwMiwgMTIxLCAxMjMsIDE0NCwgMTQ2LCAxNjksIDE3MS4KPC90Pjx0PkluIHRoaXMg bWFwcGluZywgQyBvdXRwdXQgY2hhbm5lbHMgKHRoZSBjaGFubmVsIGNvdW50KSBhcmUgZ2VuZXJh dGVkIGF0IHRoZSBkZWNvZGVyIGJ5IG11bHRpcGx5aW5nIEsgPSBOICsgTSBkZWNvZGVkIGNoYW5u ZWxzIHdpdGggYSBkZXNpZ25hdGVkIGRlbWl4aW5nIG1hdHJpeCwgRCwgaGF2aW5nIEMgcm93cyBh bmQgSyBjb2x1bW5zLiBIZXJlLCBOIGRlbm90ZXMgdGhlIG51bWJlciBvZiBzdHJlYW1zIGVuY29k ZWQgYW5kIE0gdGhlIG51bWJlciBvZiB0aGVzZSB3aGljaCBhcmUgY291cGxlZCB0byBwcm9kdWNl IHR3byBjaGFubmVscy4gICBBcyBmb3IgY2hhbm5lbCBtYXBwaW5nIGZhbWlseSAyIHRoaXMgbWFw cGluZyBmYW1pbHkgYWxzbyBhbGxvd3MgZm9yIGVuY29kaW5nIGFuZCBkZWNvZGluZyBvZiBmdWxs IG9yZGVyIGFtYmlzb25pY3MsIG1peGVkIG9yZGVyIGFtYmlzb25pY3MsIGFuZCBmb3Igbm9uLWRp ZWdldGljIHN0ZXJlbyBjaGFubmVscywgYnV0IGFsc28gaGFzIHRoZSBhZGRlZCBmbGV4aWJpbGl0 eSBvZiBtaXhpbmcgY2hhbm5lbHMuICBMZXQgWCBkZW5vdGUgYSBjb2x1bW4gdmVjdG9yIGNvbnRh aW5pbmcgSyBkZWNvZGVkIGNoYW5uZWxzIFgxLCBYMiwgLi4uLCBYSyAoZnJvbSBOIHN0cmVhbXMp LCBhbmQgbGV0IFMgZGVub3RlIGEgY29sdW1uIHZlY3RvciBjb250YWluaW5nIEMgb3V0cHV0IHN0 cmVhbXMgUzEsIFMyLCAuLi4sIFNDLiBUaGVuIFMgPSBEIFgsIGkuZS4sIDwvdD4KICAgICAgICA8 ZmlndXJlIGFuY2hvcj0iZGVtaXhpbmciIHRpdGxlPSJEZW1peGluZyBpbiBDaGFubmVsIE1hcHBp bmcgRmFtaWx5IDMiIGFsaWduPSJjZW50ZXIiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWx0PSIi IHdpZHRoPSIiIGhlaWdodD0iIj4KICAgICAgICAgIDxhcnR3b3JrIGFsaWduPSJjZW50ZXIiIHht bDpzcGFjZT0icHJlc2VydmUiIG5hbWU9IiIgdHlwZT0iIiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0 PSIiPgovICAgICBcICAgLyAgICAgICAgICAgICAgICAgICBcIC8gICAgIFwKfCBTMSAgfCAgIHwg RDExICBEMTIgIC4uLiBEMUsgfCB8IFgxICB8CnwgUzIgIHwgICB8IEQyMSAgRDIyICAuLi4gRDJL IHwgfCBYMiAgfAp8IC4uLiB8ID0gfCAuLi4gIC4uLiAgLi4uIC4uLiB8IHwgLi4uIHwKfCBTQyAg fCAgIHwgREMxICBEQzIgIC4uLiBEQ0sgfCB8IFhLICB8ClwgICAgIC8gICBcICAgICAgICAgICAg ICAgICAgIC8gXCAgICAgLwo8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+ VGhlIG1hdHJpeCBNVVNUIGJlIHByb3ZpZGVkIGFzIHNpZGUgaW5mb3JtYXRpb24gYW5kIE1VU1Qg YmUgc3RvcmVkIGluIHRoZSBjaGFubmVsIG1hcHBpbmcgdGFibGUgcGFydCBvZiB0aGUgaWRlbnRp ZmljYXRpb24gaGVhZGVyLCBjLmYuIHNlY3Rpb24gNS4xLjEgaW4gPHhyZWYgdGFyZ2V0PSJSRkM3 ODQ1IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiLz4uIFRoZSBtYXRyaXggcmVwbGFj ZXMgdGhlIG5lZWQgZm9yIGEgY2hhbm5lbCBtYXBwaW5nIGZpZWxkIGFuZCBmb3IgY2hhbm5lbCBt YXBwaW5nIGZhbWlseSAzIHRoZSBtYXBwaW5nIHRhYmxlIGhhcyB0aGUgZm9sbG93aW5nIGxheW91 dDogPC90PgogICAgICAgIDxmaWd1cmUgYW5jaG9yPSJjaGFubmVsX21hcHBpbmciIHRpdGxlPSJD aGFubmVsIE1hcHBpbmcgVGFibGUgZm9yICBDaGFubmVsIE1hcHBpbmcgRmFtaWx5IDMiIGFsaWdu PSJjZW50ZXIiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0i Ij4KICAgICAgICAgIDxhcnR3b3JrIGFsaWduPSJjZW50ZXIiIHhtbDpzcGFjZT0icHJlc2VydmUi IG5hbWU9IiIgdHlwZT0iIiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPgoKIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLSstKy0r LSstKy0rLSstKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IFN0cmVhbSBDb3VudCAgfAorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwp8IENvdXBsZWQgQ291bnQgfCBEZW1peGluZyBN YXRyaXggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOgorLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKPC9hcnR3b3Jr PgogICAgICAgIDwvZmlndXJlPgogICAgICAgIDx0PlRoZSBmaWVsZHMgaW4gdGhlIGNoYW5uZWwg bWFwcGluZyB0YWJsZSBoYXZlIHRoZSBmb2xsb3dpbmcgbWVhbmluZzogPGxpc3Qgc3R5bGU9Im51 bWJlcnMiIGNvdW50ZXI9IjgiPjx0PlN0cmVhbSBDb3VudCAnTicgKDggYml0cywgdW5zaWduZWQp OiA8dnNwYWNlIGJsYW5rTGluZXM9IjEiLz4gVGhpcyBpcyB0aGUgdG90YWwgbnVtYmVyIG9mIHN0 cmVhbXMgZW5jb2RlZCBpbiBlYWNoIE9nZyBwYWNrZXQuICA8dnNwYWNlIGJsYW5rTGluZXM9IjEi Lz4gPC90Pjx0PkNvdXBsZWQgU3RyZWFtIENvdW50ICdNJyAoOCBiaXRzLCB1bnNpZ25lZCk6IDx2 c3BhY2UgYmxhbmtMaW5lcz0iMSIvPiBUaGlzIGlzIHRoZSBudW1iZXIgb2YgdGhlIE4gc3RyZWFt cyB3aG9zZSBkZWNvZGVycyBhcmUgdG8gYmUgY29uZmlndXJlZCB0byBwcm9kdWNlIHR3byBjaGFu bmVscyAoc3RlcmVvKS4gIDx2c3BhY2UgYmxhbmtMaW5lcz0iMSIvPiA8L3Q+PHQ+RGVtaXhpbmcg TWF0cml4ICgxNipLKkMgYml0cywgc2lnbmVkKTogPHZzcGFjZSBibGFua0xpbmVzPSIxIi8+IFRo ZSBjb2VmZmljaWVudHMgb2YgdGhlIGRlbWl4aW5nIG1hdHJpeCBzdG9yZWQgY29sdW1uLXdpc2Ug YXMgMTYtYml0LCBzaWduZWQsIHR3bydzIGNvbXBsZW1lbnQgZml4ZWQtcG9pbnQgdmFsdWVzIHdp dGggMTUgZnJhY3Rpb25hbCBiaXRzIChRMTUpLiBJZiBuZWVkZWQsIHRoZSBvdXRwdXQgZ2FpbiBm aWVsZCBjYW4gYmUgdXNlZCBmb3IgYSBub3JtYWxpemF0aW9uIHNjYWxlLiBGb3IgbWl4ZWQgb3Jk ZXIgYW1iaXNvbmljIHJlcHJlc2VudGF0aW9ucywgdGhlIHNpbGVudCBBQ04gY2hhbm5lbHMgYXJl IGluZGljYXRlZCBieSBhbGwgemVyb3MgaW4gdGhlIGNvcnJlc3BvbmRpbmcgcm93cyBvZiB0aGUg ZGVtaXhpbmcgbWF0cml4LiA8L3Q+PC9saXN0PiA8L3Q+CiAgICAgICAgPHQ+Tm90ZSB0aGF0IDx4 cmVmIHRhcmdldD0iUkZDNzg0NSIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0Ii8+IHNw ZWNpZmllcyB0aGF0IHRoZSBpZGVudGlmaWNhdGlvbiBoZWFkZXIgY2Fubm90IGV4Y2VlZCBvbmUg InBhZ2UiLCB3aGljaCBpcyA2NSwwMjUgb2N0ZXRzLiBUaGlzIGxpbWl0cyB0aGUgYW1iaXNvbmlj IG9yZGVyIHRvIGJlIGxvd2VyIHRoYW4gMTIuICBBbHNvIG5vdGUgdGhhdCB0aGUgdG90YWwgb3V0 cHV0IGNoYW5uZWwgbnVtYmVyLCBDLCBNVVNUIGJlIHNldCBpbiB0aGUgM3JkIGZpZWxkIG9mIHRo ZSBpZGVudGlmaWNhdGlvbiBoZWFkZXIuICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KICAgIDwvc2Vj dGlvbj4KICAgIDxzZWN0aW9uIGFuY2hvcj0iZG93bm1peGluZyIgdGl0bGU9IkRvd25taXhpbmci IHRvYz0iZGVmYXVsdCI+CiAgICAgICAgICAgICA8dD5BbiBPZ2cgT3B1cyBwbGF5ZXIgTUFZIHVz ZSB0aGUgbWF0cml4IGluIEZpZ3VyZSA8eHJlZiB0YXJnZXQ9InN0ZXJlb19kb3dubWl4X21hdHJp eF8xIiBmb3JtYXQ9ImNvdW50ZXIiIHBhZ2Vubz0iZmFsc2UiLz4gdG8gaW1wbGVtZW50IGRvd25t aXhpbmcgZnJvbSBtdWx0aWNoYW5uZWwgZmlsZXMgdXNpbmcgY2hhbm5lbCBtYXBwaW5nIGZhbWls eSAyIGFuZCAzLCB3aGVuIHRoZXJlIGlzIG5vIG5vbi1kaWVnZXRpYyBzdGVyZW8uICBUaGlzIGRv d25taXhpbmcgaXMga25vd24gdG8gZ2l2ZSBhY2NlcHRhYmxlIHJlc3VsdHMgZm9yIHN0ZXJlbyBk b3dubWl4aW5nIGZyb20gYW1iaXNvbmljcy4gVGhlIGZpcnN0IGFuZCBzZWNvbmQgYW1iaXNvbmlj IGNoYW5uZWxzIGFyZSBrbm93biBhcyAiVyIgYW5kICJZIiByZXNwZWN0aXZlbHkuICA8L3Q+CiAg ICAgICAgPGZpZ3VyZSBhbmNob3I9InN0ZXJlb19kb3dubWl4X21hdHJpeF8xIiB0aXRsZT0iU3Rl cmVvIERvd25taXhpbmcgTWF0cml4IGZvciBDaGFubmVsIE1hcHBpbmcgRmFtaWx5IDIgYW5kIDMg LSAgIG9ubHkgQW1iaXNvbmljIENoYW5uZWxzIiBhbGlnbj0iY2VudGVyIiBzdXBwcmVzcy10aXRs ZT0iZmFsc2UiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+CiAgICAgICAgICA8YXJ0d29yayBh bGlnbj0iY2VudGVyIiB4bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIiIHR5cGU9IiIgYWx0PSIi IHdpZHRoPSIiIGhlaWdodD0iIj4KLyAgIFwgICAvICAgICAgICAgICAgICAgICAgXCAvICAgICBc CnwgTCB8ICAgfCAwLjUgIDAuNSAwLjAgLi4uIHwgfCAgVyAgfAp8IFIgfCA9IHwgMC41IC0wLjUg MC4wIC4uLiB8IHwgIFkgIHwKXCAgIC8gICBcICAgICAgICAgICAgICAgICAgLyB8IC4uLiB8CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgLwo8L2FydHdvcms+CiAgICAgICAgPC9m aWd1cmU+CiAgICAgICAgPHQ+VGhlIGZpcnN0IGFtYmlzb25pYyBjaGFubmVsIChXKSBpcyBhIG1v bm8gYXVkaW8gc3RyZWFtIHdoaWNoIHJlcHJlc2VudHMgdGhlIGF2ZXJhZ2UgYXVkaW8gc2lnbmFs IG92ZXIgYWxsIGRpcmVjdGlvbnMuIFNpbmNlIFcgaXMgbm90IGRpcmVjdGlvbmFsLCBPZ2cgT3B1 cyBwbGF5ZXJzIE1BWSB1c2UgVyBkaXJlY3RseSBmb3IgbW9ubyBwbGF5YmFjay4gIDwvdD4KICAg ICAgICA8dD5JZiBhIG5vbi1kaWVnZXRpYyBzdGVyZW8gdHJhY2sgaXMgcHJlc2VudCwgdGhlIHBs YXllciBNQVkgdXNlIHRoZSBtYXRyaXggaW4gRmlndXJlIDx4cmVmIHRhcmdldD0ic3RlcmVvX2Rv d25taXhfbWF0cml4XzIiIGZvcm1hdD0iY291bnRlciIgcGFnZW5vPSJmYWxzZSIvPiBmb3IgZG93 bm1peGluZy4gIExzIGFuZCBScyBkZW5vdGUgdGhlIHR3byBub24tZGllZ2V0aWMgc3RlcmVvIGNo YW5uZWxzLiAgPC90PgogICAgICAgIDxmaWd1cmUgYW5jaG9yPSJzdGVyZW9fZG93bm1peF9tYXRy aXhfMiIgdGl0bGU9IlN0ZXJlbyBEb3dubWl4aW5nIE1hdHJpeCBmb3IgQ2hhbm5lbCBNYXBwaW5n IEZhbWlseSAyIGFuZCAzIC0gICBBbWJpc29uaWMgQ2hhbm5lbHMgUGx1cyBhIE5vbi1kaWVnZXRp YyBTdGVyZW8gU3RyZWFtIiBhbGlnbj0iY2VudGVyIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFs dD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+CiAgICAgICAgICA8YXJ0d29yayBhbGlnbj0iY2VudGVy IiB4bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIiIHR5cGU9IiIgYWx0PSIiIHdpZHRoPSIiIGhl aWdodD0iIj4KLyAgIFwgICAvICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgIC8gICAgIFwK fCBMIHwgICB8IDAuMjUgIDAuMjUgMC4wIC4uLiAwLjUgMC4wIHwgIHwgIFcgIHwKfCBSIHwgPSB8 IDAuMjUgLTAuMjUgMC4wIC4uLiAwLjAgMC41IHwgIHwgIFkgIHwKXCAgIC8gICBcICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC8gIHwgLi4uIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgIExzIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgIFJzIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgICAg IC8KPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgIAogICAgICAKICAgIDwvc2VjdGlv bj4KICAgIDxzZWN0aW9uIGFuY2hvcj0ic2VjdXJpdHkiIHRpdGxlPSJTZWN1cml0eSBDb25zaWRl cmF0aW9ucyIgdG9jPSJkZWZhdWx0Ij4KICAgICAgPHQ+SW1wbGVtZW50YXRpb25zIG9mIHRoZSBP Z2cgY29udGFpbmVyIG5lZWQgdGFrZSBhcHByb3ByaWF0ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBpbnRvIGFjY291bnQsIGFzIG91dGxpbmVkIGluIFNlY3Rpb24gMTAgb2YgPHhyZWYgdGFyZ2V0 PSJSRkM3ODQ1IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiLz4uICBUaGUgZXh0ZW5z aW9uIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCByZXF1aXJlcyB0aGF0IHNlbWFudGljIG1lYW5p bmcgYmUgYXNzaWduZWQgdG8gbW9yZSBjaGFubmVscyB0aGFuIHRoZSBleGlzdGluZyBPZ2cgZm9y bWF0IHJlcXVpcmVzLiAgU2luY2UgbW9yZSBhbGxvY2F0aW9ucyB3aWxsIGJlIHJlcXVpcmVkIHRv IGVuY29kZSBhbmQgZGVjb2RlIHRoZXNlIHNlbWFudGljYWxseSBtZWFuaW5nZnVsIGNoYW5uZWxz LCBjYXJlIHNob3VsZCBiZSB0YWtlbiBpbiBhbnkgbmV3IGFsbG9jYXRpb24gcGF0aHMuICBJbXBs ZW1lbnRhdGlvbnMgTVVTVCBOT1Qgb3ZlcnJ1biB0aGVpciBhbGxvY2F0ZWQgbWVtb3J5IG5vciBy ZWFkIGZyb20gdW5pbml0aWFsaXplZCBtZW1vcnkgd2hlbiBtYW5hZ2luZyB0aGUgYW1iaXNvbmlj IGNoYW5uZWwgbWFwcGluZy4gIDwvdD4KICAgIDwvc2VjdGlvbj4KICAgIDxzZWN0aW9uIGFuY2hv cj0iaWFuYSIgdGl0bGU9IklBTkEgQ29uc2lkZXJhdGlvbnMiIHRvYz0iZGVmYXVsdCI+CiAgICAg IDx0PlRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0aGUgSUFOQSBNZWRpYSBUeXBlcyByZWdpc3RyeSAi T3B1cyBDaGFubmVsIE1hcHBpbmcgRmFtaWxpZXMiIHRvIGFkZCB0d28gbmV3IGFzc2lnbm1lbnRz LiAgPC90PgogICAgICA8dGV4dHRhYmxlIHRpdGxlPSIiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIg YWxpZ249ImNlbnRlciIgc3R5bGU9ImZ1bGwiPgogICAgICAgIDx0dGNvbCBhbGlnbj0ibGVmdCI+ VmFsdWU8L3R0Y29sPgogICAgICAgIDx0dGNvbCBhbGlnbj0ibGVmdCI+UmVmZXJlbmNlPC90dGNv bD4KICAgICAgICA8Yz4yPC9jPgogICAgICAgIDxjPlRoaXMgRG9jdW1lbnQgPHhyZWYgdGFyZ2V0 PSJjaGFubmVsX21hcHBpbmdfMiIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0Ii8+PC9j PgogICAgICAgIDxjPjM8L2M+CiAgICAgICAgPGM+VGhpcyBEb2N1bWVudCA8eHJlZiB0YXJnZXQ9 ImNoYW5uZWxfbWFwcGluZ18zIiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiLz48L2M+ CiAgICAgIDwvdGV4dHRhYmxlPgogICAgPC9zZWN0aW9uPgogICAgPHNlY3Rpb24gYW5jaG9yPSJB Y2tub3dsZWRnbWVudHMiIHRpdGxlPSJBY2tub3dsZWRnbWVudHMiIHRvYz0iZGVmYXVsdCI+CiAg ICAgIDx0PlRoYW5rcyB0byBUaW1vdGh5IFRlcnJpYmVycnksIEplYW4tTWFyYyBWYWxpbiwgTWFy ayBIYXJyaXMsIE1hcmNpbiBHb3J6ZWwgYW5kIEFuZHJldyBBbGxlbiBmb3IgdGhlaXIgZ3VpZGFu Y2UgYW5kIHZhbHVhYmxlIGNvbnRyaWJ1dGlvbnMgdG8gdGhpcyBkb2N1bWVudC4gIDwvdD4KICAg IDwvc2VjdGlvbj4KICA8L21pZGRsZT4KICA8YmFjaz4KICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJO b3JtYXRpdmUgUmVmZXJlbmNlcyI+PHJlZmVyZW5jZSBhbmNob3I9IlJGQzIxMTkiIHRhcmdldD0i aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTkiIHF1b3RlLXRpdGxlPSJ0cnVl Ij48ZnJvbnQ+PHRpdGxlPktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVx dWlyZW1lbnQgTGV2ZWxzPC90aXRsZT48YXV0aG9yIGluaXRpYWxzPSJTLiIgc3VybmFtZT0iQnJh ZG5lciIgZnVsbG5hbWU9IlMuIEJyYWRuZXIiPjxvcmdhbml6YXRpb24vPjwvYXV0aG9yPjxkYXRl IHllYXI9IjE5OTciIG1vbnRoPSJNYXJjaCIvPjxhYnN0cmFjdD48dD5JbiBtYW55IHN0YW5kYXJk cyB0cmFjayBkb2N1bWVudHMgc2V2ZXJhbCB3b3JkcyBhcmUgdXNlZCB0byBzaWduaWZ5IHRoZSBy ZXF1aXJlbWVudHMgaW4gdGhlIHNwZWNpZmljYXRpb24uICBUaGVzZSB3b3JkcyBhcmUgb2Z0ZW4g Y2FwaXRhbGl6ZWQuIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGVzZSB3b3JkcyBhcyB0aGV5IHNo b3VsZCBiZSBpbnRlcnByZXRlZCBpbiBJRVRGIGRvY3VtZW50cy4gIFRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIGFuIEludGVybmV0IEJlc3QgQ3VycmVudCBQcmFjdGljZXMgZm9yIHRoZSBJbnRlcm5l dCBDb21tdW5pdHksIGFuZCByZXF1ZXN0cyBkaXNjdXNzaW9uIGFuZCBzdWdnZXN0aW9ucyBmb3Ig aW1wcm92ZW1lbnRzLjwvdD48L2Fic3RyYWN0PjwvZnJvbnQ+PHNlcmllc0luZm8gbmFtZT0iQkNQ IiB2YWx1ZT0iMTQiLz48c2VyaWVzSW5mbyBuYW1lPSJSRkMiIHZhbHVlPSIyMTE5Ii8+PHNlcmll c0luZm8gbmFtZT0iRE9JIiB2YWx1ZT0iMTAuMTc0ODcvUkZDMjExOSIvPjwvcmVmZXJlbmNlPiA8 cmVmZXJlbmNlIGFuY2hvcj0iUkZDNjcxNiIgdGFyZ2V0PSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2luZm8vcmZjNjcxNiIgcXVvdGUtdGl0bGU9InRydWUiPjxmcm9udD48dGl0bGU+RGVmaW5p dGlvbiBvZiB0aGUgT3B1cyBBdWRpbyBDb2RlYzwvdGl0bGU+PGF1dGhvciBpbml0aWFscz0iSk0u IiBzdXJuYW1lPSJWYWxpbiIgZnVsbG5hbWU9IkpNLiBWYWxpbiI+PG9yZ2FuaXphdGlvbi8+PC9h dXRob3I+PGF1dGhvciBpbml0aWFscz0iSy4iIHN1cm5hbWU9IlZvcyIgZnVsbG5hbWU9IksuIFZv cyI+PG9yZ2FuaXphdGlvbi8+PC9hdXRob3I+PGF1dGhvciBpbml0aWFscz0iVC4iIHN1cm5hbWU9 IlRlcnJpYmVycnkiIGZ1bGxuYW1lPSJULiBUZXJyaWJlcnJ5Ij48b3JnYW5pemF0aW9uLz48L2F1 dGhvcj48ZGF0ZSB5ZWFyPSIyMDEyIiBtb250aD0iU2VwdGVtYmVyIi8+PGFic3RyYWN0Pjx0PlRo aXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgT3B1cyBpbnRlcmFjdGl2ZSBzcGVlY2ggYW5kIGF1ZGlv IGNvZGVjLiBPcHVzIGlzIGRlc2lnbmVkIHRvIGhhbmRsZSBhIHdpZGUgcmFuZ2Ugb2YgaW50ZXJh Y3RpdmUgYXVkaW8gYXBwbGljYXRpb25zLCBpbmNsdWRpbmcgVm9pY2Ugb3ZlciBJUCwgdmlkZW9j b25mZXJlbmNpbmcsIGluLWdhbWUgY2hhdCwgYW5kIGV2ZW4gbGl2ZSwgZGlzdHJpYnV0ZWQgbXVz aWMgcGVyZm9ybWFuY2VzLiAgSXQgc2NhbGVzIGZyb20gbG93IGJpdHJhdGUgbmFycm93YmFuZCBz cGVlY2ggYXQgNiBrYml0L3MgdG8gdmVyeSBoaWdoIHF1YWxpdHkgc3RlcmVvIG11c2ljIGF0IDUx MCBrYml0L3MuICBPcHVzIHVzZXMgYm90aCBMaW5lYXIgUHJlZGljdGlvbiAoTFApIGFuZCB0aGUg TW9kaWZpZWQgRGlzY3JldGUgQ29zaW5lIFRyYW5zZm9ybSAoTURDVCkgdG8gYWNoaWV2ZSBnb29k IGNvbXByZXNzaW9uIG9mIGJvdGggc3BlZWNoIGFuZCBtdXNpYy4gIFtTVEFOREFSRFMtVFJBQ0td PC90PjwvYWJzdHJhY3Q+PC9mcm9udD48c2VyaWVzSW5mbyBuYW1lPSJSRkMiIHZhbHVlPSI2NzE2 Ii8+PHNlcmllc0luZm8gbmFtZT0iRE9JIiB2YWx1ZT0iMTAuMTc0ODcvUkZDNjcxNiIvPjwvcmVm ZXJlbmNlPiA8cmVmZXJlbmNlIGFuY2hvcj0iUkZDNzg0NSIgdGFyZ2V0PSJodHRwOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjNzg0NSIgcXVvdGUtdGl0bGU9InRydWUiPjxmcm9udD48dGl0 bGU+T2dnIEVuY2Fwc3VsYXRpb24gZm9yIHRoZSBPcHVzIEF1ZGlvIENvZGVjPC90aXRsZT48YXV0 aG9yIGluaXRpYWxzPSJULiIgc3VybmFtZT0iVGVycmliZXJyeSIgZnVsbG5hbWU9IlQuIFRlcnJp YmVycnkiPjxvcmdhbml6YXRpb24vPjwvYXV0aG9yPjxhdXRob3IgaW5pdGlhbHM9IlIuIiBzdXJu YW1lPSJMZWUiIGZ1bGxuYW1lPSJSLiBMZWUiPjxvcmdhbml6YXRpb24vPjwvYXV0aG9yPjxhdXRo b3IgaW5pdGlhbHM9IlIuIiBzdXJuYW1lPSJHaWxlcyIgZnVsbG5hbWU9IlIuIEdpbGVzIj48b3Jn YW5pemF0aW9uLz48L2F1dGhvcj48ZGF0ZSB5ZWFyPSIyMDE2IiBtb250aD0iQXByaWwiLz48YWJz dHJhY3Q+PHQ+VGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBPZ2cgZW5jYXBzdWxhdGlvbiBmb3Ig dGhlIE9wdXMgaW50ZXJhY3RpdmUgc3BlZWNoIGFuZCBhdWRpbyBjb2RlYy4gIFRoaXMgYWxsb3dz IGRhdGEgZW5jb2RlZCBpbiB0aGUgT3B1cyBmb3JtYXQgdG8gYmUgc3RvcmVkIGluIGFuIE9nZyBs b2dpY2FsIGJpdHN0cmVhbS48L3Q+PC9hYnN0cmFjdD48L2Zyb250PjxzZXJpZXNJbmZvIG5hbWU9 IlJGQyIgdmFsdWU9Ijc4NDUiLz48c2VyaWVzSW5mbyBuYW1lPSJET0kiIHZhbHVlPSIxMC4xNzQ4 Ny9SRkM3ODQ1Ii8+PC9yZWZlcmVuY2U+IDxyZWZlcmVuY2UgYW5jaG9yPSJhbWJpeCIgdGFyZ2V0 PSJodHRwOi8vaWVtLmt1Zy5hYy5hdC9maWxlYWRtaW4vbWVkaWEvaWVtL3Byb2plY3RzLzIwMTEv YW1iaXNvbmljczExX25hY2hiYXJfem90dGVyX3NvbnRhY2NoaV9kZWxlZmxpZS5wZGYiIHF1b3Rl LXRpdGxlPSJ0cnVlIj48ZnJvbnQ+PHRpdGxlPkFNQklYIC0gQSBTVUdHRVNURUQgQU1CSVNPTklD UyBGT1JNQVQ8L3RpdGxlPjxhdXRob3IgaW5pdGlhbHM9IkMuIiBzdXJuYW1lPSJOYWNoYmFyIiBm dWxsbmFtZT0iQ2hyaXN0aWFuIE5hY2hiYXIiLz48YXV0aG9yIGluaXRpYWxzPSJGLiIgc3VybmFt ZT0iWm90dGVyIiBmdWxsbmFtZT0iRnJhbnogWm90dGVyIi8+PGF1dGhvciBpbml0aWFscz0iRS4i IHN1cm5hbWU9IkRlbGVmbGllIiBmdWxsbmFtZT0iRXRpZW5uZSBEZWxlZmxpZSIvPjxhdXRob3Ig aW5pdGlhbHM9IkEuIiBzdXJuYW1lPSJTb250YWNjaGkiIGZ1bGxuYW1lPSJBbG9pcyBTb250YWNj aGkiLz48ZGF0ZSBtb250aD0iSnVuZSIgeWVhcj0iMjAxMSIvPjwvZnJvbnQ+PC9yZWZlcmVuY2U+ PC9yZWZlcmVuY2VzPgogICAgPHJlZmVyZW5jZXMgdGl0bGU9IkluZm9ybWF0aXZlIFJlZmVyZW5j ZXMiPgogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iZ2Vyem9uNzUiIHRhcmdldD0iaHR0cDovL3d3 dy5taWNoYWVsZ2Vyem9ucGhvdG9zLm9yZy51ay9hcnRpY2xlcy9BbWJpc29uaWNzJTIwMS5wZGYi IHF1b3RlLXRpdGxlPSJ0cnVlIj4KICAgICAgICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+QW1i aXNvbmljcy4gUGFydCBvbmU6IEdlbmVyYWwgc3lzdGVtIGRlc2NyaXB0aW9uPC90aXRsZT4KICAg ICAgICAgIDxhdXRob3IgaW5pdGlhbHM9Ik0uIiBzdXJuYW1lPSJHZXJ6b24iIGZ1bGxuYW1lPSJN aWNoYWVsIEdlcnpvbiIvPgogICAgICAgICAgPGRhdGUgbW9udGg9IkF1Z3VzdCIgeWVhcj0iMTk3 NSIvPgogICAgICAgIDwvZnJvbnQ+CiAgICAgIDwvcmVmZXJlbmNlPgogICAgICA8cmVmZXJlbmNl IGFuY2hvcj0iZGFuaWVsMDQiIHRhcmdldD0iaHR0cDovL3BjZmFyaW5hLmVuZy51bmlwci5pdC9Q dWJsaWMvcGhkLXRoZXNpcy9hZXMxMTYlMjBoaWdoLXBhc3NlZCUyMGhvYS5wZGYiIHF1b3RlLXRp dGxlPSJ0cnVlIj4KICAgICAgICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+RnVydGhlciBTdHVk eSBvZiBTb3VuZCBGaWVsZCBDb2Rpbmcgd2l0aCBIaWdoZXIgT3JkZXIgQW1iaXNvbmljczwvdGl0 bGU+CiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJKLiIgc3VybmFtZT0iRGFuaWVsIiBmdWxs bmFtZT0iSiYjMjMzO3ImIzI0NDttZSBEYW5pZWwiLz4KICAgICAgICAgIDxhdXRob3IgaW5pdGlh bHM9IlMuIiBzdXJuYW1lPSJNb3JlYXUiIGZ1bGxuYW1lPSJTJiMyMzM7YmFzdGllbiBNb3JlYXUi Lz4KICAgICAgICAgIDxkYXRlIG1vbnRoPSJNYXkiIHllYXI9IjIwMDQiLz4KICAgICAgICA8L2Zy b250PgogICAgICA8L3JlZmVyZW5jZT4KICAgIDwvcmVmZXJlbmNlcz4KICA8L2JhY2s+CjwvcmZj Pgo= --94eb2c08340c00420d054b6c0d63-- From oleinikov@gmail.com Tue Mar 21 02:06:21 2017 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 A13BE1296C4 for ; Tue, 21 Mar 2017 02:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JeggRfvAxmDT for ; Tue, 21 Mar 2017 02:06:19 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 3001A1296C6 for ; Tue, 21 Mar 2017 02:06:09 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id x35so125951646qtc.2 for ; Tue, 21 Mar 2017 02:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=K9mH7pBA4vFNwuOAhwdhB28p99jydwfxfF7dBEhRsSY=; b=DBrpAycsiKk6svd8QqV3nHYWu+1N5l/dehNspooa3aTiiVGxV5P61I27NfeYHs3dwb Sy6EkZywfw2k9vqhnB768jnukHPt/yOl4N0KZvnPVlquQeLVY1P4sMs4W9+gXp03mTHg o90+J8epngz1Z+3rAu2mp+KinYzXxtD1hQ89sC0R+6KVLd/xehREhiWuNi6g//MoqJTF BW3f1AxGGmx3n2QMBD0xvUIHEMl1lpHuLP8hK0suNBgCsZbKqfb33eCsbta3RY+0ltew 8j4LsVWQYzQotvJ7Obeh8/GTRo2CiyU/V5YXZz5ltNtnZMboBlXdaAzcuGM0+z9/vbJp sBoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K9mH7pBA4vFNwuOAhwdhB28p99jydwfxfF7dBEhRsSY=; b=ASoFS35uA8fZ7RSFNeTDmIfCQG2u6dHpHXPZIw05axdvBA/dHJ+c+mLSp5eeDKddwF pb2g1HluRZyBxf4r1X1XcP7TrsKisKAkwLwQ77ocQYZQloyaIJVltDIDyTB5ar0oEQfM n+J8WE3trqWkWqJP7RFsD94hos3xM1nJo3FWhgl39CdICa0xUtujD/KFBR5B+BBy3ZEa IEWp5lSwhSVDPRaZ52Wgi/TlxsZTTxxysMF4iF2/KG38WAxJn8c6OHIQn6cb9pv/evms gcunka37S2vwmRh7l24qZWz0AqOwl3H3FZJd4DEdbTwGvN6IR1RpH50iRLX8LSJKN36u hZPw== X-Gm-Message-State: AFeK/H2/KKDwJRAH3kPfV4eGKhKmqQEI4oIIBhbPOkyiQtS2Bjr0v1y4Z6bRzZzBbmz4nmIx779+GDZxJ2a+Lw== X-Received: by 10.237.59.150 with SMTP id r22mr29892785qte.100.1490087168095; Tue, 21 Mar 2017 02:06:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.148.48 with HTTP; Tue, 21 Mar 2017 02:06:07 -0700 (PDT) From: Oleinikoff D Date: Tue, 21 Mar 2017 14:36:07 +0530 Message-ID: To: codec@ietf.org Content-Type: multipart/alternative; boundary=001a114dc34656beeb054b39f44a Archived-At: X-Mailman-Approved-At: Mon, 27 Mar 2017 08:51:04 -0700 Subject: [codec] opus question X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 09:48:32 -0000 --001a114dc34656beeb054b39f44a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, i would like to use opus codec in my linphone application but i have a few questions , if someone with opus codec knowledge could help me out would appreciate 1. OPUS. Does this codec compress as well as package the data? 2. What is the output data structure from OPUS? 3. Is the output data streaming or packets? 4. What does the audio sampling scheme look like? and=E2=80=A6. 5. Within the audio sampling scheme, what are the values for silence? 6. Within the audio sampling scheme, what are the values for speech? thx in advance --=20 Best Regards Oleinikov D oleinikov@gmail.com Sent with Mailtrack --001a114dc34656beeb054b39f44a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

i would like t= o use opus codec in my linphone application

but i have = a few questions , if someone with opus codec knowledge could help me out wo= uld appreciate

  1. OPUS. Does this codec compress as well as= package the data?
  2. What is the output data structure from OPUS?
  3. Is the output data streaming or packets?
  4. What does the audio s= ampling scheme look like? and=E2=80=A6.
  5. Within the audio sampling s= cheme, what are the values for silence?
  6. Within the audio sampling scheme, wha= t are the values for speech?

thx in advance


--
Best Regards
Oleinik= ov D
oleinikov@= gmail.com



=C2=A0 Sent with Mailtrack
--001a114dc34656beeb054b39f44a-- From nobody Mon Mar 27 09:57:12 2017 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 A760F127077; Mon, 27 Mar 2017 09:57:10 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149063383065.30638.8427289756243648268@ietfa.amsl.com> Date: Mon, 27 Mar 2017 09:57:10 -0700 Archived-At: Subject: [codec] I-D Action: draft-ietf-codec-ambisonics-02.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 16:57:11 -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 of the IETF. Title : Ambisonics in an Ogg Opus Container Authors : Jan Skoglund Michael Graczyk Filename : draft-ietf-codec-ambisonics-02.txt Pages : 8 Date : 2017-03-27 Abstract: This document defines an extension to the Ogg format to encapsulate ambisonics coded using the Opus audio codec. 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-codec-ambisonics-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-ambisonics-02 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 Wed Mar 29 10:55:29 2017 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 889AB128D8B for ; Wed, 29 Mar 2017 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 MqvP0IDk-xKD for ; Wed, 29 Mar 2017 10:55:26 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 D244E12025C for ; Wed, 29 Mar 2017 10:55:26 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id p189so11013678pfp.1 for ; Wed, 29 Mar 2017 10:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thaumas-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Qo2mamEpAbRjCiXLKJ0Ktj6bgk4ZijFhQdezL8/d8Wc=; b=j2/rV+ZdJOgdkrYYFWmNQGyHygHgqx9jne+tm4y/7zxQqmWUO7W44r6oTvC/OUseXW pFEuiv1Awq2/psZ92QZy7PswlFIi7pphhrWf9KYk1ysHfytJDQL4eJtZ2WnQ6X6W4I3c K7kNyYTk7YnFBpqLcOiqxvJ4tNtgAB0eVImz4WTScv9e2lUkzMne1dc0Ai26B6zqger+ IWVez+eDvCnyOLQT0Vb/3zon4UmAYxfl1/fXr0LaKFA5Y5X7DK65NaTU6xrZ+XoODV0A OxkC7VKKybSUlkbOUTpXC6g95ziHlGzV2HXRRUB9oxvZ+M3amQoU7lvpvz+vbxwj6hsK Ov4g== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Qo2mamEpAbRjCiXLKJ0Ktj6bgk4ZijFhQdezL8/d8Wc=; b=QANzSxIwCrCQf+MT4ddaRSiHZxa2TWMGE5D0RIHwthmt7ZGln4Lfx4ezdZyjOxq8RB 3iDMFiCAtsK4wc4Rc3N9mCgJ4QQgWQWobtHnH9Uqy9o3qfOf5QkxttWXPb3wn2eBF3zD uhRS6knTKPDRYQQwu8Cclescj33CAJU/7mhpiEah3P6P7LYTQ1NRQKqcThfgrv13vkhA VttNVjiiHQv56X/tZLNR0v4/QIbb4evck2iNIl8bmr7QdlMvkLC7QMezKJrZPcgl0xwb SPMlaySoHzml8F/T+dZt0FRo4xai3oDXV7ba60m6IpogPfEI0ZLvBk1lNEjGFaBSmbI2 vFqQ== X-Gm-Message-State: AFeK/H0Dmcx4Z44SbbdSs67ggbwSInMoL+ZqdT3MYwVuJ7mEBKZQlWdk8HNphf9G1gjDOA== X-Received: by 10.99.56.17 with SMTP id f17mr1808767pga.228.1490810126171; Wed, 29 Mar 2017 10:55:26 -0700 (PDT) Received: from pteropus.lan (S0106185933484486.vc.shawcable.net. [174.7.172.49]) by smtp.gmail.com with ESMTPSA id t12sm14850166pfg.14.2017.03.29.10.55.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 10:55:25 -0700 (PDT) To: codec@ietf.org References: From: Ralph Giles Message-ID: <9ec85a7b-16e0-c494-8786-deb5039f8de8@thaumas.net> Date: Wed, 29 Mar 2017 10:55:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [codec] opus question X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 17:55:29 -0000 On 2017-03-21 2:06 AM, Oleinikoff D wrote: > i would like to use opus codec in my linphone application FWIW, I tried to answer this at https://stackoverflow.com/questions/42900658/using-opus-in-linphone/43100737#43100737 -r From nobody Fri Mar 31 15:31:23 2017 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 3DEB5129480 for ; Fri, 31 Mar 2017 15:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 32PCZSXRPD66 for ; Fri, 31 Mar 2017 15:31:19 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 51250124217 for ; Fri, 31 Mar 2017 15:30:45 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 19962C1F5A for ; Fri, 31 Mar 2017 22:30:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-vFwJgjg4Sa for ; Fri, 31 Mar 2017 22:30:44 +0000 (UTC) Received: from [172.20.3.61] (swissotel07.s.subnet.rcn.com [216.80.61.6]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 8DE51C0999 for ; Fri, 31 Mar 2017 22:30:41 +0000 (UTC) Message-ID: <58DED88F.7000102@xiph.org> Date: Fri, 31 Mar 2017 15:30:39 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [codec] IETF 98 Minutes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 22:31:21 -0000 Minutes for Thursday's session have been uploaded: https://www.ietf.org/proceedings/98/minutes/minutes-98-codec-00 Thanks to our note takers. Please send any additions or corrections to the chairs before April 21st.