Re: [rtcweb] confirming sense of the room: mti codec

Jean-Marc Valin <jmvalin@mozilla.com> Sat, 06 December 2014 09:46 UTC

Return-Path: <jmvalin@mozilla.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56221A8FD2 for <rtcweb@ietfa.amsl.com>; Sat, 6 Dec 2014 01:46:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.288
X-Spam-Level:
X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ylzjEb20b1Mp for <rtcweb@ietfa.amsl.com>; Sat, 6 Dec 2014 01:46:04 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (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 A12AD1A8ABB for <rtcweb@ietf.org>; Sat, 6 Dec 2014 01:46:04 -0800 (PST)
Received: from panoramix.jmvalin.ca (unknown [107.16.188.53]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 1D5C9F25D4; Sat, 6 Dec 2014 01:46:04 -0800 (PST)
Message-ID: <5482D05B.1050407@mozilla.com>
Date: Sat, 06 Dec 2014 04:46:03 -0500
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Bernard Aboba <bernard.aboba@gmail.com>, David Singer <singer@apple.com>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <54820E74.90201@mozilla.com> <FCDCD184-549C-4111-ACDB-7C466A2EE9D1@apple.com> <548260D2.2020703@nostrum.com> <A5667955-21FC-4596-A86A-0902408BCC12@apple.com> <94C89195-99FC-4807-B00B-1A94701C8724@gmail.com>
In-Reply-To: <94C89195-99FC-4807-B00B-1A94701C8724@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3xGG12vsbO0RL7I5SjD8NxdqMq0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 06 Dec 2014 09:46:06 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/12/14 10:31 PM, Bernard Aboba wrote:
> [BA] While this does appear to be a statement from an implementer 
> about support in their own product, it does not correctly 
> characterize the nature of the "consensus" as a whole. The 
> "consensus" here did not involve acceptance by RTCWEB implementers
> of the necessity for them to support both H.264 and VP8.  Had such
> a proposal been made it most probably would have failed. Instead
> the "consensus" call involved imposing an obligation on a subset
> of implementers without their agreement.  There is a term for
> *that*, but it isn't "consensus" - the 13 colonies called it
> "taxation without representation".

OK, so it's browsers implementer that matter now? Let's see, the
original position from Google and Mozilla -- who represent more than
50% of the market and (AFAIK) 100% of WebRTC browsers -- was
originally "VP8 or die". Despite that, the "VP8 or die" option failed
the consensus call (as did the "H.264 or die" option). Now, the same
implementers are agreeing to make VP8 *and* H.264 MTI, while rallying
some of the H.264 supporters (obviously not you) and you're still
thinking it's a minority imposing its will on the majority of browser
implementers? I'd like to understand what other outcome you're aiming
for here:
1) Call for consensus on "H.264 or die" until enough people in the
other camp get distracted;
2) No MTI, voice only ought to be good for everyone; or
3) Some other clever compromise we haven't yet heard of

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUgtBYAAoJEJ6/8sItn9q9CLQIAJPZ47KBo/1V3pY3KNWu3B4P
OrevkGyXLkaXG9NhxRJ8TsTGP/KK7GMAVArQJW5oYhpvgZ8vmKXfLV8AwjP8THjG
geXNbPpX7vW+FIKhzdtlIwG3teF44j9a9jMy4iLKBhV0N0msQUHnBw0aMtO2K7j3
/SFzeCVNRUYxmCa7GnHVztAXE9cOHfwjy4xEYNGcRn9Ds8GqJIJOCDSuuVqa/BJr
3pRdC4s1dsG8h9sxlwy17UDJHzjBHzwnxRLKbhSkLGw2aZJSMwdVMbKh967SQb8m
PJpo71d6UWr2bpZqVRMb5JmHV+8zl8oRqBn0K0Hm8A70mrcvLksqeExoD8fFGSk=
=u+CB
-----END PGP SIGNATURE-----