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

Andrew Allen <> Tue, 09 December 2014 00:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9D0581A1A87 for <>; Mon, 8 Dec 2014 16:45:38 -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 hy6E4wQ-xtla for <>; Mon, 8 Dec 2014 16:45:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 14FA31A1A7E for <>; Mon, 8 Dec 2014 16:45:35 -0800 (PST)
Received: from (HELO ([]) by with ESMTP/TLS/AES128-SHA; 08 Dec 2014 19:45:04 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 8 Dec 2014 19:45:04 -0500
Received: from ([fe80::28c6:fa1c:91c6:2e23]) by ([::1]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 19:45:03 -0500
From: Andrew Allen <>
To: Adam Roach <>
Thread-Topic: [rtcweb] confirming sense of the room: mti codec
Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgATTdwD//69UkIAAdtWA//+sviA=
Date: Tue, 09 Dec 2014 00:45:03 +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="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 00:45:38 -0000


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.


-----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?