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
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. More on that in a sec.
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.
Project Stream official gameplay capture: 1080p@60fpshttps://t.co/SjznbRCBAP
— Justin Uberti (@juberti) October 2, 2018
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.
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