Re: [rtcweb] A different perspective on the video codec MTI discussion

Cameron Byrne <> Thu, 14 March 2013 04:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86DFA21F8D55 for <>; Wed, 13 Mar 2013 21:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.937
X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NEa6o7YloRGn for <>; Wed, 13 Mar 2013 21:27:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 65EE721F8D50 for <>; Wed, 13 Mar 2013 21:26:59 -0700 (PDT)
Received: by with SMTP id dr12so1610225wgb.23 for <>; Wed, 13 Mar 2013 21:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=G9fnfGqaKlvFEsPbjBQt9FrYQLAWWdyPKn87525cuvo=; b=NadTMUQbxqhTR8nHu7V8COUIu0pUSCPFn5ODBOiW/vt5bDuOmWMNaWwMyl69ZIApqM /+ZuE1JxsFzV2WY6u4+ALoP6NEmWMlT4pvhw8tkwVZblivHQAg6r4Jzw2OSHedjxWWwR c0kFjLifTvsCqUSVZIWnhIT+s8u0XQuYDh9eHlJWF+Gpgc3OSffmHzXGsAvP/BCfdWio LKnBieKHCgMWLYu/srvjUiqG8DICbNEsrKJ4+a4gAZ1b1AocwuczZ1ASPl0kMikKQrY0 8npMUpq4kjxmvNT5ZBqU+oUFS189CLLcZEY2P5rGpNUn1QqhUk+gX4NOY46Gqn/7xXFa LVAg==
MIME-Version: 1.0
X-Received: by with SMTP id el8mr31371280wib.22.1363235218502; Wed, 13 Mar 2013 21:26:58 -0700 (PDT)
Received: by with HTTP; Wed, 13 Mar 2013 21:26:58 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 13 Mar 2013 21:26:58 -0700
Message-ID: <>
From: Cameron Byrne <>
To: Daryl Malas <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion
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: Thu, 14 Mar 2013 04:27:02 -0000

On Wed, Mar 13, 2013 at 9:18 PM, Daryl Malas <> wrote:
> I would like to add my support to Jonathan's comments.  I have had
> discussions with multiple cable operators, which are evaluating the
> potential use cases of deploying webRTC.  The resounding comment is that if
> webRTC supports H.264, their flexibility to deploy it in the near-term on a
> number of devices improves dramatically.  If VP8 is the only allowable
> codec, this will significantly limit the deployment, because the relevant
> devices out there already support H.264 and not VP8.

You can negotiate any codec you want

There is now limitation on the number of codecs that you may support.

I hope this helps.


ps.  my position remains that the idea of MTI needs be dropped,
consensus will not be found.  Let the market figure it out.

> In addition, by saying that we will only support a royalty-free codec (VP8),
> it is effectively saying we will not allow people to pay the necessary
> license fees (whether new or already realized) at their choosing in order to
> deploy more webRTC clients and further the overall adoption of webRTC.
> Does it really increase the complexity so dramatically by supporting two
> video codecs that it outweighs the potential for faster adoption and
> deployment of webRTC?

> I also second Jonathan's comments related to, "I applaud your efforts and
> thank you for them."  This is absolutely valuable from my perspective, and
> it has great potential for future use.
> Regards,
> Daryl
> From: Jonathan Rosenberg <>
> Date: Wednesday, March 13, 2013 6:06 PM
> To: "" <>
> Subject: [rtcweb] A different perspective on the video codec MTI discussion
> I’d like to put a different perspective on the video MTI discussion.
> Much of the discussion has been around video quality, IPR, and
> standardization status. While those are all important factors, to me they
> are secondary to the core question: how does the choice impact uptake of the
> webRTC APIs and protocols by developers who build applications ontop of it?
> In this regard, I would like to suggest that, at this time, adoption of VP8
> as MTI will slow down adoption of webRTC by turning off developers that
> would otherwise embrace it if H.264 were selected.
> The reason is simple. For many application developers, what is interesting
> about webRTC is NOT just browser to browser communications, but connecting
> users in a browser to users elsewhere - on other devices, in other networks.
> After all, the vast majority of web application developers do not have the
> luxury of a massive social graph, or the luxury of their users being parked
> persistently on their website and thus able to receive an incoming call.
> Many websites that have customer support or service needs would love to be
> able to allow their users to have a video call with an agent. However, those
> agents are probably sitting on existing agent systems which are not web
> based, and it’s almost certainly true that they do not today support VP8,
> but rather H.264. Many developers would probably love to connect users on
> the web with users on mobile apps. Most mobile platforms today support H264
> based hardware acceleration for decode and sometimes encode, but not yet
> VP8. Developers who want to build business communications clients will need
> to connect those users with other users in the business, who may be using
> videophones, PC clients, telepresence units or video room systems, the vast
> majority of which do not support VP8 today, but many of which do support
> H.264.
> The reality is – today’s Internet and IP communications systems are built on
> H.264. And unless the developer cares only about living within the island of
> the web browser – a VP8 based solution will simply not meet their
> requirements.
> This may not be true down the road. I applaud Google for working hard (and
> spending much money no doubt) to secure an RF license for VP8 from these
> patent holders. I think they should continue pushing and promoting the
> technology because a  free, high quality video codec would be great for the
> Internet. But today, it is not the video codec of the Internet. And, given
> the relatively early days of video, I am sure there will be video codecs
> after VP8. Maybe H.265, maybe the new video codec being developed here at
> the IETF. And once those codecs become more broadly implemented and
> available on the endpoints that matter, we can revise our specs and mandate
> support for them. But this is not about the web of five years from now, its
> about the web today. And if we mandate usage of a codec which is not widely
> implemented in all the endpoints that matter (not just the browser), I fear
> that it will hold developers back from using webRTC and thus prevent us from
> ever having the opportunity to add these video codecs in the future.
> And so – to the supporters of VP8 – I applaud your efforts and thank you for
> them. Please continue. And when the industry is ready, we can make VP8 MTI
> in the browser. But we are not there yet.  I ask you to please put the needs
> of the developers ahead of your own, and do not hold back webRTC for the
> benefit of your ideals around an RF and open source video codec. WebRTC is
> too important for that.
> I have one more thing to say - speaking now as a developer.
> As some of you may know, I recently returned to Cisco as CTO of the cloud
> collaboration group, which is responsible for Webex. Webex was one of the
> first services to do voice and video on the web, using plugins of course.
> For our business, a key requirement is interoperability with other video
> systems in the Cisco portfolio, including our video clients and telepresence
> units. Those are all based on H.264. Consequently, much as I would like to
> avoid the need for a plugin, the benefits of eliminating the plugin do not
> outweigh the drawbacks of having to transcode from VP8 to H.264. If IETF
> selects VP8 as the MTI codec, this will make it dramatically more difficult
> and expensive for us to use webRTC. If H.264 is the MIT codec, it will make
> it much easier for us to use webRTC.
> Thx,
> Jonathan R.
> --
> Jonathan Rosenberg, Ph.D.
> _______________________________________________
> rtcweb mailing list