Content Delivery Networks (CDNs) are a popular way that many video streaming services send out their video so it can be watched by all the people that want to see it. CDNs work by caching information on the various data centers they have distributed across the globe. As each data center is a server, it… Continue reading 8 CDN Video Streaming Server Solutions: Do They Work?
Content Delivery Networks (CDNs) are a popular way that many video streaming services send out their video so it can be watched by all the people that want to see it.
CDNs work by caching information on the various data centers they have distributed across the globe. As each data center is a server, it could be said that each CDN is made up of a series of CDN Video Streaming Servers.
Akamai, one of the largest CDN providers, defines a video streaming server this way:
“A video streaming server delivers video content over the Internet to a user with a computer, smartphone, or other connected device. The term “streaming” refers to the actual process of transmitting the video, with the server in a constant state of delivering the content similar to a steadily flowing current in a river.”
To elaborate on this definition, a CDN video streaming server is a server that you use as an ingest point and then push the stream to the CDN for delivery at scale.
By caching information, CDNs are a great way to deliver static content. The idea is that a request from a subscriber connects them to the closest data center which has a cache of the video they would like to watch. However, this is not the best system for the delivery of live streams.
The fact that CDNs were developed around pre-existing architecture structures, means that many platforms have come to depend upon them for live stream delivery to a large audience. However, as CDNs are built around HTTP delivery, they are not well suited for live low latency stream delivery.
Despite this, CDNs have a long established history in the roots of the intrinsic architecture of the internet which has created a dependency on using them to scale. The following list of streaming platforms (except for one) use a server as an ingest point and then push the stream onto a CDN network to handle scale. As CDNs will only use HTTP based streaming protocols, they cannot support sub-second latency.
We emphasize sub-second latency as it is a major requirement in creating a truly live stream. Thus we have listed here only video streaming servers that can support sub-second latency through WebRTC or other means. Of course, most of these rely on pushing the streams to traditional CDNs which deliver over HTTP protocols and thus introduce high latency at scale.
CDN video streaming server solutions fall into two categories: open source and paid.
Kurento is a widely-known open-source streaming server that uses WebRTC to deliver video streams. As an open-source platform it works well and will be cheap, but you have to know how to use it. Everything will need to be configured and, like any other open-source platform, it may not have everything working as is needed right out of the box.
It is possible to take a stream from Kurento and reformat it into a stream (typically RTMP) that can be delivered via a CDN, but currently there isn’t a way out of the box to scale Kurento with sub 500 ms latency.
Jitsi is a WebRTC media server, with a whole platform built around it. It includes everything to set up a basic communication platform. It also implements its own signaling using Jingle (XMPP) and a fully featured web interface. It’s a good solution for building smaller-scale video conferencing, but it does have many limitations when trying to scale it in a one to many scenario. Unfortunately, another big pain point is recording the streams as there isn’t a solid, easy to use solution.
With some work, you can get a stream out of Jitsi and forward it to a CDN, but as stated earlier the high latency associated with HTTP based streams makes it problematic. While we can’t reveal which company has done this, we do know of one who’s written their own clustering solution based on Jitsi that’s handling millions of streams in near real-time. If you’ve got the team, the time, and the experience to do this we know it’s possible.
While their website does not describe them as a “media server”, Janus can be set up as an SFU or Selective Forwarding Unit fairly easily. An SFU receives multiple data streams then decides which ones should be sent to which participants. Essentially it is a relay server ingesting streams and distributing them. In other words, an SFU is another fancy term for a video streaming server.
One of its most notable features is Janus’ plugin architecture, which can augment the service’s core capabilities. Their demo page displays a few interesting use cases of Janus such as SIP Gateway, screen sharing, and others.
Again, it is possible to get a stream out of Janus and pushed to a CDN, but the latency on the CDN side will be an issue.
Despite the fact that WebRTC supports ultra-low latency, it doesn’t matter if it can’t be experienced. As shown here, Janus along with other open source WebRTC based video streaming servers have not been designed to scale for a one to many use case without resorting to high latency.
As they always say, “you get what you pay for.” So let’s take a look at paid options. Can their solutions achieve scale and sub 500 ms?
A long-established player in the streaming video sector, Wowza has had too much time to sink into pre-existing, HTTP based CDN infrastructure. In fact, a big part of Wowza’s business is acting as the ingest point for CDNs. Wowza claims that 1/3 of CDNs have Wowza Streaming Engine software built into their ecosystem. In that use case, the Wowza Streaming Engine handles the RTMP ingest stream and then hands it off to the CDN’s HTTP servers for delivery.
Since a large portion of Wowza’s business is revenue from the CDNs themselves, it’s no wonder that Wowza claims that CDNs are absolutely critical to live video streaming. Coincidentally, they don’t tell you that adding a CDN to distribute your live streams means that you are going to introduce a high amount of latency.
Wowza attempts to get around this problem by using Apple’s Low Latency HLS or chunked based streaming solutions that utilize HTTP, but the lowest these solutions can get the latency to, is around 2 seconds which is too high for any sort of interactive experience.
However, Wowza does support WebRTC in some scenarios, allowing for sub 500 ms streams. Despite this, so far we’ve not yet seen a solution from them that can scale WebRTC into hundreds (much less millions) of concurrent streams. As such, Wowza’s reliance on CDNs to scale live video puts them in a category of relatively high latency video streaming.
5) Mist Server
According to their website, “MistServer is a full-featured, next-generation streaming media toolkit for OTT (internet streaming), designed to be ideal for developers and system integrators.” We don’t know a lot about their solution, but we’ve heard of smaller scaled successful deployments on Mist as well as some companies using the Mist server as an ingest point to then relay out to CDNs for a more scalable solution. Yet again, using a traditional CDN for distribution will cause large amounts of latency in the live stream.
Another full-featured platform, Nanocosmos features mobile SDKs and an HTML5 player. Their pricing is based on usage so it may get expensive as it scales out. Nanocosmos uses a WebSocket + MSE based approach to achieve around 1 second of latency. While Wowza recently dropped support for their WebSocket+MSE based ultra-low latency solution and are now rallying around Apple’s LLHLS standard, it seems that Nanocosmos is still using a similar approach. We’ve covered MSE + WebSockets and its limitations in our review of ultra low latency protocols in the past.
From our conversations with Nanocosmos, they aren’t trying to solve the huge scale problem with live streams, and thus haven’t provided a live streaming solution that scales to millions of concurrent viewers in under 1 second of latency.
7) ANT Media
Forked off of Red5 open source code, ANT Media provides a basic streaming service. While their WebRTC solution provides sub 500 milliseconds of latency, In order to scale, their site recommends plugging into a CDN. So while you may get good enough performance for a small number of streams, there is no way to get a fully performant live broadcast out to a good number of subscribers with sub 500 ms latency.
It should be noted, however, that Ant Media has also copied much of Red5 Pro’s clustering solution, so they may have other ways to scale using cloud server infrastructure. From what we’ve heard though, the solution suffers from many critical bugs and has difficulty with stability.
8) Red5 Pro
Rather than working within the confines of the traditional CDN, Red5 Pro works by leveraging cloud infrastructure to dynamically meet scaling needs. By setting up server clusters in the cloud, it avoids the massive infrastructure costs associated with traditional CDNs. Furthermore, cloud providers eliminate the problem of running more servers than needed which can be a problem with fixed data centers employed by CDNs.
By integrating with WebRTC, Red5 Pro provides sub-500 milliseconds of latency to millions of concurrent users. As the latency is so low, the distance between the broadcast origin and subscribing edge servers is much less important. In fact, you can watch a demo with a round trip latency between Paris and New York City of just 180 milliseconds. Of course, don’t just take our word for it, try it out for yourself.
Furthermore, Red5 Pro has developed a Cross-Cloud Distribution System which works across a variety of cloud platforms. This increases the flexibility to deliver live streams by exploiting the different performance and pricing offered by each platform. It will even work in private networks as well. The Cross-Cloud solution allows for a high availability network of server clusters with custom authentication rules to securely and quickly deliver live streams.