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

Jean-Marc Valin <> Mon, 13 August 2018 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AC0A130E14 for <>; Mon, 13 Aug 2018 11:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iUi1HZhlE05o for <>; Mon, 13 Aug 2018 11:25:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB26D130DFE for <>; Mon, 13 Aug 2018 11:25:02 -0700 (PDT)
Received: by with SMTP id 27-v6so11672677qkv.0 for <>; Mon, 13 Aug 2018 11:25:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KnUq3UjfwdNfPUmxtYKBlYtVQG1zzJtknRZqe3cEw7Q=; b=cqEPFS/XOALyRbDwx6GsfKsNl8yWYoAH9Z6QKFzQn8iXnbfSBt/699wvXMYK9PHEqR ZWue6MNjUWjsucAzQ8rQggiqmvq0c5uEdu0p02huJ+e8jEMhVXdaD5nbIljdwjjoRkGQ cBQxVI6GKAQE3eNpffwHks0tkOydBxffekDKwUbw4v1engly5pE53+pawxL5lxNqQmqV +pNozv2nOa2b3ScCsy/VQTmgKNhu9x8lBe+JyZOXmupQ/Z/w/Gj2dKgPq8aeYfCDNaw8 Bgkh19GhDgWqO2ySYQie6sJey2dTSAFxy7Z/RULdf341hMlRznwm0AWX2nt0x3glDgif 6onw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KnUq3UjfwdNfPUmxtYKBlYtVQG1zzJtknRZqe3cEw7Q=; b=R9EUm4wkK/tvV9/kBnfTvHHm/uA4UyxvyJb81cAB+RxPF9S5ojSduwvGl0feC15O1v veexVQ94UkPCXkBRLB0+1aAAX5ixw4i9aZiiX0/ZNNNEL6JsDQY8Pac1zAFtzWsXEmw5 h0qYAvN+4zKhxSGJfRbEPsKSkqs9SXvx3D64lUxvTMjl9SGM0TrbQVcpUUd56reDkVHE yTJe2NnKMbnG6zFBrk9D0L1motoKDvOvMmoq937UxFxByB88ZD4p3UxsubHXYxl58isi fcjabxKz7DjF7EzNmsYanPG/QLDfkO03q8yJCdKF5eTsEY8BaCNZKWV+6AyWZm57QoBT +wSw==
X-Gm-Message-State: AOUpUlHlY/5Csv1q12IP6Lb7ZPKQSqRZN3YV2EuSprbAlnz02w8OO6wb UpN0FrVN2s1pj/vltRo+E7tvMw==
X-Google-Smtp-Source: AA+uWPz7oKYncK125DhllCqlmmIKecV+/+KMka6AraRraGagNdy6Z5J3o3nv1gHVWy4pwO7nDpmE5g==
X-Received: by 2002:a37:c65c:: with SMTP id b89-v6mr16577183qkj.421.1534184701892; Mon, 13 Aug 2018 11:25:01 -0700 (PDT)
Received: from ( []) by with ESMTPSA id e21-v6sm11831322qtc.67.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Aug 2018 11:25:00 -0700 (PDT)
To: Eric Rescorla <>, Jan Skoglund <>
Cc: Tim Terriberry <>,,,, The IESG <>
References: <> <> <>
From: Jean-Marc Valin <>
Message-ID: <>
Date: Mon, 13 Aug 2018 14:24:59 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [codec] Eric Rescorla's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Aug 2018 18:25:05 -0000

>     This is the reason the changes below to 7845 are necessary. I.e.,
>     not interpreting as channel mapping family 255, and instead “A
>     demuxer implementation encountering a 'channel mapping family'
>     value that it does not recognize SHOULD NOT attempt to decode the
>     packets“
> Sorry, I'm not following. Is your point that previously it would have
> misdecoded it and now it will just refuse to play? That's a reasonable
> design choice, but it seems like it was always present in this design,
> so why does it need to change?

Basically, RFC 7845 didn't consider the possibility of new mappings
requiring some kind of transformation (in the case of family 3, a matrix
multiply) between the Opus streams and what the decoder needs to output.
Once you consider that, then it makes no sense to output the "raw"
decoded streams as if it were a family 255.