Re: [rtcweb] Alternative consensus and MTI video codecs
Adam Roach <adam@nostrum.com> Fri, 08 November 2013 01:06 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F9921E817E for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 17:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.484
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnf0+wYYPXVX for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 17:06:11 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D626C21E816A for <rtcweb@ietf.org>; Thu, 7 Nov 2013 17:06:08 -0800 (PST)
Received: from dhcp-9081.meeting.ietf.org (dhcp-9081.meeting.ietf.org [31.133.144.129]) (authenticated bits=0) by shaman.nostrum.com (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 adam@nostrum.com)
Message-ID: <527C38FF.6040000@nostrum.com>
Date: Thu, 07 Nov 2013 17:06:07 -0800
From: Adam Roach <adam@nostrum.com>
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 <greg@xiph.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CAAS2fgQ730sjjv5Ly0_TFmdz=ryhPN13+A69_0_MedotHGEthg@mail.gmail.com>
In-Reply-To: <CAAS2fgQ730sjjv5Ly0_TFmdz=ryhPN13+A69_0_MedotHGEthg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 31.133.144.129 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] Alternative consensus and MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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. /a
- [rtcweb] H.261 vs No MTI (was: Alternative consen… cowwoc
- [rtcweb] Alternative consensus and MTI video code… Gregory Maxwell
- Re: [rtcweb] Alternative consensus and MTI video … Adam Roach
- Re: [rtcweb] Alternative consensus and MTI video … Gregory Maxwell
- Re: [rtcweb] Alternative consensus and MTI video … Ron
- Re: [rtcweb] Alternative consensus and MTI video … Adam Roach
- Re: [rtcweb] H.261 vs No MTI cowwoc
- [rtcweb] On the form of the question (was Re: Alt… Adam Roach
- Re: [rtcweb] H.261 vs No MTI Leon Geyser
- Re: [rtcweb] H.261 vs No MTI (was: Alternative co… Tim Panton
- Re: [rtcweb] H.261 vs No MTI Tim Panton
- Re: [rtcweb] H.261 vs No MTI Leon Geyser
- Re: [rtcweb] H.261 vs No MTI cb.list6
- Re: [rtcweb] On the form of the question (was Re:… Markus.Isomaki
- Re: [rtcweb] H.261 vs No MTI cowwoc
- Re: [rtcweb] H.261 vs No MTI cb.list6
- Re: [rtcweb] H.261 vs No MTI cowwoc
- Re: [rtcweb] On the form of the question (was Re:… Ron