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

Iñaki Baz Castillo <> Mon, 08 December 2014 23:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 959251A0203 for <>; Mon, 8 Dec 2014 15:46:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4wIWDgtZ-uO0 for <>; Mon, 8 Dec 2014 15:46:37 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3056C1A0073 for <>; Mon, 8 Dec 2014 15:46:36 -0800 (PST)
Received: by with SMTP id w7so4359656qcr.14 for <>; Mon, 08 Dec 2014 15:46:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=sc0eyCIsCnG7TL+AXiciBFJK0vob9bfDpI3ShDUHV70=; b=FXKYaXckWQVsc1jIHPJyBgz8tUv12XwRUMLVxEDaYRaqzLdzFpKxDdh7fOydrShXuG /GXSrzcOLgSuwTaGzGVFMfUILbLa3fJY1CvAQ8va0MZ0JDs7c94m23r+T0tSb9QOCJLp m9hPQyXNktTfGrBWSUksZhyiEf4Fd8982h1rmP7oowPLf3EGdkW3hTyf5dIrNBc4xgp+ vIqKw13hSq9ud9iFcDPN45ZUXpmt7nC/aj2sGQ3/NyLqY2PGiwxL5cuAVmG+9Qhr2s7f cVVRVlLMQ1JsD7j/qDSPWn/8GcwW383l6wgJLSE8GMIle+xXeLedqAZ109T3d0u3OWTN qWiQ==
X-Gm-Message-State: ALoCoQllO4Q8IxCKGl9lVgcgtOY3vcbYKYjGMPgtqn4AV+vcQxCqPKplPu4xTq/hLXP3f/2Pql5c
X-Received: by with SMTP id ef6mr108796qcb.31.1418082395366; Mon, 08 Dec 2014 15:46:35 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 8 Dec 2014 15:46:15 -0800 (PST)
In-Reply-To: <20141208210320.GF19538@hex.shelbyville.oz>
References: <> <> <> <> <20141208210320.GF19538@hex.shelbyville.oz>
From: Iñaki Baz Castillo <>
Date: Tue, 09 Dec 2014 00:46:15 +0100
Message-ID: <>
To: Ron <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Mon, 08 Dec 2014 23:46:38 -0000

2014-12-08 22:03 GMT+01:00 Ron <>:
> On Mon, Dec 08, 2014 at 07:00:28PM +0100, Iñaki Baz Castillo wrote:

>> There was a much better solution:
>> - And a W3C compromise: First video codec 100% royalty free would
>> become MTI in WebRTC.
> We've had a 100% RF codec on the table since the very beginning.
> Two if you include the later proposal of H.261 as the MTI fallback.
> (three if you include theora ...)
> We apparently failed to get consensus on either of those as sole MTI.

My concern is that, regardless companies' interest on certain no RF
codecs, the W3C should mandate some requirements in order to adopt a
MTI codec. IMHO the main requirement should be being a 100% RF codec.
Unfortunately IMHO such a requirement does not exist and here we are,
mandating vendors and other players to implement non RF codecs to be
W3C compliant.

> I think the consensus that we do have, which at least includes an RF
> video codec, is better than perpetuating the chaos of no MTI.  So I
> also confirm my support for this as being the consensus of the group.

That sounds nice, but let's be realistic: will 50% of main vendors
accept this resolution? For me it is clear that they already exposed
their refusal to it. So what is solved here?

>> Things would be exactly as they are now, but at least we avoid a
>> "MUST" that will be ignored by 50% of the market.
> I'm not sure I follow your logic here?  Right now 100% of the current
> implementations have not ignored this.  That includes something like
> 75% of the browser user market share.  The rest of the market will do
> whatever their market research dept. tells them their customers want
> them to do.  This compromise gives the best chance for people who
> really are wedged through no fault of their own to be able to produce
> something that still will interop with that majority of 'the market'.

Well, let's imagine both IE and Safari implement WebRTC within the
next 4 months and, as announced, they just support H264. What is the
value of having VP8 as MTI? I mean: a company providing a WebRTC
service will need to implement H264 (because at least the 25% of their
use IE or Safari), so?

It may happen that certain famous applications just allow VP8 so
"customers" will indeed demand Microsoft and Apple to add support for
VP8 in their browsers.

IMHO nothing would change (and this is what I meant) if the WG would
have mandated no MTI video codec. The only difference (and a good one
IMHO) is that vendors and players would not be required to assume
"license / patent risks" in order to conform with a W3C specification.

> The only people currently claiming they are inclined to ignore this
> are people who so far have shown no real indication that they are going
> to do anything but ignore this standard anyway, regardless of what we
> specify about anything.  While the IETF does give everyone a voice to
> express real technical concerns and propose solutions, I don't think
> it grants a veto to people who simply want to obstruct something they
> feel their business is threatened by.  Whatever their "market share".
> Anyway, if you want to discuss that (again), we probably ought to move
> it off the "sense of the room" thread, so as not to make the hard job
> of the chairs even harder :)

AFAIU the resolution is already taken, and won't change. I don't want
to spend more time on this (I would prefer to invest it into ORTC
adoption which is the real next step).


Iñaki Baz Castillo