Re: [rtcweb] Alternative consensus and MTI video codecs

Adam Roach <> Fri, 08 November 2013 01:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1F9921E817E for <>; Thu, 7 Nov 2013 17:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.484
X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qnf0+wYYPXVX for <>; Thu, 7 Nov 2013 17:06:11 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id D626C21E816A for <>; Thu, 7 Nov 2013 17:06:08 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id rA8167cm013560 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Nov 2013 19:06:08 -0600 (CST) (envelope-from
Message-ID: <>
Date: Thu, 07 Nov 2013 17:06:07 -0800
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Gregory Maxwell <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] Alternative consensus and MTI video codecs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Nov 2013 01:06:11 -0000

On 11/7/13 16:41, Gregory Maxwell wrote:
> If we still believe from an engineering perspective that WebRTC ought
> to have one MTI video codec it still can, even though the counts were
> split:   We can invoke RFC 3929 4.4 and_flip a coin_.

I do not believe the decision under consideration qualifies for the 
process in section 4.4. As that section itself notes, random selection 
is only appropriate for something like deciding a numerical codepoint or 
a DNS prefix.

Our situation is radically different: there are a number of actual 
arguments to be made for both options.

I think an external review team (section 4.1) is a reasonable way 
forward, as it lets the decision rest on the merits that proponents of 
each approach have themselves put forth, without allowing partisan or 
emotional considerations to get in the way of facts.

I'll make an even stronger statement: I would contend that any strong 
push against the use of an external review team amounts to a tacit 
admission by an individual that the arguments for their preferred 
position are insufficiently compelling.

If anyone believes that their position logically follows from the known 
facts, then they would necessarily believe that a randomly-selected 
panel of neutral third parties will agree with them. If such a person 
thinks that the panel won't, perhaps they should reevaluate whether 
their arguments are grounded in facts and logic, or their own emotional 
investment in this decision.