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 BBD6421F8431 for ; Wed, 13 Mar 2013 16:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 lbfowpPV+OJu for ; Wed, 13 Mar 2013 16:54:30 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 44DED21F8CD4 for ; Wed, 13 Mar 2013 16:54:17 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id fn15so1549272wgb.20 for ; Wed, 13 Mar 2013 16:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fDl3sGItlki1Fu587yLrc+FJIeQD81YiHSf3SwW03qQ=; b=T2ZKX2NLUc3OBFiMezne9T5ucNZiywRUPzMH3O8bRupYOyPxCkyMBCiRH1zwF7ONdb NqsSxT4GaN43XVfaIslvpg7tu2yYqfIXKM1lKrvSiZw+d+M4o+3GnNSEaffym+Q9b6lo QpFyv9yyfeywhM/A5M4XDq8T1CNX5GwieIE0gsxaHCYeF9CqD81peOWIRk3fWAirSg4Q F/kX+6oKhs37vFC62wCmAsKRn9ywL8rDDqXnmTa3JdoSuFxT+I2czqbWwu2PmTLBPZSB /bIqOWtJyAd/32YJV4SG5fMuCUTIMJs8pl1o53c2WbfnK4AZ+tya5Lj3bonskK66vMKd JOTQ== MIME-Version: 1.0 X-Received: by 10.180.75.143 with SMTP id c15mr402304wiw.18.1363218856347; Wed, 13 Mar 2013 16:54:16 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 16:54:16 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 16:54:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 16:54:16 -0700 Message-ID: From: Cameron Byrne To: Jonathan Rosenberg Content-Type: multipart/alternative; boundary=f46d04389555af0eae04d7d71fd0 Cc: "rtcweb@ietf.org" 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: Wed, 13 Mar 2013 23:54:34 -0000 --f46d04389555af0eae04d7d71fd0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mar 13, 2013 4:44 PM, "Jonathan Rosenberg" wrote: > > Justin - my point is that there are non-web endpoints that people care about - including most importantly mobile endpoints. Its not just about pure numbers, its about reaching users on the devices/platforms they need to be reached on. > > Surely you don't mean that its not important for developers (like Webex) to reach users on mobile clients or other video systems outside of the web? > They too can have vp8 and opus. And if your legacy gear does not, then it can negotiate appropriately to something that will work. As a mobile operator offering fmc today, I look forward to opus and vp8 being ubiquitous in all devices. CB > Thx, > Jonathan R. > > > On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer < silviapfeiffer1@gmail.com> wrote: >> >> Also, it is worth pointing out that h.264 cannot meet the RF requirements of W3C, so the only alternatives we can look at are VP8 or delaying the decision for an MTI until the market decides. >> >> I'd rather we specify for an environment 5 years down the track (and give companies like CISCO a reason to replace all their old devices with new ones that support VP8) than continuing decision avoidance. >> >> Regards, >> Silvia. >> (Speaking for myself) >> >> On 14 Mar 2013 09:42, "Justin Uberti" wrote: >>> >>> Regarding your comment on the "web today", I think it is worthwhile to point out that within weeks, there will be 2B+ deployed WebRTC endpoints, across desktop and mobile, that support VP8. >>> >>> Surely that dwarfs the total number of deployed H.264 endpoints by several orders of magnitude. >>> >>> >>> On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg wrote: >>>> >>>> I=92d 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=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 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 =96 today=92s Internet and IP communications systems ar= e built on H.264. And unless the developer cares only about living within the island of the web browser =96 a VP8 based solution will simply not meet the= ir 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 =96 to the supporters of VP8 =96 I applaud your efforts and tha= nk 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. >>>> jdrosen@jdrosen.net >>>> http://www.jdrosen.net >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> > > > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d04389555af0eae04d7d71fd0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Mar 13, 2013 4:44 PM, "Jonathan Rosenberg" <jdrosen@jdrosen.net> wrote:
>
> Justin - my point is that there are non-web endpoints that people care= about - including most importantly mobile endpoints. Its not just about pu= re numbers, its about reaching users on the devices/platforms they need to = be reached on.=A0
>
> Surely you don't mean that its not important for developers (like = Webex) to reach users on mobile clients or other video systems outside of t= he web?
>

They too can have vp8 and opus. And if your legacy gear does= not, then it can negotiate appropriately to something that will work.

As a mobile operator offering fmc today, I look forward to o= pus and vp8 being ubiquitous in all devices.

CB

> Thx,
> Jonathan R.
>
>
> On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>>
>> Also, it is worth pointing out that h.264 cannot meet the RF requi= rements of W3C, so the only alternatives we can look at are VP8 or delaying= the decision for an MTI until the market decides.
>>
>> I'd rather we specify for an environment 5 years down the trac= k (and give companies like CISCO a reason to replace all their old devices = with new ones that support VP8) than continuing decision avoidance.
>>
>> Regards,
>> Silvia.
>> (Speaking for myself)
>>
>> On 14 Mar 2013 09:42, "Justin Uberti" <juberti@google.com> wrote:
>>>
>>> Regarding your comment on the "web today", I think i= t is worthwhile to point out that within weeks, there will be 2B+ deployed = WebRTC endpoints, across desktop and mobile, that support VP8.=A0
>>>
>>> Surely that dwarfs the total number of deployed H.264 endpoint= s by several orders of magnitude.
>>>
>>>
>>> On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
>>>>
>>>> I=92d 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 t= hey are secondary to the core question: how does the choice impact uptake o= f 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, wha= t 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 develope= rs 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 ag= ent. However, those agents are probably sitting on existing agent systems w= hich are not web based, and it=92s almost certainly true that they do not t= oday 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 t= oday support H264 based hardware acceleration for decode and sometimes enco= de, but not yet VP8. Developers who want to build business communications c= lients will need to connect those users with other users in the business, w= ho may be using videophones, PC clients, telepresence units or video room s= ystems, the vast majority of which do not support VP8 today, but many of wh= ich do support H.264.
>>>>
>>>> The reality is =96 today=92s Internet and IP communication= s systems are built on H.264. And unless the developer cares only about liv= ing within the island of the web browser =96 a VP8 based solution will simp= ly not meet their requirements.
>>>>
>>>> This may not be true down the road. I applaud Google for w= orking 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 pro= moting the technology because a=A0 free, high quality video codec would be = great for the Internet. But today, it is not the video codec of the Interne= t. And, given the relatively early days of video, I am sure there will be v= ideo codecs after VP8. Maybe H.265, maybe the new video codec being develop= ed 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 man= date 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 preven= t us from ever having the opportunity to add these video codecs in the futu= re.
>>>>
>>>> =A0
>>>>
>>>> And so =96 to the supporters of VP8 =96 I applaud your eff= orts and thank you for them. Please continue. And when the industry is read= y, we can make VP8 MTI in the browser. But we are not there yet. =A0I ask y= ou 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 sourc= e 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 C= TO 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 plugi= ns 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.2= 64. If IETF selects VP8 as the MTI codec, this will make it dramatically mo= re 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.=A0
>>>>
>>>>
>>>> Thx,
>>>>
>>>> Jonathan R.
>>>>
>>>> --
>>>> Jonathan Rosenberg, Ph.D.
>>>> jdrosen@jdrosen.net=
>>>> http://www.jdrosen.net<= /a>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> h= ttps://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https= ://www.ietf.org/mailman/listinfo/rtcweb
>>>
>
>
>
> --
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--f46d04389555af0eae04d7d71fd0--