Comparing WebRTC, Skype Video Quality

We often get asked about what we think about WebRTC and Skype video quality, and how they compare to each other.

There are many different ways to start a discussion about this, but the fundamental difference comes down to this: WebRTC is a technology. Skype is primarily an application.

WebRTC enables it’s proponents to embed video, audio, and data interaction into applications, to make real-time interaction a part of the user experience and to bring context to communications. When people use Skype, they do so within the context of Skype itself. It’s a standalone application whose sole purpose is to enable video, audio, and chat interactions.

Skype does what it does, very well. There’s a reason why Skype is often used as a fallback for many people who end up frustrated with trying to connect to people through other communication tools.

WebRTC has come a very long way since 2012 when Temasys started working with it and made the decision to build a business around making WebRTC as easy to use as possible. With WebRTC’s evolution over the past couple of years, and in part because of what we’ve done with Skylink, our platform as a service (PaaS), and to another extent, our WebRTC Plug-in for Internet Explorer and Safari, there is a lot of interest and more questions that we receive on a regular basis about how Skype and WebRTC compare in other ways.

WebRTC, Skype Video Quality

The other day a customer asked me about how WebRTC and Skype compare in terms of video quality, so I thought I’d take a few minutes and write a short post about that.

Having been in the real-time communication industry for over a decade, I’ve been a Skype user since the beginning. We have to begrudgingly admit that, lately, Skype has been doing a good job at providing audio and video services over “best effort” networks, aka The Internet.

Skype has put in an enormous amount of engineering in their communication protocols, their audio video encoders/decoders, and their ability to manage a quality experience given the available network conditions a consumer may have access to. Just looking at video quality for example, when a wideband connection starts to be constricted into a narrow-band connection, Skype excels at being able to manage that experience by adjusting the bitrate, frame rate, and video resolution. These parameters are the key knobs to adjust when managing quality. Allowing users to maintain continuity in their conversations with audio/video adjusting appropriately is important to making video pervasive and accessible.

The end result? There is a reason why so many people use Skype as a fallback when other communications services and applications just don’t work. Still, it’s a standalone application, and even with Microsoft’s efforts to get developers to “transform their solutions with integrated communications and the power of Skype“, they’re a long way from making it as easy and powerful as WebRTC can to enable contextual communications.

A comparison between WebRTC and Skype media quality has to take into account the specific use case. For the sake of simplicity. let’s focus on delivering media between just two peers or “callers”. The ability to manage bandwidth for multi-party calls with more than just a couple or a few peers is more complicated (and more fun). We’ll save that for other discussions.

WebRTC and its current implementation

• The major web browsers out there each provides some basic capability related to bandwidth management. If you’re building applications with real-time communication features powered by WebRTC, you have some ability to set the resolution and bandwidth constraints for video and audio interactions, to manage the experience for your users. The core WebRTC engine does have built in mechanisms to provide feedback between media streams (RTCP-FB) and it will attempt to correct and adjust bit-rates in response to bandwidth quality. And some browsers have also allowed the ability to reoffer SDPs with adjustments to the bandwidth attribute (although you may have to modify them yourself).

WebRTC 1.0 Standards Changes

• The W3C have certainly heard that adjusting the target quality/bandwidth is something developers do want to do while a stream is active. The ability to massage RTP sending parameters, specifically degradation preferences, priority, framerate, bitrate and resolution scale have been plumbed in. Not only will this allow WebRTC developers to be able to change some parameters, but it will also future proof us for codec advancements like scalable video coding (SVC).

WebRTC in the Future

• As Vidyo and Google continue to work together, having an “encode once but send multiple resolutions” type codec will help developers adjust codec resolution dynamically. There are many advantages to supporting an SVC codec as adjustments will not require a renegotiation or re-encode or codecs. The browser’s current WebRTC implementations do not have an SVC compatible codec built into it. When this happens, I’m excited to see codec support for SVC regardless if it is VP9, H.264 or HVEC (H.265).

So what does this mean?

Currently, WebRTC-enabled applications such as Facebook Messenger and Google Hangouts, or any application powered by our own Skylink Platform as a Service do provide a good communication experience. There are other areas where we think WebRTC has massive advantages over Skype. And while Skype has invested in  video quality and media processing improvements over the last year or two, WebRTC leverages the best open source codecs for video and audio, and there are mechanisms available to help manage video and audio quality in WebRTC-powered applications. There will be more improvements coming soon, and we’re excited about the future.

As technology advancements make the leap into real world implementations, we will see video experiences that adapt very well to the reality of best-effort networks. WebRTC will ultimately provide the best experience for given network conditions, by leveraging the best video and audio codecs as part of the standard.

We’ll discuss other aspects of how WebRTC compares to existing applications and technologies like Skype, going forward, but I hope this is helpful to people who are wondering how the two differ in terms of managing video quality.