Video CDN and Satyagraha: admitting defeat in the course to perfect live streaming.

Satyagraha, (Sanskrit and Hindi: “holding onto truth”), was the philosophy proned by gandhi when addressing the British Imperialism: non-violence, self-scrunity and research of truth. It lead to citations like “First they ignore you, then they laugh at you, then they fight you, then you win”, and more simple saying like “believe what they do, not what they say”, which should be applied any marketing material, really.

For the past two years, all CDNs and most streaming server vendors, have been trying to downplay the disruptive impact that WebRTC would have on their business. It wouldn’t scale. There would be no market for it. It would not be needed. It has now changed.

A first wave of streaming WebRTC CDN have emerged: Limelight, phenixRTS and MilliCast (*), showing that e.g. WebRTC can scale while maintaining an order of magnitude lower latency than the traditional offers. The traditional CDNs were left with no excuse and still had no answer to WebRTC-based solutions. They did what anybody with money would, and moved on to the next … “marketing spin”. Other, smaller and tech-oriented company realise the trend, and recognise it publicly, but think that there is space for both technology stack: a more mature slower stack well-adapted to pre-recorded content streaming, or VOD, and WebRTC more suited for real-time content. For example, the founder and CEO of bit moving, co-inventor of MPEG-DASH, opened his talk at NAB 2019 about CMAF saying just that: if you re looking for real-time WebRTC would be better, but for any other cases, and there is a lot of them, MPEG-DASH and HLS are still the best out there, and CMAF is a much welcome improvement to them.

Some come up with new protocols that will save the world, and their business, from WebRTC.
– For Wowza, WebSocket is the solution, even if it does include any media related reliability, and is still an HTTP-based protocol.
– For Haivision (and wowza), SRT is the solution, even if it is not a standard, unlike WeBRTC which went through the standardisation process at both the W3C and the IETF, and reached consensus, and will never be accepted in Browsers: at least it provides some kind of answer.
– For many CMAF is the current hope word: “wait, don’t leave our service, we are going to make it faster!”, which is true, but hide the fact that by design, “faster” for HTTP-based (transport) and file-based (container) technologies can only go so far as a second or a couple of second latency.

Very recently, we can witness a new phase of the organised retreat from the traditional video CDNs: “granted, we cannot achieve the same level of latency, granted, our scalability is but marginally better, and the quality is admittedly in par, so, let’s not speak about that, it’s not important anymore. Instead of embracing the new disruptive tech, or in order to buy us time to do so, let’s go into smaller and smaller niche to differentiate, by coupling the “live” keyword with some other keyword we believe WebRTC CDNs can’t achieve yet:

LLNW:Live events require ad-insertion and forensic Watermarking”
may 2nd

VDMS: “Live events require ad-insertion.
may 6th

And of course, the old school Fear Uncertainty and Doubt (FUD) tactic used by bigger corporation against smaller ones, as infamously illustrated by Microsoft halloween memo in 1998:
– “They are small, they can go belly up anytime, we’re a big corporation, nobody has ever been fired for buying IBM’s”
– “They are young, they do not know what they are doing, we have been doing this for decade.”
In the later case, in the words of Verizon Digital Media Services it translates into this:

As a live event streaming platform that has supported thousands of live sporting events, including some of the largest leagues, biggest venues, and most watched games, we’ve had to address these concerns. Working closely with our customers, we’ve continually evolved and optimized every aspect of our live streaming video workflow and architecture so we can keep up with rising viewer standards for streaming quality.” (link)

Alas, it is all past tense.

First they ignore you“. As a conclusion, there is a lots of indication that the streaming and broadcasting ecosystem is now aware that not only WebRTC exists, but that it is viable.

“Then they laugh at you“. We see multiple attempts at trying to half-heartedly adopt it , at undermining its disruptive effect, or at preventing losing too much market to it.

Then they fight you“. One thing that people seems to be oblivious to is the speed at which WebRTC and corresponding offers mature. Two to three years ago, there were no WebRTC CDN (PhenixRTS was still phenix P2P and they had not understood yet the best way to use WebRTC for streaming). Today, a couple of years later, there are several WebRTC streaming services doing a good enough job to capture a part of the streaming market.

The web economy is not on vacation either, and Facebook, AWS, Google are all pushing the boundaries of the possible with e.g. project Stadia, defining Next generation of Codecs (AV1), network transport (QUIC), and of course WebRTC NV, all of which allow WebRTC-based services to evolve faster than the rest, on the shoulder of giants.

Given the speed at which those new players have came to market, it wouldn’t be surprising to see them invade quickly the rest of the market, adding features the traditional CDNs think are differentiating like server-side ad-insertion, forensic Watermarking, and the like before the end of the year.

Then you win“.

More technical details and ideas can be found in our recent presentation at Live Streaming East here.

(*) – NetInsight, Id3as, nanocosmo, wowza service get sometime mentioned, but it is not clear wether they are WebRTC end-to-end, i.e. it is not clear wether they can achieve as low a latency as WebRTC does.
Video Conferencing services like Tokbox, Twilio,, …. also get mentioned, but the design of a Video Conferencing platform is vastly different from a streaming platform, and they are likely not to be competitive for a streaming usage.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.