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

Andrew Allen <> Tue, 09 December 2014 04:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 981041A1A92 for <>; Mon, 8 Dec 2014 20:47:05 -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 4AnI8nDj2D66 for <>; Mon, 8 Dec 2014 20:47:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3DADB1A0242 for <>; Mon, 8 Dec 2014 20:47:02 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 08 Dec 2014 23:46:52 -0500
Received: from ([fe80::28c6:fa1c:91c6:2e23]) by ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 23:46:51 -0500
From: Andrew Allen <>
To: Adam Roach <>
Thread-Topic: [rtcweb] confirming sense of the room: mti codec
Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgATTdwD//69UkIAAdtWA//+sviCAAJK3AP//sTDw
Date: Tue, 09 Dec 2014 04:46:50 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Tue, 09 Dec 2014 04:47:05 -0000

And the 3rd alternative is that we agree that we cannot agree on a single MTI video codec and let the market decide. IMHO the sky will not fall if that ends up being the outcome. There is too much interest in WebRTC for it to fail just because we failed to mandate a single video codec. SIP based communication has had considerable market success without mandating any audio or video codecs and CLUE do not see it necessary to mandate codecs for telepresence.

I believe the current proposal also failed to garner 50% in the original straw poll and IMHO only garners more support now because a way has been found through the use of definitions that immunize many of the parties from being impacted by this decision. Support level for a variant of "choice 12" in tandem with the definitions in the overview document has not yet been polled.

In terms of the parties actually impacted by the decision a significant section of that community still opposes the current proposal. 

-----Original Message-----
From: Adam Roach [] 
Sent: Monday, December 08, 2014 10:44 PM
To: Andrew Allen
Cc: Maire Reavy;
Subject: Re: [rtcweb] confirming sense of the room: mti codec

I see two proposals in your response, both of which have been explored already. One is "choice 1" from the straw poll, which garnered only 48% support, and the other is "choice 12", which received only 7%.

Which is to say that these are not merely implausible, but demonstrably non-viable. So, when I asked whether you had a "constructive and plausible proposal," you could have saved us all some time by simply saying "no."


On 12/8/14 18:45, Andrew Allen wrote:
> Adam
> Our preference is for H.264 to be the single MTI. We believe that Cisco's open source royalty free code offer goes a long long way to address the concerns of many related to IPR on H.264 and the prevalence now of APIs to access embedded codecs (such as H.264) on mobile devices goes even further to address those concerns. See
> We also have proposed as a compromise having 2 MTI decoders but only have to implement one encoder.
> I know the above doesn't make everyone happy either.
> But this current proposed "compromise" whilst succeeding in garnering a significant hum in the room is opposed by some rather significant vendors in the browser space. So whilst it may make the RTCWEB Video RFC look pretty and complete it is unlikely to ensure interoperability in the market any more than simply leaving it to the market to decide (which is what will happen if we fail to agree on a single MTI video codec).  Having a standard that is not fully implemented by some of the primary participants in the market does not  bode well for the success of the standard even more than not agreeing on a single MTI codec IMHO. CLUE has agreed not to define MTI codecs but does this mean that telepresence interoperability will be a failure - I think not.
> BetaMax vs VHS and Blu Ray vs HD DVD have shown that ultimately the market will resolve these entrenched interoperability issues which are based on business reasons not technical merit without everyone having to agree in a standards body to support both or to support only one.
> Andrew
> -----Original Message-----
> From: Adam Roach []
> Sent: Monday, December 08, 2014 6:57 PM
> To: Andrew Allen
> Cc: Maire Reavy;
> Subject: Re: [rtcweb] confirming sense of the room: mti codec
>> On Dec 8, 2014, at 17:28, Andrew Allen <> wrote:
>> If we decide on two MTI video codecs then we have clearly failed to meet this commitment.
> Do you have a constructive and plausible proposal?
> /a