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

[Jonathan Rosenberg <[e-mail]>]

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