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

Jean-Marc Valin <> Sat, 06 December 2014 09:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E56221A8FD2 for <>; Sat, 6 Dec 2014 01:46:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.288
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ylzjEb20b1Mp for <>; Sat, 6 Dec 2014 01:46:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A12AD1A8ABB for <>; Sat, 6 Dec 2014 01:46:04 -0800 (PST)
Received: from (unknown []) (Authenticated sender: by (Postfix) with ESMTPSA id 1D5C9F25D4; Sat, 6 Dec 2014 01:46:04 -0800 (PST)
Message-ID: <>
Date: Sat, 06 Dec 2014 04:46:03 -0500
From: Jean-Marc Valin <>
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 <>, David Singer <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: "" <>
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-Mailman-Version: 2.1.15
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: Sat, 06 Dec 2014 09:46:06 -0000

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

Version: GnuPG v1