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

Jonathan Rosenberg <> Mon, 04 November 2013 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 814A621E81A1 for <>; Mon, 4 Nov 2013 06:58:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.876
X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IPKJPDdfnW5X for <>; Mon, 4 Nov 2013 06:58:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DBF7111E823A for <>; Mon, 4 Nov 2013 06:58:28 -0800 (PST)
Received: from ([]:57052) by with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from <>) id 1VdLbk-0004yj-0r for; Mon, 04 Nov 2013 09:58:27 -0500
Received: by with SMTP id fb1so7047817pad.31 for <>; Mon, 04 Nov 2013 06:58:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E540fIV7HC9mxfHI/FZy8/038l3uCj7V1Skjx/GHHsc=; b=Jn1/iFojwn1+gXpVyfk2uTxPy8tZEkGUrhKLfZNZ99aZm8S5s9JVmXeiP6NtQGoWHc HiBsMwZGAMWNLcLRKGnFxu37dpFS5M0Bz4fmR9HDlD5aoil1Xluv40+AYBePFjAm9jRj daLkTBCVPSi364yOdYk/pXjXW2bddWkP4DvIIQlvbKNqg45oHc8Qo9ZhGNEOwRYrtu8i vvn6JnblpmWu6j1mEaFk+JAFOJMrXFgMPEiRbE2tKTedU1D6AtRi4Fn/c4h+A/Bu4XjF rZZaknoPpusySCHzKxPdwXMHt/tsX406Sobq7KC7YNT4a1czIiTceWngWLpk3dHlw6vQ +cmg==
MIME-Version: 1.0
X-Received: by with SMTP id ph6mr18357916pac.28.1383577103286; Mon, 04 Nov 2013 06:58:23 -0800 (PST)
Received: by with HTTP; Mon, 4 Nov 2013 06:58:23 -0800 (PST)
In-Reply-To: <20131102124801.GY3245@audi.shelbyville.oz>
References: <> <20131102124801.GY3245@audi.shelbyville.oz>
Date: Mon, 04 Nov 2013 09:58:23 -0500
Message-ID: <>
From: Jonathan Rosenberg <>
To: Ron <>
Content-Type: multipart/alternative; boundary="047d7b5db49ac2cc0404ea5b256c"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id: user confirmed/virtual account not confirmed
Cc: "" <>
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 14:58:53 -0000

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.

So - I would assert that frankly our primary consideration for webRTC is
interoperability. And interoperability as a requirement clearly points to

There are other considerations too. Some of the ones I'd list are:

* Interoperates with install base
* Widespread deployment
* 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?
* Available widely in hardware - especially mobile phones
* Broad availability of expertise
* Broad availability of toolsets
* Multiple codebases and implementations to choose from

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

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