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

Randell Jesup <> Mon, 04 November 2013 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52DFA21E817F for <>; Mon, 4 Nov 2013 08:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s9sk7x0yWlZm for <>; Mon, 4 Nov 2013 08:26:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 298C021E8175 for <>; Mon, 4 Nov 2013 08:26:43 -0800 (PST)
Received: from [] (port=53127 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1VdMzD-0009nT-9W for; Mon, 04 Nov 2013 10:26:43 -0600
Message-ID: <>
Date: Mon, 04 Nov 2013 08:26:42 -0800
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Thunderbird/25.0
MIME-Version: 1.0
References: <> <20131102124801.GY3245@audi.shelbyville.oz> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070806070402000605020307"
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:
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:26:52 -0000

On 11/4/2013 6:58 AM, Jonathan Rosenberg wrote:
> 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?

Those are all important considerations.

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

Here you're stretching - most of these don't have an existing system 
"based on H.264" for this.  Some may, but most do not; video access 
would be something new in any case.  And for many of those use-cases, 
end-to-end WebRTC would be preferable to gatewaying to another system.

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

Interop is certainly a consideration and that's where H.264's advantage 
lies.  (H.264's only real technical advantages are interop and the 
possibility of existing hardware support).

> There are other considerations too. Some of the ones I'd list are:
> * Interoperates with install base
> * Widespread deployment

Not in of itself a consideration.

> * 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?

This is just the interop argument again.

> * Available widely in hardware - especially mobile phones
> * Broad availability of expertise

I don't see this as a consideration.

> * Broad availability of toolsets

It's unclear if this has any import or not.

> * Multiple codebases and implementations to choose from

Only of use to those willing to pay MPEG-LA fees.   Everyone else has to 
use platform OS codecs, HW codecs, or Cisco's plugin.

   Randell Jesup, Mozilla

> 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.
> <>
> _______________________________________________
> rtcweb mailing list

Randell Jesup