Disable simulcast based on # of users

Hey community,
Does anyone know if there’s a way to disable simulcast based on number of users.
In a scenario where we have up to 10 participants I don’t think Simulcast is needed cause we’re looking at a downstream of roughly 25Mbps.
It will however take a load off the upload bandwidth (which is usually limited) and the CPU by sending out 1 stream of 2.5Mbps.

So the main challenge we’re looking to solve is:

  1. Disable Simulcast and enable it when reaching a number of users
  2. Force the streams of all the participants the be 720p when Simulcast is unavailable

Any idea//helps will be appreciated.


@damencho ?

Downstream of 25 and upload of 250 without simulcast, this?

That was quick - thanks.
Not quite 250 upload when using Octo and several bridges. Each bridge has 1Gig line at least and the cost of higher speed is not that much in $$.

The users’ bandwidth will be the first to go before my servers will, so not worried about that at all.

So can we have simulcast off and have it turned back on after certain amount of users?

  • How can I force minimum stream quality to be at least 360p. 180p just don’t cut it for me.

Thanks D

There is no such option at the moment. But octo is not in the equation at the end the sum of uploads of the different bridges will be 250 and there will be even more traffic between the bridges … So what I’m trying to say switching it off is not a good idea. You will make all clients to have 20 download and not all clients have good internet …

Wait my equation is wrong

O yeah 102.5 =25 download on the server and upload sum is 109*2.5=225 yeah its the same, its near 250 :slight_smile: So every client will have download of 22.5 and upload of 2.5.

Fantastic. Where we’re located that bandwidth is not an issue. All connections go from 40Mbps downstream and up. Between the servers the traffic will be as high cause the remote bridge is considered 1 endpoint.

I think you guys need to consider - it’ll make smaller meeting better experience and you can make it definable so if you are in a place where bandwidth is not abounded you can reduce the limit number.

What for my other question?
Can we set the minimum stream to 360p or dare I say higher :smiling_imp:?

Yep, that is possible

Right on… let’s get to the how?? we’ve been struggling :slight_smile:

Appreciate you help

Adjust all these:

I wish it was that easy. We set our config file to 480p minimum resolution but simulcast is still sending minimum of 180p at some occasions. It doesn’t change the 180p stream processing.

Other ideas?

A you want to change the minimum, yeah I’m not sure about that … What if you change it to 360p does it work?
We need to ask @jallamsetty for some help :slight_smile:

The constraints affect the higher resolution from the camera not the lowest resolution from simulcast. So if the camera is giving 720 simulcast will use it to encode 180 but if the the camera will give 360 the most (for this example) then simulcast cannot produce 720 stream.

I think the constraints should always be 720 or the highest the camera can give. It’s lowest stream sent we want to change not the highest.

I see you guys have a bandwidth saving approach there…

Would love some input on this :pray:t2:

So most of the time people are using these to limit the resolution to save bandwidth.

I think it’s better to cater to everyone and give the option to those who rather quality and the over the top experience rather than bandwidth.

Jitsi is AWESOME just not at 180p :wink:

Hi @rn1984, I don’t quite understand the problem statement. Why do you think Simulcast is not useful when you have less than 10 participants?
The upstream and downstream bandwidths are not 2.5 Mbps and 25 Mbps respectively. It depends on how the conference is being viewed by the participants.
If everyone is viewing in the tile view (default mode for 3+ users calls), the downstream b/w is going to be (200 Kbps * 9 = 1.8 Mbps) and the uplink is going to be only 200 Kbps.
If everyone is viewing the conference in stage view, the downstream b/w is going to be 2.5 Mbps + 8 * 200 Kbps = 4.1 Mbps and the upload can be at the most 2.5 Mbps for the active speaker while all others would be sending only 200 Kbps.

Please note that when simulcast is enabled, the client is sending only the streams that are needed based on how this participant is being viewed by other participants in the call. Disabling simulcast would force the client and bridge to send only 720p streams which would make the upload 2.5 Mbps and download 22.5 Mbps making the experience terrible for users who do not have that much downlink since there is no way for the bridge to do any remediation for the low downlink users.

In the simulcast case, you can further control these bitrates using this setting - https://github.com/jitsi/jitsi-meet/blob/master/config.js#L259

1 Like

Hi @jallamsetty
Love the detailed answer and thank you so much for taking the time to explain it in such depth.

I’m all for low b/w but here’s what we found in our use case. We present different users to in different views to different participants. According to our observation and documentation online all users are sending 3 streams at all times. We see outgoing b/w of 3.2Mbps which from what I gathered is 3 stream 180p 360p and 720p.

We also notice a processing drain. All devices are getting over heated, computer fans run fast which sometimes actually feedback noise into the call. We changed the views as we need them and we’re getting 180p on main screen tile view which counts for a not great experience.
My idea of ideal is if we can lower the processing load and while keeping quality at the highest possible.

As for b/w, I don’t know of a lot of places with less than 40Mbps the very least. So I don’t mind capturing 25mbps downstream of those 40Mbps b/w and then reduce quality (since tiles become smaller on screen due to # of users). That means the quality of up to 10 participants will be phenomenal, processor will have less strain cause most cameras provide 720p streams anyway - which means the processor just need to do a passthrough encoding and computers won’t get so heated. The quality will be way better than what’s out there (even zoom with their processed composites).

I’m all for simulcast and reserve b/w if:

  1. Get a great video quality first and foremost
  2. CPU stays cool :sunglasses:

Would love your thoughts on this and thank you once again