Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2951F0C74 for ; Wed, 13 Mar 2013 21:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUQm1hFdesxB for ; Wed, 13 Mar 2013 21:18:18 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 786E41F0C6D for ; Wed, 13 Mar 2013 21:18:18 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r2E4IHJW022350; Wed, 13 Mar 2013 22:18:17 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 13 Mar 2013 22:18:17 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 22:18:14 -0600 From: Daryl Malas To: Jonathan Rosenberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A different perspective on the video codec MTI discussion Thread-Index: AQHOIDcYbFpDVsu7rEa3KEkeiqjz/ZiktwQA Date: Thu, 14 Mar 2013 04:18:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_FEA80D86BEEC134D88CA45E53A0D3408180DA31BEXCHANGEcablela_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion X-BeenThere: rtcweb@ietf.org 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:18:20 -0000 --_000_FEA80D86BEEC134D88CA45E53A0D3408180DA31BEXCHANGEcablela_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I would like to add my support to Jonathan's comments. I have had discussi= ons with multiple cable operators, which are evaluating the potential use c= ases of deploying webRTC. The resounding comment is that if webRTC support= s H.264, their flexibility to deploy it in the near-term on a number of dev= ices 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. 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 li= cense 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 vi= deo codecs that it outweighs the potential for faster adoption and deployme= nt of webRTC? I also second Jonathan's comments related to, "I applaud your efforts and t= hank you for them." This is absolutely valuable from my perspective, and i= t has great potential for future use. Regards, Daryl From: Jonathan Rosenberg > Date: Wednesday, March 13, 2013 6:06 PM To: "rtcweb@ietf.org" > Subject: [rtcweb] A different perspective on the video codec MTI discussion I=92d like to put a different perspective on the video MTI discussion. Much of the discussion has been around video quality, IPR, and standardizat= ion 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 re= gard, I would like to suggest that, at this time, adoption of VP8 as MTI wi= ll slow down adoption of webRTC by turning off developers that would otherw= ise 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 th= e luxury of a massive social graph, or the luxury of their users being park= ed 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, tho= se agents are probably sitting on existing agent systems which are not web = based, and it=92s 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 V= P8. Developers who want to build business communications clients will need = to connect those users with other users in the business, who may be using v= ideophones, 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 =96 today=92s Internet and IP communications systems are bui= lt on H.264. And unless the developer cares only about living within the is= land of the web browser =96 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 pa= tent holders. I think they should continue pushing and promoting the techno= logy because a free, high quality video codec would be great for the Inter= net. But today, it is not the video codec of the Internet. And, given the r= elatively early days of video, I am sure there will be video codecs after V= P8. 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 th= e endpoints that matter, we can revise our specs and mandate support for th= em. 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 wil= l hold developers back from using webRTC and thus prevent us from ever havi= ng the opportunity to add these video codecs in the future. And so =96 to the supporters of VP8 =96 I applaud your efforts and thank yo= u for them. Please continue. And when the industry is ready, we can make VP= 8 MTI in the browser. But we are not there yet. I ask you to please put th= e needs of the developers ahead of your own, and do not hold back webRTC fo= r the benefit of your ideals around an RF and open source video codec. WebR= TC 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 c= ollaboration group, which is responsible for Webex. Webex was one of the fi= rst services to do voice and video on the web, using plugins of course. For= our business, a key requirement is interoperability with other video syste= ms in the Cisco portfolio, including our video clients and telepresence uni= ts. Those are all based on H.264. Consequently, much as I would like to avo= id the need for a plugin, the benefits of eliminating the plugin do not out= weigh the drawbacks of having to transcode from VP8 to H.264. If IETF selec= ts 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. jdrosen@jdrosen.net http://www.jdrosen.net --_000_FEA80D86BEEC134D88CA45E53A0D3408180DA31BEXCHANGEcablela_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0A2BE5EACB1CDA499F85F2A07829D7B3@cablelabs.com> Content-Transfer-Encoding: quoted-printable
I would like to add my support to Jonathan's comments.  I have ha= d discussions with multiple cable operators, which are evaluating the poten= tial use cases of deploying webRTC.  The resounding comment is th= at 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 t= he deployment, because the relevant devices out there already support H.264= and not VP8.

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 necessa= ry license fees (whether new or already realized) at their choosing in orde= r to deploy more webRTC clients and further the overall adoption of webRTC.

Does it really increase the complexity so dramatically by supporting t= wo video codecs that it outweighs the potential for faster adoption and dep= loyment of webRTC?

I also second Jonathan's comments related to, "I applaud your eff= orts and thank you for them."  This is absolutely valuable from m= y perspective, and it has great potential for future use.

Regards,

Daryl

From: Jonathan Rosenberg <jdrosen@jdrosen.net>
Date: Wednesday, March 13, 2013 6:0= 6 PM
To: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: [rtcweb] A different persp= ective on the video codec MTI discussion

I=92d like to put a different per= spective on the video MTI discussion.

Much of the discussion has been a= round video quality, IPR, and standardization status. While those are all i= mportant factors, to me they are secondary to the core question: how does t= he choice impact uptake of the webRTC APIs and protocols by developers who build applications ontop of it? In th= is regard, I would like to suggest that, at this time, adoption of VP8 as M= TI will slow down adoption of webRTC by turning off developers that would o= therwise embrace it if H.264 were selected.

The reason is simple. For many ap= plication developers, what is interesting about webRTC is NOT just browser = to browser communications, but connecting users in a browser to users elsew= here - 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 parke= d 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 hav= e a video call with an agent. However, those agents are probably sitting on= existing agent systems which are not web based, and it=92s almost certainl= y true that they do not today support VP8, but rather H.264. Many developers would probably love to connect user= s 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 wit= h other users in the business, who may be using videophones, PC clients, te= lepresence units or video room systems, the vast majority of which do not s= upport VP8 today, but many of which do support H.264.

The reality is =96 today=92s Inte= rnet and IP communications systems are built on H.264. And unless the devel= oper cares only about living within the island of the web browser =96 a VP8= based solution will simply not meet their requirements.

This may not be true down the roa= d. 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 f= or 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 co= decs after VP8. Maybe H.265, maybe the new video codec being developed here at the IETF. And once those codecs be= come more broadly implemented and available on the endpoints that matter, w= e 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 w= idely 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 =96 to the supporters of V= P8 =96 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. W= ebRTC is too important for that.

I have one more thing to say - sp= eaking now as a developer.

As some of you may know, I recent= ly returned to Cisco as CTO of the cloud collaboration group, which is resp= onsible for Webex. Webex was one of the first services to do voice and vide= o on the web, using plugins of course. For our business, a key requirement is interoperability with other video s= ystems 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 webRT= C. If H.264 is the MIT codec, it will make it much easier for us to use webRTC. 


Thx,

Jonathan R.

--
--_000_FEA80D86BEEC134D88CA45E53A0D3408180DA31BEXCHANGEcablela_--