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

Cameron Byrne <cb.list6@gmail.com> Thu, 14 March 2013 04:27 UTC

Return-Path: <cb.list6@gmail.com>
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 86DFA21F8D55 for <rtcweb@ietfa.amsl.com>; Wed, 13 Mar 2013 21:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.937
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEa6o7YloRGn for <rtcweb@ietfa.amsl.com>; Wed, 13 Mar 2013 21:27:00 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65EE721F8D50 for <rtcweb@ietf.org>; Wed, 13 Mar 2013 21:26:59 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr12so1610225wgb.23 for <rtcweb@ietf.org>; Wed, 13 Mar 2013 21:26:58 -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: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 10.180.98.232 with SMTP id el8mr31371280wib.22.1363235218502; Wed, 13 Mar 2013 21:26:58 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 21:26:58 -0700 (PDT)
In-Reply-To: <FEA80D86BEEC134D88CA45E53A0D3408180DA31B@EXCHANGE.cablelabs.com>
References: <CA+23+fE3WRs5SxAUcsjWbxcjzQKxCtW7sdfHtAsbd7MbPyHAtQ@mail.gmail.com> <FEA80D86BEEC134D88CA45E53A0D3408180DA31B@EXCHANGE.cablelabs.com>
Date: Wed, 13 Mar 2013 21:26:58 -0700
Message-ID: <CAD6AjGQGX+63eHp_DXxJ=RWP=vg-VGJPaCUsL75S7teZP8+UDg@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: Daryl Malas <D.Malas@cablelabs.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <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 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 04:27:02 -0000

On Wed, Mar 13, 2013 at 9:18 PM, Daryl Malas <D.Malas@cablelabs.com> 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
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-3.2

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

I hope this helps.

CB

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 <jdrosen@jdrosen.net>
> Date: Wednesday, March 13, 2013 6:06 PM
> To: "rtcweb@ietf.org" <rtcweb@ietf.org>
> 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.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>