There should be no doubt about WebRTC anymore. It is here and it is ready for everyone. The question is: “now what?” Where are we headed with WebRTC in 2019
Is WebRTC Ready Yet?
That was the name of a website that tracked how well is WebRTC adopted by the various browser vendors.
Apparently, it is also the most common question on Google about WebRTC:
It is time we say it outloud (I don’t believe anyone has done that up until now):
WebRTC is READY
I was asked to speak at Apidays Amsterdam last week, which was a true joy. The topic I was tasked was around WebRTC being a standard, and well… where are we headed next. So I decided to rephrase it a bit and ignore that tiny bit of a fact that WebRTC 1.0 still isn’t an official standard (nobody but those in standardization organizations and those opposing to adopting WebRTC seem to care either).
So I sat down to think what does it mean that WebRTC is ready. Which led to this question:
Why I think that WebRTC is ready?
The best way for me to answer that question was to give 3 recent examples on things happening with WebRTC (and I don’t mean Uber doing VoIP using WebRTC):
#1 – VP8 Supported by Safari
I’ve been a critic about Apple’s non-support of WebRTC and then Apple’s non-support of VP8.
The fact that Apple decided at the time to support only the H.264, a royalty bearing video codec, and ignore VP8, the royalty free alternative, wasn’t a good sign.
In the past two weeks, tweets and webkit bug links have been flying around, indicating that if the mountain won’t come to Muhammad, then Muhammad must go to the mountain. Or more accurately, that Apple decided to do a Microsoft and support VP8.
Do a Microsoft because this is the same steps Microsoft took when going WebRTC. Starting with H.264 and only later adding VP8.
So Apple has started with H.264 and only now adding VP8.
When will this be available for all? Ask Apple.
What’s important is that ALL modern browsers now support both VP8 and H.264. And when it comes to WebRTC browser support in general – then we’re in quite a good place already.
—
It doesn’t stop there either. Apple joined the Alliance of Open Media as a founding member. This alliance is behind the future video codec AV1, and now has 40 members in it.
#2 – H.264 Simulcast Support
The second example is H.264. It is now becoming a first class citizen.
H.264 on Chrome didn’t have simulcast support. The “fix” for that was available for quite some time, but was never incorporated into Chrome. Simulcast increases the quality of group video calls, so not supporting it in H.264 made H.264 useless for group video calls.
There can be two reasons for this feet dragging by Google:
- Timing and priorities. Google didn’t really care enough to add that in and deal with the headaches of pushing code from a third party with the fix and validating it
- The push towards VP8. Increasing the quality of H.264 would get more developers to adopt it, especially when Apple supports only H.264 on Safari
Since VP8 is coming to Safari, the reason to give it an edge over H.264 isn’t there anymore. Especially considering the healthy growth of the Alliance of Open Media.
The end result?
- All modern browsers support VP8 (Safari support is imminent)
- All modern browsers support H.264; and simulcast will soon be possible for it
- VP9 is available only in Chrome and Firefox for WebRTC – but who cares? The future will be AV1. And ALL browser vendors are part of the Alliance of Open Media where AV1 is getting specified (YouTube is already testing AV1 decoding in Chrome and Firefox)
This media codecs disparity between browsers was the main challenge for the WebRTC community. It is now behind us.
#3 – Google Shifts Focus
That third reason why I believe WebRTC is ready?
Google is shifting focus. It is doing what is needed to support WebRTC and the migration to the 1.0 specification (unified plan for example), but its heart and mind is already elsewhere:
At the beginning of this month, Google announced Project Stream – a cloud based service that streams high end games from resource intensive cloud based machines to low end devices in real time.
There’s not a lot to go on about the technology, but it seems to be based on WebRTC.
Why else would Justin Uberti from Google’s WebRTC team publish this? 1080p resolution at 60 frames per second with low latency for gaming. This type of a use case is different from real time communications. It requires a different focus and optimizations. And yet… the WebRTC team at Google have probably spent some cycles on supporting it.
Why is that a good thing?
Because for Google, WebRTC is ready when it comes to real time communications, and beyond optimizations and house keeping, it is time to move on and look at other use cases where WebRTC can be beneficial.
What’s Next?
So. WebRTC is here:
- Apple supports it now; and there’s codec parity across browsers
- H.264 is a first class citizen in WebRTC
- And Google has moved on to other use cases for WebRTC
What’s next for WebRTC?
The answer I gave in that presentation at Apidays was Machine Learning.
I like that slide above. I like it because you can take RTC out of it, replace it with whatever word/term/industry you want and it will STILL be true.
In the rest of that presentation, I went over the research report that Chad Hart and I have written, sharing some of our findings.
I went into the 4 domains we’ve mapped in our research, in each giving an example of the impact and use cases that are now possible:
- Speech analytics, and how we’re shifting from offline processing to real time
- Voicebots, and how work in that area is accelerating
- Computer vision, where use cases are vastly different between consumer and enterprise settings
- Media optimization, and the shift from heuristics to machine learning
That Deck from Amsterdam
That slide deck from Amsterdam is now available online as well. You can view it here:
Machine Learning and Real Time Comms
If you are interested to learn more about machine learning, to be able to make smart decisions in your own company about the use and introduction of machine learning and artificial intelligence in a communications application, then definitely check out our report: AI in RTC
Answers to other common “is WebRTC” questions
Yes. WebRTC is ready. You shouldn’t wait more until it “matures” – just start using it already.
Yes. WebRTC has security by design.
All traffic sent over WebRTC is encrypted, with additional layers of security added when needed. You can learn more about WebRTC security.
Yes. WebRTC is an open source implementation (webrtc.org) as well as a standard specification that is free for all to use.
The open source license for the main implementation is permissive enough for everyone to use.
Yes and no.
WebRTC is a standard specification (=protocol) defined by both the W3C and the IETF. The W3C is in charge of specifying the web browser APIs for WebRTC while the IETF deals with what goes in the network.
WebRTC is also a specific implementation of the specification that is found at webrtc.org and maintained by Google.
Most people don’t make any specific distinction between the protocol and the implementation when referring to WebRTC.
No. It is very much alive and just starting to take off.
WebRTC is part of the web browsers today, and there is no other alternative to it at the moment when it comes to providing real time audio and video communications in browsers.
Tsahi – any insights on HW accelerated encoding in desktop browsers? Looks like both Chrome and Firefox are still using software encoders on Windows/MacOS, is it ?
None at all I am afraid.
While acceleration is available in many desktop devices, Google haven’t focused on using them. Main reason is probably the better quality that can be reached by software encoders which are easier to modify and tweak.
It is looking like WebRTC is ready for the “big time”!
Just kinda reading between the digital lines of technology and a couple “wild ass guesses”! 🙂
Lot of stuff buzzin’ around my cranium.
100,000-foot level stuff.
I think WebRTC “really takes off” once all browsers also support either an AV1 software codec, AV1 in embedded mobile GPU (aka Apple mobile processor) and/or AV1 embedded in low power silicon chip.
Also just thinking out loud, WebGPU (Apple tech)
will “rip a direct path” to the Mobile embedded GPU for Mobile Browser apps (True Interactive Distributed Cloud Gaming, AR/VR, Machine Learning, AV1-based 4k UHD Video, etc.) add WebAssembly, RUST programming language and a few other goodies from a browser perspective and I think we will see some very interesting uplifts to WebRTC in the coming Web Epoch….the “Real-Time Web”, in browser platforms. Seems that mobile operating systems are starting to get in the way of progressive innovation on the Web and a few bypasses are required. H.264 served it’s purpose at Apple and now with the web becoming visually focused (i.e. Live Video IP Broadcast, Video on Demand, Cloud-based Game Play, etc.) for its Mobile use base (Billions and Billions) and the crushing demand of compute, memory, network and storage of video applications, video apps will find a “safe refuge” in today’s modern browsers to continue to provide compelling revenue and profits for Apple, Google, Facebook, Amazon and other web properties hangin’ around the edge of the net.
Also, think Google Android may be hitting a wall. Think Chris McKillop’s (Google Engineering Director) Fuchsia OS may be a good candidate for a Modern Google Android to deal with the demands of future WebRTC apps, again just a crazy wild ass guess.
https://twitter.com/chrismckillop?lang=en
Oh yeah, forgot the one critically important value proposition of AV1….”no royalties”. That’s the “kicker” that “will bury the digital needle” in moving the Visual Web forward and help WebRTC a wee bit.
Just plain good business common sense, among many, many other business and technology decisions in the rapidly, evolving web ecosystem. 🙂
Cheers,
Ron
Did I miss something? How is Safari ready for webRTC when it only has limited support in desktop Safari and not at all in standalone mobile? Did this change?
In some ways, you have.
Safari supports WebRTC as much as can be expected from a new entrant. There are gaps in the implementation but these will be resolved at their own pace now, without the big question “Will Apple support WebRTC”.
VP8 is coming to Safari as well, so that’s behind us.
There are companies already in production who support both desktop and mobile Safari.
h264 simulcast (for openh264) is supported in libwebrtc (google validated and accepted the patch), it isn’t yet enabled on chrome and not sure what will happen with firefox when they updated to the appropriate version. Safari “ported” the h264 for hw accelerated h264 on mac/ios.
Sergio – thanks a bunch for the clarification on this one (and for getting it done)
Thank you for great article. I am wondering why there are no public services for p2p file transfers. Those kind of things would require very little or none server power since at the end after signaling ends all traffic goes trough clients. There was one which is now dead.
Mihajlo, I guess it has to do with a business case and simplicity. For the most part, cloud storage and cloud transfer services are good enough and offer an asynchronous experience (I can send you a file whenever I want and don’t need to be online when you receive it). Then there’s the business case question – what does the service provider has to gain from offering this capability? How does he turn it into a profit, and why would people use it?