Achieving Browser Differentiation With WebRTC

Can WebRTC bring differentiation to browsers and assist them in adopting market share?

WebRTC is starting to get adopted by various browsers. And they are taking different approaches in doing so:

• Google Chrome is full steam ahead with their initial proposal, modifying the API as they go
• Mozilla Firefox is getting there
• Microsoft is working on their own spec for WebRTC, and probably will take their time in releasing support for it
• The only thing we know about Apple is that they want H.264 as the mandatory codec for WebRTC
• Ericsson is trying to launch their own mobile browser supporting WebRTC – with their own codecs of choice

How are the different browser implementations of WebRTC going to differentiate between one another, if at all?

Additional video codecs

There’s a war going on – which video codec will be the mandatory one for WebRTC. This war has 4 possible outcomes:

1. No video codec is selected as mandatory, which means you will need to choose the correct browser for the given web page you are going to access
2. VP8 will be supported, making Google and openness the winner; and may bring patent litigation by MPEG-LA to some unsuspecting, relatively high-profile web site using WebRTC in the future.
3. H.264 is the selected codec, causing a headache to browser developers who need to add WebRTC to their browser, which is distributed freely today.
4. Both VP8 and H.264 are selected as mandatory, which is effectively just as selecting H.264 alone for all intent and purpose.

Only time will tell which one will be selected, browser vendors can always add their own codecs as well.

Here are 3 additional codecs they might consider:

1. H.264/SVC. With scalable video coding, it will be way easier to implement multipoint. Google Hangout today uses H.264/SVC and not VP8 – so why not others?
2. H.265, the successor of H.264, which is starting to get some traction and initial demos by various vendors. It is said to reduce bitrate requirements considerably. This in turn enhances quality
3. The imaginary IETF video codec that is now collecting requirements. This is going to take a lot of time to get out the door, and the requirements are rather ambitious. Once it gets standardized, it will get into WebRTC.

The problem here is the decoupling between the application/service which the user consumes, to the web browser that is used by the user, but selected beforehand. This gives only companies like Microsoft and Apple any leverage here: using H.265 for their own services for example – they control the OS, the browser and the service. Can’t see it applicable enough for others.

Additional voice codecs

While this may appear like the same issue as the video codecs one – it isn’t.

Video codecs is all about progress – adding codecs that are technically better, or easier from patent licensing point of view. For voice it is all about interoperability into legacy systems. For voice, Opus was already selected as the voice codec of choice in WebRTC, placing it as the top performer – but one that is just too new, so there’s no existing VoIP service out there that supports it.

Other codecs are widely used today: iLBC, SILK, G.729, G.722 and more. By supporting them, voice transcoding requirements on the infrastructure side are reduced.

Is that reason enough to add them? I don’t think so, but only time will tell.

Better media quality

As with high end video conferencing systems, browsers will be compared by the media quality they offer. Place two laptops on the same network – one with Firefox and the other with Chrome; and then check on which one video looks better with WebRTC. Try it over Wi-Fi, LTE, with and without packet loss on the network.

What kinds of things can be improved/explored here?

• Multimedia handling – the selection of resolutions, seamlessly switching them properly, etc.
• Better congestion control, to make sure varying network conditions are worked out properly
• Focus on lower latency of media processing, to provide a better user experience
• Better packet loss concealment techniques to work better in packet loss conditions
• Optimization for specific types of network behavior

This shouldn’t affect interoperability between browsers – and it can’t be standardized beyond a certain point. This one is a real differentiator.

Will it be reason enough to switch between browsers? It just might.

Hardware codec integration

In browsers, the main competing criteria is speed: which one can render a page faster, or run Java Script code faster. WebRTC is computationally intestive. By offering hardware codec integration instead of software implementation (software implementations is what you experience today with WebRTC), several good things happen:

• Battery life increases. And if this is a laptop, tablet or a smartphone – this counts big time.
• Video quality usually improves – hardware is capable of using brute force techniques that software heuristics usually can’t use in real time.
• CPU usage reduces. Which means more power for other capabilities – other applications, other UI elements. This means better user experience.
• Solving patent issues. This one I am not sure of, but assuming the hardware codec already does an H.264 implementation – might this mean it already paid the relevant patent royalties to the parties involved?