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.
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.
dpkg -l “jitsi-*”
Desired=Unknown/Install/Remove/Purge/Hold
| 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*”
Desired=Unknown/Install/Remove/Purge/Hold
| 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 ?
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
quality”
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.
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
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
@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.
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://meet.jit.si/xmpp-websocket', // FIXME: use xep-0156 for that
websocketKeepAliveUrl: 'https://meet.jit.si/_unlock',
openBridgeChannel: 'websocket', // One of true, 'datachannel', or 'websocket'
