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

Ron <> Mon, 08 December 2014 21:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4FB6D1A1A48 for <>; Mon, 8 Dec 2014 13:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ddtZg7LdGauG for <>; Mon, 8 Dec 2014 13:03:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 87E0D1A1A1D for <>; Mon, 8 Dec 2014 13:03:24 -0800 (PST)
Received: from (HELO mailservice.shelbyville.oz) ([]) by with ESMTP; 09 Dec 2014 07:33:23 +1030
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id 53E79FFC86 for <>; Tue, 9 Dec 2014 07:33:22 +1030 (ACDT)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([]) by localhost (mailservice.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id 3MakiaCzyRSi for <>; Tue, 9 Dec 2014 07:33:20 +1030 (ACDT)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 7D229FFBC1 for <>; Tue, 9 Dec 2014 07:33:20 +1030 (ACDT)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 712DC80470; Tue, 9 Dec 2014 07:33:20 +1030 (ACDT)
Date: Tue, 09 Dec 2014 07:33:20 +1030
From: Ron <>
Message-ID: <20141208210320.GF19538@hex.shelbyville.oz>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 21:03:28 -0000

On Mon, Dec 08, 2014 at 07:00:28PM +0100, Iñaki Baz Castillo wrote:
> 2014-12-08 18:55 GMT+01:00 Randell Jesup <>:
> > +1 - it's by no means my preferred solution, but it's one I can live with,
> > and better than the alternative of the status-quo - no MTI at all.  If it
> > wasn't for OpenH264, my answer would be different.
> >
> > I can't see adopting H.264 as sole MTI, and I can't see that we'd get
> > consensus to adopt VP8 as sole MTI.
> 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.

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.

I still have a tiny candle burning with the hope that the people who
have so far done everything they could to try to thwart having a
single RF MTI codec, will finally come to their senses and pull the
trigger we've given them to enable that to still happen.  But even
if they don't, I think this standard will benefit far more from this
agreement than it would by letting the obstructing factions keep us
locked in a stalemate with no MTI video at all.

  Ever the optimist,

> 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'.

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 :)