The Weakest Links of WebRTC

If there is anything that can impede WebRTC’s success it is WebRTC itself.

WebRTC is disruptive. WebRTC will change communication. WebRTC is great. But for all of its advantages it has its weaknesses. These in the end can make or break it if they aren’t handled in the long run.

Video Resolution

Our world is moving towards retina – higher resolutions and more pixels per square inch of display. In such a world, users expect video calling to be crisp.

Google have opted for supporting VP8 video codec instead of the more popular and wider spread H.264 codec – and for good reasons – VP8 doesn’t have the license costs baggage for patents that H.264 brings with it.

The only problem is that VP8 is new, and as such doesn’t have any native support of chipsets: with H.264, you can go on your latest mobile phones for HD resolution video decoding without hurting the CPU – it won’t even feel the burden. The reason for that is that modern chipsets today have included the ability to encode and decode H.264 bit streams in hardware.

VP8, on the other hand, doesn’t have that luxury. There are no chipsets in commercial products that do VP8 encoding or decoding in hardware yet. And while that is the case, WebRTC is going to suffer in two ways:

1. When using WebRTC, the CPU of the phone will work hard to encode and decode the video in software
   1. This leads to reducing the battery life
   2. It also takes up resources from other tasks and possibly reducing the user experience of the whole application/service
2. Encoding and decoding WebRTC today on mobile phones cannot go a lot more than VGA resolution (640×480), where HD resolution is 1920×1080.

This difference gives a head start for out of the box video calling solutions that can take advantage of hardware accelerated encoding and decoding.

At least until new chipsets catch up and start supporting VP8.

Apple

Apple isn’t going to support WebRTC any time soon.

It has vested interest in H.264, as one of the patent holders (that’s what QuickTime uses).

It has its FaceTime service to think about. It likes it closed, and WebRTC interferes with that notion.

Apple is the only web browser company who hasn’t publicized their support to WebRTC at this point in time.

When will they support it? If and when they see too many useful communication applications using it being adopted and the risk of being left with platforms that can’t support apps that exist on other competing smartphone only starts to show.

Mobile Adoption

Google have decided to focus on the desktop before supporting WebRTC on Android.

It is a reasonable move, especially when you look at the number and variety of demos running on WebRTC already.

The only problem is that the smartphone is where such a technology is really lacking – for the desktop we still have Flash. Not the best solution, but we can live with it. For mobile developers have nothing to work with.

Until vendors start showing WebRTC on smartphones and tablets things will move slowly.

App Store Support

WebRTC is geared towards the web browser – call it the de-facto operating system of the desktop and laptop. On mobile, that isn’t true – the most common way of spreading applications is through app stores.

To fit WebRTC into a mobile applications, developers will have two approaches:

1. Build the app using HTML5 and wrap it up with a cross platform tool. Nice, but limiting
2. Tear out the relevant C++ parts of WebRTC, port them to the mobile platform and tweak until it works

It would be great if Google just defined a simple C++ API and a Java one for their Android Application Framework and made the first steps of providing a vinyl source code version of it. From there, vendors will have an easier life in such an integration if they opt for developing native mobile apps.

–

Will this hinder the adoption of WebRTC? To some extent.

Most of it is solvable either through time or by a decision of priorities within Google. The Apple problem will stay a problem for years to come.