State of #webrtc in Media Streaming and Broadcast

With COVID-19 out there, people have to reinvent the way they live and the way they work, remotely from the office but also remotely from each other. Webrtc technology being rooted in conferencing and collaboration, those topic understandingly take the front line.

However, this is not the only space being disrupted by WebRTC.

For a certain time, webrtc has been pushing the boundaries of can be done in real-time streaming, and the pandemic is only accelerating this. This blog post is a follow-up of previous posts and show the evolution of the situation, and how the pandemic is actually creating new use cases and transforming the streaming market.

Introduction

A few months back, last year, Jan Ozer, maybe the most prominent blogger in the streaming industry, wrote a joint article with wowza’s CTO.

That article received a lot of back push from the webrtc community (look at the twitter thread), especially from some open source media server developer, and motivated me enough to write a blog post about how deceiving it could be.

While some bloggers and consultants would write anything for the right price, Jan Ozer is not of that kind. He looks for knowledge, and accumulate knowledge before others to be able to bring value to his customers. Value is coming from giving “the” right answer, not “a good enough” answer, and you need to look for the truth to get that kind of value.

Feeling that there was something more to say about webrtc than what he had assumed so far, he went on to locate and have a session with every webrtc vendors equally in the streaming space, and bring the knowledge back to the streaming industry through a blog post in Streaming media, the leading publication in that industry. The resulting post title alone made my day: The Need For Speed. I can only thanks him for having the ability, and humility, to challenge what he thought he knew, put in the effort to check the fact, speak with everybody equally, and reproduce some of the results by himself.

That, for me was the starting point of a change in perception of webrtc in the streaming industry.

What is real-time Streaming? Do you mean “Live”, or Ultra-Low-latency? How good is webrtc anyway?

Previously, webrtc wasn’t perceived as an option for streaming media at all, it would not work, would not scale, quality would be barely passable for webcam calls, …. We spoke at length in this blog about every single one of those misconceptions, largely carried by vendors who would not have a webrtc offer, or would have a very poor webrtc implementation. Google Stadia was instrumental in showing that high quality at scale and with very low latency was possible.

The perception of the industry, was that any solution or use case which would require less than 5 seconds latency would fall in the ‘live’ bucket, or the brand new Ultra-low-latency (ULL less than 3 seconds) bucket. The corresponding markets would be too small, and would have acceptable technical solutions. In an industry dominated by the Video on Demand model (netflix, HBO+, dysney+), who would want or need real-time?

The reality of course, was different, and not only some use cases became orphan with the removal of flash, the latest of the real-time protocol, but the ubiquity of mobile phone started a latency race for people watching live events, sports, or e-gaming championship over ‘live’, 5 second delay, paid channels, while their friends calling them with free (webrtc) apps could provide them with the same content much faster. In a previous post we have spoken about how big players like limelight network, or Verizon Digital Media Services had already tried to position themselves in reaction to this.

In march, streaming media wrote again about those subjects. However, this time, reflecting the perception shift in the industry, they did not one, but two articles (low latency, and live), separating the technologies and solution vendors for ‘live’ streaming, that could be done as an extension of traditional Media CDNs, and ‘Real-Time’ streaming.

The reality is that ‘Real-time’ has now a big enough market, and demand, as well as a different enough set of technologies to have its own category. With demand comes entrepreneurs. The list of Real-Time services and server vendors has almost doubled in a year, including recognition for Millicast.io and CoSMo technology.

Circumstantial at best, what else do you have to show the age of real-time streaming as come?

Maybe more interestingly, there are other move from actors that reinforce this idea that webrtc is really emerging.

Wowza is closing their ULL cloud offering and mentioning that they will shift to webrtc, …. one day (here)(*). This is a huge move for a vendor that was especially outspoken about how bad webrtc was, and how they could do anything anyone would want. Shutting down a cloud offering can only means it was not sustainable.

It is also telling to see that Wowza, one of the original founder of SRT which was positioning itself to directly compete for secure real time media, is moving to webrtc, instead of adopting SRT. Actually, SRT members have been trying to bring SRT to the IETF for a year. The leading expert in security of the IETF, as well as some other world leading expert, have expressed the opinion that SRT does not seem to be secure, nor terribly real-time and overall not bringing anything on the table that SRTP/webrtc would not already do, or that QUIC (HTTP/3) will not provide. The IETF public discussion is especially interesting to follow, here.

We touched a little bit on previous posts how ABR was a good solution to bitrate adaptation, if one is using a file-based, HTTP-based media protocol like MPEG-DASH or HLS. Bitrate adaptation is mandatory to have to sustained streams over the public internet, where fluctuation of available bandwidth are frequent and expected. It was maybe one of the two main features that was missing from RTMP (the other being NAT traversal). ABR, by design, cannot achieve real-time streaming. For real-time streaming, codecs researcher and real-time streaming researchers came up with one solution each.

Codecs developers invented SVC (around 15 years ago, first available in H264 annex G), which provides a single encoder the capacity fro generate a single file which contains interlaced, or layered multiple resolutions of the original media.

Real-Time media Streaming in parallel implemented in the main webrtc stack simulcast, which is basically ABR on the sender side, directly from the source, and divide the usual latency of ABR by two. Nowadays, the webrtc default stack can handle simulcast, SVC, and a mix of both, for most codecs.

Maybe more interesting in a time where security of content is important, and consumer want to control how the content they buy or consume is beng consumed and protected, ABR is not compatible with end-to-end encryption. DRM only provide protection for those who trust the media platform, and the player. This is a level of trust that new real-time content provider, live event producer, life (TV) show producer, might not entertain anymore, as they would like the content to be encrypted directly from the source and control who it is sent to , or who can view it, by themselves. ABR, by design, need to access the raw data, and cannot be use din conjunction with E2EE, while simulcast and SVC, being done sender side, happen before the encryption and can run without modifications.

This is not new, what is new is that ABR implementation are now being legally challenged and companies that use it targeted (here).

Conclusion

The (Live streaming) fort is under attack. WebRTC is seemingly winning some battles, passing over the FUD, and it’s showing through the shut down of some platforms.

The streaming industry does not seem to have the equivalent of what WebRTC provides today for real-time streaming, and thus can’t answer the growing demand for Real-Time streaming.

Their are under attack on both sides, as Netflix is growing on the more usual VOD streaming business. Both have in common to follow the Web technology train.

One could argue that the internet already disrupted the streaming industry once, forcing a merge of what used to be telecom and entertainment (ITU and MPEG). Suddenly people could do with a computer connected to the internet (with a dvd player and a GPU) what required specific hardware and dedicated connection. You still needed appropriate software, players and codecs.

Now that people can do in a browser, on a normal computer or laptop (mobile phone!), what required a beefy computer, with specific hardware and software, the industry is being disrupted again. As the web is also evolving MUCH faster than other technology pools, is accumulating most of the revenue, and is pushing for royalty-free solutions, we are in fact witnessing a blitzkrieg…

Bop!

(*) Wowza: “These cutting-edge technologies include Apple’s Low Latency HLS (Preliminary Spec) as well as enhanced options for WebRTC, enabling the delivery of interactive, low-latency video at scale. As open standards, these approaches will provide you with access to the latest industry technologies, as well as greater player flexibility for delivering an optimized experience to your viewers worldwide. These technologies are currently in early development, and delivery is targeted for the fall of 2020.”

Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.