When everyone WebRTCs: are browser based codecs the future of VC?

Update:    Firefox just released Hello, which is free to use, and is what you would expect from a WebRTC app:  free, no plugins, no account, connect with anyone who has a WebRTC-enabled browser such as Firefox, Chrome or Opera.

When you start a conversation a window opens showing a self-view until the person you have invited clicks on the link and joins you. When they joins the conversation, there is an alert and the Hello icon turns blue.

Each conversation window has a shareable, unique URL for two people to communicate over video or audio. You can create multiple conversations and name them for different topics, making it easier to go back to the people you speak to regularly without having to create a new link each time.

Let’s review a few recent developments:  a significant announcement recently got a lot of attention in videoconferencing circles: Microsoft’s Skype for Web service will now use WebRTC.

WebRTC, (where RTC stands for Real-Time Communications) is a technology that enables audio/video streaming and data sharing between browsers via plugin-free communication of video, audio and data.  The announcement would seem to indicate that WebRTC now works in all modern browsers.  That furthermore we may be looking at the future of videoconferencing.  Right?

Well….Yes and no.

Yes, there is a plugin for Mac and Windows.

But no, even though Microsoft has done this for years in Lync UC, success in real-time communications is not generally a case of someone producing a new and awesome way of doing something.   Let’s take a quick look at the chances that a single, elegant standard like WebRTC will become a web standard for videoconferencing anytime soon.

I cannot imagine anyone explaining the challenges better than Bernard Aboba, the principle architect working on Skype.

He says that the plugin is a miniature version of Skype. “For audio it uses much of the same technology as the mandatory WebRTC codecs. It has a technology called forward error correction so it’s robust to packet loss and it can handle a wide range of video bandwidth. On the video side, it relies on the H.264 codec. It also supports simulcast and scalable video codecs, which allow video to scale all the way from a mobile device up to a large desktop system with a large screen, and have all those devices participate in a call at once.”

“Those are the technologies that need to be supported in WebRTC to give a good experience.

The term “good experience” means usable video and audio in a call.  We have all seen what happens when there is a small problem with sync, especially on the audio portion of a call.

So all browsers support the basics?  Like H.264, simulcast, scalable codecs, multi-stream?  Nope.

Chrome:  simulcast, scalable video codecs, multi-stream, no H.264.

Firefox:  H.264,  no simulcast, no scalable video codecs, no multi-stream.

IE: yes, yes, and yes, “in the future”.

You may be wondering why all this delay, when WebRTC has been here for years.  Note that even Google has only been using WebRTC for four months.  Some would also point out that WebRTC 1.0 isn’t actually done yet.  The delay can be attributed to two things:  tech issues and people/agenda issues.

1.   Technical

Aboba called building real-time features into browsers “a complex and risky project even for us.”  He is pointing to the fact that on video calls the slightest hiccup is incredibly disruptive.  The minimum standard in this world is similar to that of aircraft standards: anything short of full functionality and perfect reliability is unnacceptable.  Tough biz to be in, eh?

2.   People/Agendas

Simple fact:  a video call between 2 browsers will not work unless both use the same format for the video, right?  So think about how many players have to agree on that question, and how well they get along:  short list would have to include Apple, Cisco and Qualcomm, along with Microsoft, Mozilla and Google (remember VP8, the codec that is aimed squarely at H.264?).   Would it surprise you to hear that the “discussions” over which video codec browsers will have to support in WebRTC dragged on, and on?  Among the sticking points were licensing and royalties?  Apple’s only input to the discussion was to refuse to use VP8, for example.

There is progress, finally.  Enter something called Object RTC.  It’s based on JavaScript objects that are easier to work with than WebRTC, but would still be compatible with it.   And guess what?  Both Google and Microsoft are now involved with developing ORTC and it looks like many ORTC ideas are going straight into WebRTC 1.0, which will eventually birth WebRTC 1.1.  Might slow the whole thing down a bit, but seems more acceptable to more people, and is more compatible with what’s out there.

Challenges remain:

One –  battery life on mobile devices. Hardware acceleration is key, and not all devices support it.  You may have to get a new device to get to use WebRTC properly.   Apple and Microsoft for the most part have done so, others not so much.

Two – call quality can be significantly affected by capabilities like forward error correction and redundancy.  Note that there is not yet a standard for FEC, for example.  That really becomes clear when a VC call features multiple streams onscreen.

Why this is important:

WebRTC is an important technology with powerful implications for the way we will do business in the future.  Videoconferencing vendors will have to reckon with a world where soft clients begin to take over the large deployments that used to go exclusively to hardware vendors.  That is why an Audiovisual integrator should not assume that the hardware codec and MCU system commonly specified now will be the right thing 5 years from now.

People like Vaddio have been at the forefront of the new end point/soft codec strategy for years.  A knowledgeable integrator will plan and train for both hardware and software installs, with the help of their local rep.

Back to Mr. Aboba:  “We now have as much real time functionality as was in the enterprise quality systems of a few years ago.”

The rest of the world is getting there quickly.The only thing holding full implementation is lack of agreement on a common standard.  When browser manufacturers and developers get together on that one, watch out!

Dave Fahrbach