4 Reasons to Choose H.264 for your WebRTC Service (or why H.264 Just won over VP8)

H.264 is set to replace VP8 for WebRTC services.

You can thank Fippo for making me write this one.

Microsoft ended last week with an announcement of sorts on their Edge dev blog, indicating that H.264/AVC support for ORTC is now available in Edge.

• Yes. It is ORTC and not WebRTC
• Yes. It is only behind a runtime flag
• Yes. It is only on Edge. No IE

But then again, it is the only way today (or at least tomorrow) to get a video call running cross browser between Firefox, Chrome and Edge. VP8 or VP9 gets you as far as Chrome and Firefox.

Which got me to this one over here. Edge support for H.264 in ORTC isn't much. It isn't even interesting in the bigger scheme of things (Edge has literally no market share compared to the other browsers, so why bother with it?). And still it marks a turning point - one in which we can all ask ourselves what video codec should we be leaning towards if we started developing a product that uses WebRTC today?

Last year, the answer would have been "VP8".

A few months ago, it was, "it depends".

Today, it will lean towards "H.264, unless you must use VP8".

Here are 4 reasons why this is happening:

#1 - Browser interop baseline

If you want your service to get the most coverage on as many browsers as possible and you need video, then H.264 is the way to go. In a few months, H.264 will get official support by all of these vendors and that will be the end of it. Furthermore, you can expect Apple to use H.264 first and contemplate VP8 - same as Microsoft is doing now with Edge.

#2 - Mobile

Mobile devices like H.264 more than they like VP8. Video codecs take up a lot of resources. To overcome this, mobile handsets use hardware acceleration for video codecs. They all have H.264 video acceleration (though you can't always gain access to it as a developer). Many of them don't even know how to spell VP8. This boils down to WebRTC implementations on mobile needing to implement VP8 using software.

Some developers ended up replacing VP8 with H.264 on mobile just because of this reason. Especially for mobile only products.

While I am sure support for VP8 is improving in new chipsets, there's this pesky issue of supporting the billion and more devices that are already out there. And now that all browsers support H.264 in one way or another, what incentive do developers needing to support mobile apps have to use VP8?

#3 - Legacy video systems

All them video conferencing systems? They use H.264. Most don't have VP8. Not even in their latest released products. The way they end up supporting WebRTC until today is via a specialized gateway, on the MCU or not at all.

Transcoding was one of the main barriers to getting WebRTC to legacy video systems. It just costs a lot. It would have been easier to just go H.264 all the way. Which is what is now available.

It is one of the reasons why Cisco first worked on Firefox with Spark. It made a decision to use H.264 for WebRTC instead of transcoding from VP8.

#4 - Streaming

Over 60% of the Internet traffic is video. Most of it isn't real time video, but rather the YouTube or Netflix kind. Passive consumption.

Video streaming today is predominantly H.264 based, and at times VP9 (=YouTube whenever possible).

To get video content on an iPhone device, HLS is required, and that again means H.264.

So again we are left with the alternative of either transcoding our WebRTC generated content to H.264 when we want to stream it out - or to create it using H.264 to begin with.

Do you even care?

If your service is a 1:1 calling service with no server side media processing, then you shouldn't even care. In such a case, whatever the browsers end up negotiating will be good enough for you (and most probably the best alternative for that specific situation).

Those who invested in server side media processing, be it recording, mixing, routing -  have made investments that are targeted at VP8. Modifying these to work with H.264 as well may not be trivial. For them, the decision of switching to H.264 is a harder one to make, but one that needs to be addressed.

The Future of Video Coding in WebRTC

Once we step into the future, we see VP9. And the SVC flavor of VP9.

And then there's the Alliance of Open Media and the work they are doing towards a widely accepted next gen royalty free video codec. So much so that we now have a new video codec war in WebRTC: AV1 vs HEVC.

For the record, I rather hate H.264 and what it stands for. But now I must accept that it is here to stay and grow with WebRTC.