One-to-many translation: do you need a media server?

TL; DR - YES.

The next article of our Israeli colleague on WebRTC and calls between browsers is translated for Habr. At Voximplant, we are developing our own solution for organizing video conferencing through the server and we can say that yes, that’s all. Peer-to-Peer is a good thing, but it does not work in all cases. And to make a good video conference via the server is not so easy when a lot of different web browsers and mobile devices are connected to the server, each with its own connection to the Internet and its implementation of the video stack. After some time, we’ll tell you about the insides of our solution, and now the word is passed to Tzachi Levent-Levy, the creator of bloggeek.me , widely popular in narrow circles

One-to-many translation: do you need a media server?

This is the question I received in the support chat this week. The answer was simple - yes.
But then I received a question that I did not expect:

What for?
')
It took me by surprise. Not because I do not know the answer, but because I do not know how to respond briefly enough to fit in the chat. I also think that this is not a very simple question.

The short answer is the resource limit plus the fact that we do not control most of these resources.

Upper limit

Whenever we want to connect two browsers directly, we must use a peer-to-peer connection.

Chrome 65 has an upper limit for such connections, which is used by the garbage collector. Chrome will not allow to create more than 500 parallel p2p connections.


500 is a lot. If you are counting on more than 10 parallel connections, then you must be one of those people who know what he is doing (and you do not need my blog). Creating more than 50 connections is a bad idea for any use case I can remember.

Understand that resources are limited. If something is free and embedded in the browser, it does not mean that it will not be associated with some costs and serious efforts on your part.

Bitrate, Speed, and Streams

Probably this is the main reason why you cannot broadcast (hereinafter “Broadcast”. Note of the translator) on WebRTC or on another technology.

We focus on a tricky case using WebRTC. Processing media is hard. Real-time processing is even harder.

Suppose we want broadcast with a low VGA resolution . We checked that the 500 Kb / s bit rate gives a good result for this.

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


Broadcasting our stream to 10 people will require an outgoing bit rate of 5 Mb / s.

If we have an ADSL connection, then we have an outgoing bitrate in the region of 1-3 Mb / s, so we will not be able to broadcast the stream to 10 people.

For the most part, we cannot control how the broadcast will take place. Through ADSL? Wi-Fi? 3G network with poor connectivity? As soon as we contact broadkastom, we are obliged to make such assumptions.

And this is only for 10 viewers. And what if we need 100 viewers? Thousand? Million?

In the case of a media server, we already define the connection to the network, which hardware to use for the server, etc. We can cascade media servers to scale our broadcasts. We have much more control over the situation.

A media server is required to translate a WebRTC stream.

Uniformity

The actual question is for group calls, however it is most relevant for broadcasters.

When we use WebRTC for Broadcast, a lot of solutions fall on the media server. For example, if one viewer has a bad connection, it will lead to packet loss and the media server will know about it. What should he do in this case?


Although there is no simple answer, there is a choice what to do:

• ask Broadcaster to send a new I-frame, which will affect all viewers and increase bandwidth usage in the near future (the media server would not want to);
• ask Broadcaster to lower the bitrate and video quality in order to level packet loss - this will affect all viewers, and not just the one with a bad connection;
• ignore packet loss, i.e. “Sacrifice” one spectator for “the common good” (the rest of the audience);
• use simulcast or svc and put the viewer on a “lower level” with lower quality. It will not affect other viewers.

Most of this cannot be done in the browser. For the problem user, the browser will try to use the same stream as the rest of the viewers; Also, the browser will not be able to well assess the bandwidth for a large number of viewers. Just because the browser is not designed for this.

You need a media server

In most cases, you will need a media server for one reason or another.

If you are doing Broadcast, then the media server is required. And yes, Google will not find you such a free service or at least an open source solution aimed at broadcasting.

All this does not mean “impossible” - this is only a sign that you will have to work hard to achieve the goal.