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

Andrew Allen <> Mon, 08 December 2014 23:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3C2621A008B for <>; Mon, 8 Dec 2014 15:28:46 -0800 (PST)
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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U2Jex-YWtD6g for <>; Mon, 8 Dec 2014 15:28:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C86041A0062 for <>; Mon, 8 Dec 2014 15:28:43 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 08 Dec 2014 18:28:34 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 8 Dec 2014 18:28:34 -0500
Received: from ([fe80::28c6:fa1c:91c6:2e23]) by ([::1]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 18:28:34 -0500
From: Andrew Allen <>
To: Maire Reavy <>, "" <>
Thread-Topic: [rtcweb] confirming sense of the room: mti codec
Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgATTdwD//69UkA==
Date: Mon, 08 Dec 2014 23:28:33 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 08 Dec 2014 23:28:46 -0000

We are not re-opening this discussion. This list discussion is the decision making process.

What took place in Honolulu was only a consensus hum of those present in the room.

In IETF all decisions are made on the list and it was clearly stated by the chair in Honolulu that the decision would need to be endorsed on the list.

On 1) We have committed to an MTI video codec

I note the small word "an".

If we decide on two MTI video codecs then we have clearly failed to meet this commitment.

On 3) This is the only proposal that gets support from both camps

As David pointed out we are not in two monolithic camps (this isn't the cold war here). Different companies and different individuals have different positions for different reasons. The fact that some people who might have been perceived as being in "one camp" have found a way to agree to a "compromise" based upon a definition that doesn't force them in their product to implement what they don't agree to implement does not mean that the fundamental reason behind the difficulty in reaching consensus on MTI video codecs by those whose products would be forced to implement both codecs has changed.

It's very easy to agree to someone else to have to do something that you are not willing to do yourself.


-----Original Message-----
From: rtcweb [] On Behalf Of Maire Reavy
Sent: Monday, December 08, 2014 4:41 PM
Subject: Re: [rtcweb] confirming sense of the room: mti codec

On 12/5/2014 2:58 PM, Jean-Marc Valin wrote:
> Hash: SHA1
> Considering that:
> 1) We have committed to an MTI video codec
> 2) All consensus calls on "VP8 only" and "H.264 only" have failed
> 3) This is the only proposal that gets support from both camps I 
> strongly support this MTI proposal.
> Please, let's close this debate once and for all. This compromise is 
> by no means great, but it's much better than anything else we're going 
> to get otherwise (i.e. more wasted time and still no MTI).
A big +1

We have spent *so* many hours already considering, discussing, & debating what to do about the MTI video codec.  One could argue an "insane amount" of time relative to the other issues we need to resolve.  We did this because most of us realized that "no MTI" could be horrific for the standard.  We should embrace consensus around anything less than horrific, and most of us agree that this compromise is less than horrific (not great, but less than horrific).

Right now I fear we're on the verge of shooting ourselves in the foot or head (I'm not sure which) by reopening this discussion even though we're in sight of the end.  I ask that the working group and the chairs put the proverbially safety back on the gun, declare consensus on this less-than-horrific proposal, and finish our work on "v1.0" of the spec.


Maire Reavy

rtcweb mailing list