How to change the Simulcast bitrate?

I deployed Jitsi on IaaS with a guaranteed bandwidth of 300Mbps.

I need to turn on simulcast because of bandwidth issues that users use. However, I am suffering from the phenomenon that the image quality of all users deteriorates when Simulcast is turned on.

*This issue also occurs when using Firefox, Chrome, and Android applications.

I don’t know the cause, but the screen sharing resolution is good.

Is there a way to set the lower limit bitrate for simulcast?
Thanx in advance for any answer or logical input.

1 Like

as far as I know there is a way to set max bitrates for every simulcast layers. If the client bandwidth is available, the client should be sending the highest possible bitrates for every layer (unless you cap the layer max bitrates).
Did you inspect the clients available bandwidth and current sending/recieving bitrates while in a conference? also check the default resolution you set as it always tries to acquire that resolution, it’s 1/2 and 1/4 resolution for simulcast layer where 180p is the lowest i believe.

1 Like

I have noticed that too, the quality deteriorates so much that I have set:

    disableSimulcast: true,
    enableLayerSuspension: true,

Is there a way to solve this issue? (other than disabling Simulcast)

@GeorgeJitsi what version of Jitsi are you running?

dpkg -l “jitsi-*”
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
ii jitsi-meet 2.0.5390-3 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.4628-1 all Prosody configuration for Jitsi Meet
un jitsi-meet-tokens (no description available)
un jitsi-meet-turnserver (no description available)
ii jitsi-meet-web 1.0.4628-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.4628-1 all Configuration for web serving of Jitsi Meet
un jitsi-videobridge (no description available)
ii jitsi-videobridge2 2.1-416-g2f43d1b4-1 all WebRTC compatible Selective Forwarding Unit (SFU)

dpkg -l “prosody*”
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
ii prosody 0.11.2-1 amd64 Lightweight Jabber/XMPP server
un prosody-0.11 (no description available)
un prosody-modules (no description available)
un prosody-trunk (no description available)


“Simulcast lets us send multiple video streams with varying bandwidths/quality at once.

Each of these uploaded streams consumes bandwidth and CPU and when there isn’t enough of either they also compete with each other for resources which can reduce quality.”

Does this mean that when Simulcast is enabled, every participant is sending, for example, three streams of video, one HD, one SD and one LD to the Jitsi server ?

I am using 2.0.5390 (21-01-12).

I used to use 4627 (2020-05-26), but the same phenomenon occurred.

After further testing, with Simulcast enabled on the server, the meeting i snow stuck in LD. Without Simulcast, the meeting could be LD, SD, and HD depending on setting “Manage call

yes if you don’t have “enableLayerSuspension : true”.
simulcast tries to send 3 stream always with various resolution so that the client/receiver get’s the advantage of saving bandwidth - if he(receiver) needs someone in focus he can use the highest resolution of his, if he needs some one in grid view he can just use the medium/low resolution of his (as 3 stream is available in videobridge now, if you dont enable simulcast there will be only one stream available). but it costs wastage of bandwidth and cpu usage both in sending client side and video bridge. So here, comes the - enable layer suspension, if you have this enabled sending client always gets to know which of his sending stream is getting viewed by the present other participants in that conference. So, if videobridge detects that everyone is seeing participant “A” in grid view it sends a message to “A” that only send this stream (medium and low resolution) and only if it detects that someone is viewing “A” in focus then he sends message to “A” so “A” now start sending “High resolution” stream as well as medium and low resolution stream to video bridge and video bridge serve the videos to the needed ones. Suspension layer disabled/suspend high resolution streams that are not being viewed at the current time but send the lower streams if possible.

Yes I do have “enableLayerSuspension" set to true.

enable layer suspension and don’t forget to set

openBridgeChannel : ‘datachannel’ / ‘websocket’ (if you use websocket you have to configure it, video bridge use this channel to communicate with clients)
enableTcc : true (enabling sending side congession sontrols)
enableRemb : true (enabling receiving side congesion controls)

I think this should work just as fine. you also can check the config.videoQuality.maxBitratesVideo to set max bitrates for individual layer and config.videoQuality.minHeightForQualityLvl to set when you wanna get HD/SD/LD of the receiving stream

Please tell me in which files these parameters are…
I would take me a long time to find them.

in config.js

openBridgeChannel : ‘datachannel’ / ‘websocket’,(to use websocket you have to configure it)
enableTcc : true, (enabling sending side congession sontrols)
enableRemb : true, (enabling receiving side congesion controls.
enableLayerSuspension : true,
disableSimulcast : false

**edit : also check if these values are already set or not or double setting the values, after changing any configs you need to do hard refresh (ctrl+r) on clients to get the configs as the client downloaded the config file at the beginning of the session or use the previously downloaded configs

checking jitsi-meet’s *-config.js file, I want not able to find a “openBridgeChannel” option.

There was a setting:

    // Websocket URL
    // websocket: 'wss://',

But when I enabled this option, no video streams were working, just like we had selected Low bandwidth.

I have tried setting the options that my config.js has, and this causes the Jitsi server to all work in LD only. Despite what users might select.

As I said, you need to worry in that later to configure websocket.
For now first try :

openBridgeChannel: ‘datachannel’

you can check this in official (official)
or your config.js at https://your_url/config.js

and again you need to do hard refresh on client side after making a change in config everytime

@GeorgeJitsi and @Y_S if you’re running version 5390-3 (latest stable), websocket is enabled by default. You don’t need to set anything in config.js. You also shouldn’t be having this resolution issues with this version, unless you made some changes to the default installation/configuration.

The out-of-the-box installation gives you 720p resolution in stage view and 360p resolution in tile view (if your tiles meet the height requirement). If you’re seeing unexpectedly low resolutions, check to make sure you’re actually making websocket connections. Again, this should happen automatically if you installed the latest version using the Quick Install Guide, but check just in case. Start a meeting with 3 people and check to see if you have any errors in your js console.

Thanks Freddie. How would I do this check?

FYI: It was a 5390-3 (latest stable) standard build, but I had to disable Simulcast to get HD working, otherwise any meeting was stuck in LD.

None of these settings exist in my config.js file (as you say, they don’t need to be:

    websocket: 'wss://', // FIXME: use xep-0156 for that
    websocketKeepAliveUrl: '',

    openBridgeChannel: 'websocket', // One of true, 'datachannel', or 'websocket'

On Chrome, click on View_Developer_Javascript Console.

Screen Shot 2021-03-04 at 12.28.13 AM

Logger.js:154 2021-03-03T18:44:37.853Z [modules/xmpp/XmppConnection.js] <u._maybeEnableStreamResume>:  Stream resume enabled, but WebSockets are not enabled

Logger.js:154 2021-03-03T18:44:38.422Z [modules/RTC/TraceablePeerConnection.js] <A.addTrack>:  add LocalTrack[2,video] to: TPC[1,p2p:false]
index.js:159 Imploding SIM group: 1939946512 2773055047 1513717972
index.js:159 Imploding SIM group: 916812246 1852672965 2145857522
BridgeChannel.js:86 WebSocket connection to 'wss://[internal ip]/42c53da55c8cfaa/c8e20294?pwd=30ims01h2dnjrlr96vel1oer6v' failed: 
_initWebSocket @ BridgeChannel.js:86
l @ BridgeChannel.js:75
initializeBridgeChannel @ RTC.js:285
ie._setBridgeChannel @ JitsiConference.js:2023
ie._acceptJvbIncomingCall @ JitsiConference.js:1953
ie.onIncomingCall @ JitsiConference.js:1901
a.emit @ events.js:152
onJingle @ strophe.jingle.js:171
run @ strophe.umd.js:1875
(anonymous) @ strophe.umd.js:3157
forEachChild @ strophe.umd.js:830
_dataRecv @ strophe.umd.js:3146
_onRequestStateChange @ strophe.umd.js:5012
Logger.js:154 2021-03-03T18:44:38.532Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onclose>:  Channel closed by server
Logger.js:154 2021-03-03T18:44:38.533Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onclose>:  Channel closed: 1006 
o @ Logger.js:154
e.onclose @ BridgeChannel.js:359

Just a guess, but my server’s websockets are not working…