Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8

Tim Panton <> Mon, 04 November 2013 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2B6811E8310 for <>; Mon, 4 Nov 2013 08:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1M2kdGe7MWoe for <>; Mon, 4 Nov 2013 08:11:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E863411E82FB for <>; Mon, 4 Nov 2013 08:10:49 -0800 (PST)
Received: (qmail 86909 invoked from network); 4 Nov 2013 16:10:48 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 10634
Received: from unknown (HELO ( by with SMTP; 4 Nov 2013 16:10:48 -0000
Received: from (localhost []) by (Postfix) with ESMTP id 6D03218A0C8B for <>; Mon, 4 Nov 2013 16:10:48 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 3849D18A06CC for <>; Mon, 4 Nov 2013 16:10:48 +0000 (GMT)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_14B792FE-27E7-462B-9773-8FF01ACD703E"
From: Tim Panton <>
Resent-From: Tim Panton <>
In-Reply-To: <>
Date: Mon, 04 Nov 2013 16:01:22 +0000
Resent-Date: Mon, 04 Nov 2013 16:10:39 +0000
Message-Id: <>
References: <> <20131102124801.GY3245@audi.shelbyville.oz> <>
To: Jonathan Rosenberg <>
X-Mailer: Apple Mail (2.1816)
Resent-Message-Id: <>
X-Mailman-Approved-At: Mon, 04 Nov 2013 09:17:38 -0800
Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8
X-Mailman-Version: 2.1.12
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, 04 Nov 2013 16:11:42 -0000
X-List-Received-Date: Mon, 04 Nov 2013 16:11:42 -0000

On 4 Nov 2013, at 14:58, Jonathan Rosenberg <> wrote:

> I do not believe that "genuinely free" is the only, nor even the primary, consideration here.
> I believe we should in general be thinking about what it takes to make webRTC successful. And more than anything else, that means making it a platform that application developers can utilize. If we do our jobs well, we'll have many thousands (hundreds of thousands even) of applications on the web that are enabled with real-time comms and frankly a great many of them will know nothing about codecs or the nuances of MPEG-LA licensing. What are the considerations for making webRTC attractive to them?
> I assert that the primary thing they'll want is to interconnect their application with some kind of video network or user base that can add value to their application. Let me give an example. Lets say there is a bank, and this bank wants to add the ability for a user to look at their investment portfolio online, click a button, and have a voice/video call with their investment advisor. To build such an app into their existing banking web app, the bank will need webRTC to connect to the voice and video contact center and clients their investment advisors have. Today, all of that is based on H.264. 

But the scale of such _video_ deployments is so negligible compared to current VP8 deployment in chrome and firefox as to make that 
argument unconvincing to me.

> So - I would assert that frankly our primary consideration for webRTC is interoperability. And interoperability as a requirement clearly points to H.264. 
> There are other considerations too. Some of the ones I'd list are:
> * Interoperates with install base

An irrelevant install base, mostly consisting of non-realtime decoders.

> * Widespread deployment

Deployments that can't interoperate with web RTC because they don't support the required security features, or don't
support APIs that expose realtime H264.

> * Appeals to the existing set of video application developers - in other words, the biggest consumers of webRTC should be the folks who are already providing video communications applications on the Internet (which by definition none of them do so natively from the browser). Don't we want them to come to the web with webRTC?

Really? That's quite some assertion. I suppose many web designers did come from a print-design background initially, 
but they have rapidly been overcome by webnative developers.

> * Available widely in hardware - especially mobile phones

But entirely in-accessible to developers- except to the platform players, giving the platform browser an unfair advantage.

> * Broad availability of expertise
> * Broad availability of toolsets

I'll grant these two, but with the caveat that if VP8 were to be an MTI in webRTC we could expect toolsets and expertise
to grow pretty fast, and probably overtake h264 before long. I say this because creating such tools in h264-land requires
lawyers and licences. The VP8 coders can do their initial work in a garage in spare time.

> * Multiple codebases and implementations to choose from

That's the best argument for h264 I've seen so far. 

> And none of that has anything to do with IPR or royalties. 

That's where we disagree. The legal framework shapes every decision in this space. Open source hackers will
be very edgy of messing with h264 for fear of falling off the legal straight and narrow.

> -Jonathan R.
> On Sat, Nov 2, 2013 at 8:48 AM, Ron <> wrote:
> On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote:
> > We congratulate Cisco on their intention to make an open source H.264 codec
> > available and usable by the community. We look forward to seeing the result
> > of this effort.
> >
> > Google still believes that VP8 - a freely available, fully open,
> > high-quality video codec that you can download, compile for your platform,
> > include in your binary, distribute and put into production today - is the
> > best choice of a Mandatory to Implement video codec for the WebRTC effort.
> This is my belief also.
> While the Cisco announcement is certainly an interesting approach to trying
> to extricate their existing technology investment from the deep quagmire of
> encumbrances that currently bind it, the result still falls well short of
> not only the ideal, but also the already existing alternative choices that
> we have available to us.
> Given the choice between a genuinely Free option, that anyone is free to
> improve and distribute however they wish - and a no-cost binary-only option
> that is available from only a single supplier, while Happy Hour lasts - the
> decision still seems to be something of a no-brainer.  Even before you also
> consider that the Free Option is not constrained to only its lowest possible
> performance mode in the implementation that is available to people today.
> VP8 still seems like the only obvious and enduring choice for an MTI codec
> for WebRTC at present.
>   Ron
> _______________________________________________
> rtcweb mailing list
> -- 
> Jonathan Rosenberg, Ph.D.
> _______________________________________________
> rtcweb mailing list

Tim Panton - Web/VoIP consultant and implementor