Why WebRTC Live Streaming Needs Media Servers

SHARE

As one of the top WebRTC experts in the world, we listen closely to what Tsahi Levent-Levi has to say on his site BlogGeek.me. Tsahi always posts informative articles, and he’s even penned (keyboarded?) [one for us](/blog//guest-post-tashi-levent-levi-webrtc-scaling-challenges/). However, we would like to add a point of clarification to one of his recent posts on requiring… Continue reading Why WebRTC Live Streaming Needs Media Servers


As one of the top WebRTC experts in the world, we listen closely to what Tsahi Levent-Levi has to say on his site BlogGeek.me. Tsahi always posts informative articles, and he’s even penned (keyboarded?) [one for us](/blog//guest-post-tashi-levent-levi-webrtc-scaling-challenges/).

However, we would like to add a point of clarification to one of his recent posts on requiring a media server for a one-to-many WebRTC broadcast. We certainly agree that you need some kind of server solution. In fact, we agree so much that we would like to add that you should use multiple media servers in clusters.

The fact remains, if you are looking to support any type of scale, you will need multiple media servers deployed in some kind of cluster architecture.

That’s the only way to deal with any sort of scale as there is too much processing going on to do that completely in the browser. A cluster is essentially a group of origin and edge servers that allow for more broadcasters and subscribers respectively, as illustrated by this diagram:

cluster

Since open source media servers like Kurento or Jitsi were built for video chat scenarios, and not for broadcast, they tend to only support small number of connections (a little over a 100 or so). Any use case beyond that and you will need to configure a cluster for your application. The issue is that none of the open source media servers have, as far as we know, built in clustering support.

Also, it is worth noting there is an additional reason to use a media server: transcoding. If your users are on low bandwidth or high packet loss networks, you might want to split the stream into different quality streams which allows the subscriber to automatically adjust by using the best stream for the smoothest viewing experience. This can be done by transcoding into multiple streams using a media server. Our upcoming Red5 Pro release will support this transcoding scenario.

While we agree with Tsahi on almost every point of his post, there is one thing that we completely disagreed with::

If you are broadcasting, then a media server is mandatory. And no. Google doesn’t offer such a free service or even open source code that is geared towards that use case.

It doesn’t mean it is impossible – just that you’ll need to work harder to get there.

While live-streaming is hard, you don’t need to work harder. All you need to do is go to Red5 Pro and sign up for a free 30-day trial. We’ve done most of the work for you by creating a straightforward way to scale your application through multiple clusters, all in real-time latency.

So don’t worry about it. Send an email to info@red5.net or give us a call and we can get you streaming in no time.