Do I Need a Media Server for a One-to-Many WebRTC Broadcast?

20/02/2018

TL;DR – YES.

Do I need a media server for a one-to-many WebRTC broadcast?

That’s the question I was asked on my chat widget this week. The answer was simple enough – yes.

Decided you need a media server? Here are a few questions to ask yourself when selecting an open source media server alternative.

Then I received a follow up question that I didn’t expect:

Why?

That caught me off-guard. Not because I don’t know the answer. Because I didn’t know how to explain it in a single sentence that fits nicely in the chat widget. I guess it isn’t such a simple question either.

The simple answer is a limit in resources, along with the fact that we don’t control most of these resources.

The Hard Upper Limit

Whenever we want to connect one browser to another with a direct stream, we need to create and use a peer connection.

Chrome 65 includes an upper limit to that which is used for garbage collection purposes. Chrome is not going to allow more than 500 concurrent peer connections to exist.

500 is a really large number. If you plan on more than 10 concurrent peer connections, you should be one of those who know what they are doing (and don’t need this blog). Going above 50 seems like a bad idea for all use cases that I can remember taking part of.

Understand that resources are limited. Free and implemented in the browser doesn’t mean that there aren’t any costs associated with it or a need for you to implement stuff and sweat while doing so.

Bitrates, Speeds and Feeds

This is probably the main reason why you can’t broadcast with WebRTC, or with any other technology.

We are looking at a challenging domain with WebRTC. Media processing is hard. Real time media processing is harder.

Assume we want to broadcast a video at a low VGA resolution. We checked and decided that 500kbps of bitrate offers good results for our needs.

What happens if we want to broadcast our stream to 10 people?

 

Broadcasting our stream to 10 people requires bitrate of 5mbps uplink.

If we’re on an ADSL connection, then we can find ourselves with 1-3mbps uplink only, so we won’t be able to broadcast the stream to our 10 viewers.

For the most part, we don’t control where our broadcasters are going to be. Over ADSL? WiFi? 3G network with poor connectivity? The moment we start dealing with broadcast we will need to make such assumptions.

That’s for 10 viewers. What if we’re looking for 100 viewers? A 1,000? A million?

With a media server, we decide the network connectivity, the machine type of the server, etc. We can decide to cascade media servers to grow our scale of the broadcast. We have more control over the situation.

Broadcasting a WebRTC stream requires a media server.

Sender Uniformity

I see this one a lot in the context of a mesh group call, but it is just as relevant towards broadcast.

When we use WebRTC for a broadcast type of a service, a lot of decisions end up taking place in the media server. If a viewer has a bad network, this will result with packet loss being reported to the media server. What should the media server do in such a case?

While there’s no simple answer to this question, the alternatives here include:

  • Asking the broadcaster to send a new I-frame, which will affect all viewers and increase bandwidth use for the near future (you don’t want to do it too much as a media server)
  • Asking the broadcaster to reduce bitrate and media quality to accomodate for the packet losses, affecting all viewers and not only the one on the bad network
  • Ignoring the issue of packet loss, sacrificing the user for the “greater good” of the other viewers
  • Using Simulcast or SVC, and move the viewer to a lower “layer” with lower media quality, without affecting other users

You can’t do most of these in a browser. The browser will tend to use the same single encoded stream as is to send to all others, and it won’t do a good job at estimating bandwidth properly in front of multiple users. It is just not designed or implemented to do that.

You Need a Media Server

In most scenarios, you will need a media server in your implementation at some point.

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.

Looking to learn more about WebRTC? In the coming weeks, I’ll be refreshing my online WebRTC training. Join now so you don’t miss out.

 

Responses

Kranthi says:
February 20, 2018

Great Article Tsashi and right when I was looking for answer.

I came across Kurento Media Server. What do you think of this for a 1 to many broadcast?

Reply
    Tsahi Levent-Levi says:
    February 20, 2018

    Kranthi,

    I wouldn’t use Kurento at all. It hasn’t been seriously updated in the past year or so which makes it risky to use.

    Look at Jitsi and Janus for alternatives.

    Reply
    Sibghatullah Sheikh says:
    February 23, 2018

    Kurento iOS support is finished. Lots of Bugs in the Code. The Serverside is so glitchy. After being sold to twilio, they have stopped maintaining it.

    Reply
    Wen Chang says:
    December 8, 2018

    Hello!
    I am web developer
    My name is Wen Chang.
    Excuse me , can i ask you?
    I want to make web apps (contains video , audio , message chatting : one to many)
    can i make this app using kurento-server?

    Reply
Sreelekshmi says:
February 22, 2018

Tsahi,
We are using licode as our media server. What will be your comments on licode for this scenario?

Reply
Bharath says:
February 23, 2018

Hi All,

I’m getting an issue when I tried to make more than 16 concurrent calls. Can anyone tell me a proper way to investigate this issue?

Error Message by sip.js 0.7.8
DOMException: Could not start source

sip.invitecontext.mediahandler | unable to acquire streams

Reply
sriman says:
March 1, 2018

Hi Sahi,

Our use case is One broadcaster -> many Viewers might be 100k users.

will jitsi meets our need, whether its scalable.

We hosted and checked jitsi meet, but it seems like Google Hangout with Many peers with 2 way communication, do we have library like kurento i.e one broadcast many viewers

Reply
    Emil Ivov says:
    March 1, 2018

    Support for super large conferences is on the way with Jitsi Videobridge but if you are looking for 100K users then maybe you want to use it in a combination with an HLS server. The Jitsi project that does this is Jibri: https://github.com/jitsi/jibri

    Reply
      sriman says:
      March 2, 2018

      Thanks for you reply, can we achieve low latency ~1s also using jibri(with hls)?

      Also is there any methodology available in the jitsi for scaling up and down depending on outbound stream and ports availability in AWS cloud.

      Thinking clustering will work, is there any documentation in jitsi for the scaling with clusters.

      Reply
Ziv says:
March 11, 2018

Hello Tzahi,
First of all great article!
I was wondering what are your thoughts on Hybrid solutions?, i.e. mixing webrtc with rtmp or hls, to have maximum compatibility with different browsers/os.

What should guide me when I’m building such a solution, how should I choose the media server technology (rtmp\webrtc\hls), what is the best encoding direction webrtc-> rtmp\hls or vice versa?

Thanks a lot

Reply
    Tsahi Levent-Levi says:
    March 11, 2018

    Ziv,

    That’s a lot more than a single question with no clear answer, so can’t really comment much about it here.

    It will greatly depend on what your service is doing and what your requirements are. These will dictate the broadcaster’s and the viewer’s protocols.

    Hybrid models are possible and achievable bu they are more complex to develop, deploy and maintain, so I usually try to refrain from them if possible.

    Reply
Andrew says:
April 21, 2018

Thank you for the article.
I’m building (as a prototype) an ultra low latency video streaming channel where I need to broadcast RTP stream from a few (5..10) cameras to say hundreds or thousands clients in web browsers who can choose which camera of those to see (or maybe a few of them together).
As a mediaserver I made it working with Kurento, but not happy with it’s complexity n effort to configure etc. I’m also looking @Janus and Jitsi – but maybe you could point me to another direction? Say, Streamedian or a like?
Appreciate your guidance.

Reply
Tuan Nguyen says:
May 23, 2018

Hi Tsahi,
I have read your post, and it seems like you are talking about problems with Mesh topology. When we use SFU, new client only setup one PeerConnection to server. If we have a new viewer, there is only a new media stream from server to client, not from client to server. So the only problem maybe is the the server bandwidth right? Or am I missing something ?
Thanks.

Reply
    Tsahi Levent-Levi says:
    May 23, 2018

    Tuan,

    This one focuses on mesh topologies. When it comes to routed SFUs you will not have the performance issues on the browser side, but rather the varying bitrates available by each viewer as well as total bandwidth available on the server end.

    Reply
      Tuan Nguyen says:
      May 23, 2018

      Thanks you for your clarification. By the way, I really love your posts about WebRTC. So keep up your good work :))

      Reply
Daniel Lucumi says:
May 31, 2018

Hello, I am thinking to build an application like periscope using react native, what media server do you recommend me?

Reply
Richard Seth says:
July 11, 2018

For live broadcasting like HQ Trivia, would you recommend WebRTC over other protocols? What are some pros and cons?

Reply
    Tsahi Levent-Levi says:
    July 17, 2018

    That would depend a lot on your requirements Richard.

    HQ Trivia is a kind of a template that gets used today in other domains to try and copy its success. The copy process usually involved minor tweaks to differentiate the new service. These tweaks may require the use of WebRTC.

    Reply
Dr Alex says:
August 19, 2018

– Janus has a special solution for streaming called SOLEIL. It’s based on Lorenzo’s PhD (http://www.fedoa.unina.it/10403/1/miniero_lorenzo_27.pdf) and they published some more details about it in july under “SOLEIL: Streaming Of Large-scale Events over Internet cLouds” at IEEE. It’s not open source yet, but i’m sure one can contact them about it.

– Without multiple media servers in cluster / cascade / tree / …, you won’t reach much more than 1,000 viewers.

– Beyond the upload bandwidth limitations for the publisher, the main problem to crack is handling network variations (both quantity: bandwidth, and quality: jitter, packet loss) between viewers, a.k.a. the noisy neighbour problem, when you have multiple hops between publisher and viewer. It’s a known limitation of RTP / RTCP (see V. Novotny and D. Komosny, “Large-scale rtcp feedback optimization,” Journal of Networks, Vol. 3, No. 3, March 2008), that has been solved by some (vidyo), but never in an open source implementation.

– Medooze.com is another open source WebRTC media server (toolkit), that has been used to solve this problem. It is currently used by Spanchain (spank.live) for live adult entertainment where latency is crucial for user experience (ever tried to make love with 5 seconds delay?). It has been tested up to 1 million viewers thanks to Google webrtc testing tool KITE. It is at the core of Xirsys’s operated millicast.com, a webrtc-based streaming platform.

– Tsahi does a very good job, as usual, at giving the big picture. For those interested in more in-depth technical details, which compare rtmp, flash and webrtc, we wrote two blog posts:
* http://webrtcbydralex.com/index.php/2018/05/15/streaming-protocols-and-ultra-low-latency-including-webrtc/
* http://webrtcbydralex.com/index.php/2018/06/08/using-webrtc-as-a-replacement-for-rtmp/

– There will be a session at Live Streaming Summit (Huntington Beach, CA, Nov. 13~14) dedicated to those questions: “VES203: WebRTC: The Future Champion of Low Latency Video”.

Reply
What Is WebRTC? | Wowza says:
November 27, 2018

[…] According to WebRTC expert Tsahi Levant-Levi, whenever you connect one browser to another with a direct stream, you have to create and utilize a peer connection. But there is a limit to the number of concurrent peer connections a browser will allow; on Chrome, the limit is 500 connections, but Levant-Levi recommends no more than 50. […]

Reply
Wowza’s marketing at work again. #webrtc. | WebRTC by Dr Alex says:
May 19, 2019

[…] getting them close to the CDN prices today. Their only citation (setting aside self-citations) is a blog post by Tsahi, a very knowledgeable webrtc consultant, but dating from early 2018, and complete obsolete […]

Reply

Comment