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

[Mark Weidick <[e-mail]>]

+1
Ben has this right based on our in market experience to make a commercially
viable service based on WebRTC - and we can corroborate his analysis with
real data.  

We have more than 1,000 businesses using our reference application and
dozens of companies have used our APIs to embed WebRTC based video within
their applications.  They care most about 1) working in the browser of their
choice, so cross-browser interop in Ben's words, 2) mobile and 3) cost.

Based on our real world interaction and across each of the use cases that
Ben highlights, interop with legacy endpoints isn't even on the radar.  In
fact, with increasing frequency we encounter video "room systems" that
consist of a flat panel display, a webcam, a PC/Mac and a browser that can
run a WebRTC app.  The so-called legacy endpoints seem to be going to zero
in terms of relevancy.

Mark

From:  Ben Strong <[e-mail]>
Date:  Thu, 14 Mar 2013 11:24:36 -0500
To:  "[e-mail]" <[e-mail]>
Subject:  Re: [rtcweb] A different perspective on the video codec MTI
discussion

I've been talking to developers who are interested in building WebRTC apps
regularly for the past year and have drawn the opposite conclusion about
their preferences.

Before going into what they want and why, let me give you a flavor of who
I'm talking to: These are primarily inbound contacts who are interested in
the vLine WebRTC platform. I think they're pretty representative of the
non-legacy use-cases for WebRTC, but almost certainly under-represent the
existing enterprise market.

* Over half are building apps for healthcare or education. I'd say it's a
pretty even split between those categories, and within each category it's a
pretty even split between startups and more established organizations.
Non-profits make up a substantial fraction of both groups.

* Over half are outside the US, with most of the international interest
coming from developing countries (e.g., India, Brazil, and China).

* Not one of them has been interested in enabling video for customer service
calls (though a number have been interested in voice). I mention this
because it's frequently cited as an important use-case and I expected it to
be an important market for us, but I'm beginning to wonder if businesses
actually want this. I'll admit that those who _are_ interested are more
likely to be talking to Jonathan than to me, so take this with a grain of
salt.

* A sampling of other apps people are building: translation services (both
for foreign languages and sign language), social commerce services, and
social apps with all sorts of interesting new interaction models.

Here's what I've heard from them:

* The only questions I have ever gotten about interop with legacy equipment
are in regard to voice. I do occasionally talk to people with existing
investments in video conferencing systems, but they are mostly interested in
moving away from them (huge sample bias here, of course).

* Very rarely does the subject of codecs come up other than the context of
whether the browsers will all interoperate. The only concerns I ever hear
about VP8 quality are from people who haven't actually used WebRTC in
Chrome. The feedback I get from people who have used it is consistently that
they are surprised by how good the video quality is.

* All of them care about having a good mobile experience and do occasionally
express concerns about the battery life and performance impact of software
codecs.

* _Everyone_ is concerned about cross-browser interoperability. It is far
and away the biggest concern I hear about WebRTC, and I can't remember the
last time it didn't come up in a conversation with a customer.

Finally, here's my take on it all:

>From a power and performance point of view, H.264 is undoubtedly a better
option on devices with a hardware codec for it. Implementations on those
devices should by all means support it and attempt to negotiate it.
Implementations on other platforms where it is feasible to support it,
either because the implementation vendor has a license or the OS includes
it, should by all means support it as well, for the sake of allowing mobile
devices with a hardware codec to use it whenever possible.

I'm happy to grant that H.264 is technically superior to VP8 in every way
(though I think the differences are negligible in real-world use). By all
means implementations that wish to should attempt to negotiate it for that
reason, as well.

However, I fail to see how either one of those points has any bearing on the
MTI decision. The whole point of MTI is guaranteed interoperability across
all WebRTC implementations, which is absolutely critical to WebRTC adoption.
The only criteria should be the best quality codec which can be supported by
all implementations. And because some implementations are open source, it
absolutely must be royalty free.

I've already gone on too long here, but I want to make one final point on
open source. There are two new mobile platforms that have the potential to
drive innovation around mobile apps in general and the mobile web in
particular, and both are open source: FirefoxOS and Ubuntu Mobile. Neither
will be able to be WebRTC compatible unless a royalty-free codec is chosen.

I would argue that FirefoxOS and Ubuntu should be of special concern to the
working group for three reasons: 1) They support web apps as first class
citizens. Since the main goal of WebRTC is to make it possible to build rich
apps entirely with web technologies, I would hope that the innovators in
that arena will be able to support it. 2) I expect that some of the areas
where WebRTC will have the biggest impact (e.g., telemedicine in rural
India) will be most concerned about using a low-cost, open source platform.
3) Even without every being market-share leaders, open source platforms tend
to drive innovation across the whole market. The best example of this is how
Firefox kickstarted a decade of innovation in browsers and web apps. I have
high hopes that FirefoxOS will do the same.

Adopting a codec that will more firmly entrench legacy providers at the
expense of some of the most innovative new platforms out there seems like a
bad trade-off to me.

Ben

[this post will probably need moderator approval, so apologies if it shows
up after the conversation has moved on]

--
Ben Strong
[e-mail]



On Wed, Mar 13, 2013 at 5:06 PM, Jonathan Rosenberg <[e-mail]>
wrote:
> 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.
> [e-mail]
> http://www.jdrosen.net
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

_______________________________________________ rtcweb mailing list
[e-mail] https://www.ietf.org/mailman/listinfo/rtcweb