Re: [rtcweb] Plan for MTI video codec?

"Jeremy Laurenson (jlaurens)" <> Sun, 19 October 2014 18:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 34E791A1A71 for <>; Sun, 19 Oct 2014 11:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PhGzcHzfID_T for <>; Sun, 19 Oct 2014 11:00:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B9171A19FE for <>; Sun, 19 Oct 2014 11:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14013; q=dns/txt; s=iport; t=1413741601; x=1414951201; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=W5RZnFd7nzhvaO5ZDkaVT1e4OgxlawJQI2pbYldDOAw=; b=EJVl2vr/E3u8LkLILIjm8zZ7RDN3SB4ZCoyCk3s7r2IXI+5pO27dGpmB elvaLqEY2n2j4gFmuzExxKxWJ705yK6dnF/is7YAcqzRTBhkRznHxF5oB 0zbr9IDQ3kbsgzSZKk7DmPbbi8aaS04A0zQCYgFx9HkdXQ6dh0JpJdOkP A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,749,1406592000"; d="scan'208,217";a="364582417"
Received: from ([]) by with ESMTP; 19 Oct 2014 18:00:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s9JHxxqr020140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Sun, 19 Oct 2014 17:59:59 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 12:59:59 -0500
From: "Jeremy Laurenson (jlaurens)" <>
To: "" <>
Thread-Topic: [rtcweb] Plan for MTI video codec?
Thread-Index: AQHP669o0YA0VVXvZkG/wkm6G20Ux5w3tZ/C
Date: Sun, 19 Oct 2014 17:59:58 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_16C290A2EB7C4D778871C7E82B374C48ciscocom_"
MIME-Version: 1.0
Subject: Re: [rtcweb] Plan for MTI video 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: Sun, 19 Oct 2014 18:00:03 -0000

I am hearing a lot of folks outside this group losing faith and beginning to talk about writing off WebRTC for lack of consensus (including analysts).

I am therefore in favor of a very finite amount of "new-news" discussion and another attempt at consensus. We either do or don't have it.

On Oct 19, 2014, at 11:15 AM, Jonathan Rosenberg <<>> wrote:

I'm in favor of taking another run at this.

The working group has repeatedly said that an MTI codec is something we need to produce. And its one of the issues holding up wider adoption of the technology (not the only one for sure).

And things have changed since the last meeting, a year ago now (November in Vancouver). Cisco's open264 plugin shipped and now just recently is integrated into Firefox. iOS8 shipped with APIs for H264. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <<>> wrote:
+1 to not having MTI codec discussion unless some progress has been made on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling that there was no change on the members position.

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <<>> wrote:
On 10/17/2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually interoperate regardless of the codec.

The big argument for an MTI is actually the one stated in -overview: It guards against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to everything else, and run well for *some* level of "well" - and I would prefer that ecosystem to be one where it's possible to field the box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. And I don't see much movement on the specifics of the proposals either.

We'll have to interoperate well with the codecs we field. So using some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't finished either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer to re-discuss based on the knowledge that some significant players have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have said "I have changed my mind".


On Oct 16, 2014, at 2:28 PM, Martin Thomson <<>> wrote:

On 16 October 2014 14:17, Matthew Kaufman <<>> wrote:
And that's because something substantive has changed, or simply because
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far as
I can tell)
Personally, I've found the reprieve from this fight refreshing.  And
it would appear that we've made some real progress as a result.  I'd
suggest that if we don't have new information, we continue to spend
our time productively.  If we can't find topics to occupy our meeting
agenda time, then maybe we can free an agenda slot.

rtcweb mailing list<>
rtcweb mailing list<>

rtcweb mailing list<>

Alex. Gouaillard, PhD, PhD, MBA
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA


rtcweb mailing list<>

Jonathan Rosenberg, Ph.D.<>
rtcweb mailing list<>