Re: [rtcweb] Plan for MTI video codec?

Harald Alvestrand <> Fri, 17 October 2014 13:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 90A151ACDA7 for <>; Fri, 17 Oct 2014 06:22:13 -0700 (PDT)
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 2h9u3wjUwPCP for <>; Fri, 17 Oct 2014 06:22:08 -0700 (PDT)
Received: from ( [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id 9A0531ACDBD for <>; Fri, 17 Oct 2014 06:22:07 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 444D87C4994 for <>; Fri, 17 Oct 2014 15:22:06 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rtmh9OSq3z5D for <>; Fri, 17 Oct 2014 15:22:04 +0200 (CEST)
Received: from (unknown [IPv6:2620:0:1043:1:4ce8:48b8:b02b:3825]) by (Postfix) with ESMTPSA id C172B7C42C8 for <>; Fri, 17 Oct 2014 15:22:04 +0200 (CEST)
Message-ID: <>
Date: Fri, 17 Oct 2014 15:22:03 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 17 Oct 2014 13:22:14 -0000

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