Re: [codec] Comments on draft-ietf-codec-ambisonics-01

Jean-Marc Valin <> Sat, 18 February 2017 06:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B696612896F for <>; Fri, 17 Feb 2017 22:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jaaFHc5-PxWG for <>; Fri, 17 Feb 2017 22:02:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F1F7120726 for <>; Fri, 17 Feb 2017 22:02:58 -0800 (PST)
Received: by with SMTP id 129so2364496pgg.2 for <>; Fri, 17 Feb 2017 22:02:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=T+gNiMJ62OknP9jYUf5P6/RlPP2j1yLiRuMwNxvL7Rc=; b=Lo2ni86+MZTNkxyISA2jw66uNLWMWfykyNWu1fEVTrw+c4e5KJgcBhhyXNF5D7cn9U RSRJKrb7W2IrS4r7I6WQUKkbwR0GjZ44/OlZD11UU5ctKd5+riPEkiBDlc5RTTOlSTLy 16NalAp/QqMZQa5qpo69orLDX/EYtZo4BRLM1z7iBgrCD0bbYpRkrAl1YHkBiPJLaFBS q38Q1itsKBndYcUESNnMwER1MzzW+mReN9c2x1rEkgUYlTC5agF0VGZCeN1U0v5SveeV bywaXyCR7An/8Z5oiCWiKPT0vDxqR2aY1igptSa/JbRIyac8rEKxDveePOIw+wd1gRwz 6g8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=T+gNiMJ62OknP9jYUf5P6/RlPP2j1yLiRuMwNxvL7Rc=; b=KGF9rYmSSvQUTUUHILDkPER1FuEIHHdY8vN5UJOTgKhmRPjiOfPAm1yHzMhTga9kdi sOyySEifOF1XdZiujyv7PLiR0/9A+9yVcQ4Z4zo3wImmHvg7fyBL9cNIC8YfL5ACTuEZ zPzEdjnOB+TzuicioScAuoW1cTmCry9a3lri6VIDi2PYeMPTVx/eQw5NMdI4CVnABHg4 KoKkGsBvzpNG1vl/ODmY/M9xSoDHdIpY4hlbv6sf+oxWUIwQaOi+4JmAiyZXk6OUZBG9 Q83+DtzCQY7eo1IsLtBNa/3KTxQYLJSKyPUsg9O1Ci6HJJvYI0jGtCefS2Fw+Z67HGce 5Jzw==
X-Gm-Message-State: AMke39md0NlBzT7kvn4sVlNxM77l9piKoMsPGIGdqhweN8QsA6txmzksTC9XlqrEnk7eDQ==
X-Received: by with SMTP id l36mr16486079plg.166.1487397777987; Fri, 17 Feb 2017 22:02:57 -0800 (PST)
Received: from ([]) by with ESMTPSA id m21sm22930413pgh.4.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 22:02:57 -0800 (PST)
To: Jan Skoglund <>, "" <>
References: <>
From: Jean-Marc Valin <>
Message-ID: <>
Date: Sat, 18 Feb 2017 01:02:56 -0500
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-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: Sat, 18 Feb 2017 06:03:00 -0000

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

So based further discussions off-list with Mark and Tim, it seems like
there's a few issues with RFC7845 that would need to be addressed:

5.1.1.  Channel Mapping

>    The order and meaning of these
>    channels are defined by a channel mapping, which consists of the
>    'channel mapping family' octet and, for channel mapping families
>    other than family 0, a 'channel mapping table', as illustrated
>    in Figure 3.

This seems to impose that all other families have a channel mapping
table, which as I pointed out for family 3, isn't always appropriate. So
I think this draft should update RFC7845 to state that only the "Stream
Count" and "Coupled Count" fields are required for all families greater
than 0. The channel mapping table isn't required unless a particular
family defines it.  Undefined Channel Mappings

>    The remaining channel mapping families (2...254) are reserved.  A
>    demuxer implementation encountering a reserved 'channel mapping
>    family' value SHOULD act as though the value is 255.

If we change the channel mapping table to not be defined for all
families, then we would need to update this paragraph to state that
undefined families should be treated as 255, but assuming an "identity
ordering" rather than attempting to read a mapping table that may not
actually exist.

I also think we should officially mark families 250-254 (or maybe a
larger range?) as reserved for experimental features that have yet to be
assigned a permanent family number by IANA. For example, the Opus code
currently uses 254 and 253 to handle what would be families 2 and 3 ones
this draft becomes RFC.

Mark, Tim, did I forget anything?