Achieving Browser Differentiation With WebRTC

November 29, 2012

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?

You may also like

Comment​

Your email address will not be published. Required fields are marked

  1. I think you bring up a very good point: The Video codec. Coming from the world of voice and video conferencing the lack of interoperability has always been a problem, specifically in the video conference side, after Cisco acquired Tandberg the world expected a real change and integration, in which the release of TIP protocol was a good start, Polycom implemented it but in reality when we mention other vendors as Lifesize, Radvision, Vydio etc, each vendor has its own separate agenda and this interoperability dream is not close to be true. (BlueJeans is a different story ) This time the opportunity is huge and while this week in SF WebRTC conference there was a great discussion for WebRTC standard and the video codec to use I really hope to have an standard mandatory codec in which all browsers can interoperate, from a technical perspective this is possible from a legal and business we all know that bring up different implications, if browser vendors agree to have a video codec then we will have a real game changer, otherwise we just will have more of the same, Skype, FaceTime, VSee, Google Hangouts on customer side, Cisco, Polycom, Lifesize, etc on the enterprise world.

  2. I think you bring up a very good point: The Video codec. Coming from the world of voice and video conferencing the lack of interoperability has always been a problem, specifically in the video conference side, after Cisco acquired Tandberg the world expected a real change and integration, in which the release of TIP protocol was a good start, Polycom implemented it but in reality when we mention other vendors as Lifesize, Radvision, Vydio etc, each vendor has its own separate agenda and this interoperability dream is not close to be true. (BlueJeans is a different story ) This time the opportunity is huge and while this week in SF WebRTC conference there was a great discussion for WebRTC standard and the video codec to use I really hope to have an standard mandatory codec in which all browsers can interoperate, from a technical perspective this is possible from a legal and business we all know that bring up different implications, if browser vendors agree to have a video codec then we will have a real game changer, otherwise we just will have more of the same, Skype, FaceTime, VSee, Google Hangouts on customer side, Cisco, Polycom, Lifesize, etc on the enterprise world.

  3. Hi Tsahi,

    Amazing points on browser – video codec.

    In Enterprise scenario’s we are heavily dependant on the OeM’s and their capabilities to interoperate. Please suggest – if we can have this browser based Video codecs (if browser vendros decides to have video codec) implemented in the Enterprise environement and achieve more interoperatibility.

    Thanks,

    1. Anant,

      Think of the solutions today. They are no different. Even when the phone has an H.264 hardware codec, most chances are that your app can’t use it and you will be implementing it by software – and that is what is happening today with a lot of the iOS and Android ports for WebRTC that you see popping around.

  4. Hi Tsahi,

    Amazing points on browser – video codec.

    In Enterprise scenario’s we are heavily dependant on the OeM’s and their capabilities to interoperate. Please suggest – if we can have this browser based Video codecs (if browser vendros decides to have video codec) implemented in the Enterprise environement and achieve more interoperatibility.

    Thanks,

    1. Anant,

      Think of the solutions today. They are no different. Even when the phone has an H.264 hardware codec, most chances are that your app can’t use it and you will be implementing it by software – and that is what is happening today with a lot of the iOS and Android ports for WebRTC that you see popping around.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}