enableLayerSuspension: false doesn't work?

Install & Config
#1

Hello,
We have installed jitsi on ubuntu 20.04 and tested video conference with 3~5 partipants . Although we didn’t change any options in the xxx.xxx.xxx.xxx-config.js at beginning, it seems that disableSimulcast is false and enableLayerSuspension is true by default.

In our special network test, we would like to keep all partipants with almost same simulcast uplink data rate(e.g. 180p + 360p + 720p, about 3.5Mbps). Therefore we have tried to set the enableLayerSuspension: false and disableSimulcast: false in config.js, but we found that the partipants who are “Not selected” by other partipatns in the stage view only transmitted 180p(about 200kbps) video instead of 180p + 360p + 720p (about 3.5Mbps) video. Only the partipants who are “selected” by other partipatns transmitted 180p + 360p + 720p (about 3.5Mbps)

Would someone help figure out how to make the config enableLayerSuspension: false work? Thanks!

Below is the jitsi version we have installed.
—
dpkg -l | grep jitsi
ii jitsi-meet 2.0.7287-1 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.6155-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-turnserver 1.0.6155-1 all Configures coturn to be used with Jitsi Meet
ii jitsi-meet-web 1.0.6155-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.6155-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 2.1-681-g3544ed05-1 all WebRTC compatible Selective Forwarding Unit (SFU)
–

#2

enableLayerSuspension is no longer available, it defaults to true now. Why would you want senders to be sending resolutions nobody is receiving?

#3

Hi saghul,
Thanks for your reply. If we would like to disable Layer suspension, could we modify which code or install which version of jitsi meet? We would be appreciated for the help.

Since we are planing to test video conference on a novel wireless network, we have to first estimate bandwidth requirement per partipant in a video conference with 2~5 partipants and HD video.
Then we could simply estimated how many meeting rooms and clients required in each test scenario for evaluating the communication system under its peak rate.

For example on google meet website below, it indicates that a participant outbound signals of HD video must meet 3.2 mbps bandwidth requirement ,as well as inbound signals of HD video must meet 2.6 mbps with 2 participants and 3.2 mbps with 5 participants.
Once we have estimated bandwidth requirement and find out the configuration of video conference for generating date rate near the bandwidth requirement in normal situation, we could test it in normal network environment then in poor situation.

Google Meet hardware requirements - Google Meet hardware Help

We found someone has bandwidth rough estimation “Jitsi Video Server and End User Bandwidth Rough Estimation.doc” in previous discussion below, so we would like to find out the suitable configuration and measure the real data rate per partipant in general,
We think simulcast is preferred to enable in the test for saving bandwidth, and stage view is more suitable to estimate bandwidth requirement per partipant simular to google meet.

Bandwidth cost modeling - #17 by narcisgarcia

#4

I think maybe you’re not really getting how layer suspension works. In essence, what it does is that it signals to the client not to send certain layers when no one is viewing them.

Without layer suspension, each client sends 3 streams when simulcast is enabled. Of those 3 streams, only one of them will be viewed by the receiving client at any time. So, if a receiving client for instance, is only viewing SD (360p resolution) as is typical in tile view, then the HD and LD layers are not being requested and sending them is merely wasting resources. What layer suspension does then is to signal to the clients to stop sending those other layers (that are not being used) until they are requested. This helps tremendously as it ensures a remarkable level of efficiency in bandwidth, CPU and memory usage (think of the clients encoding streams at resolutions that are not being used and the bridge forwarding layers that serve no purpose).

So, bearing this in mind, there is no logical need to disable layer suspension. If you want to force all participants to send HD at all times in your test scenario, then you’d just need to disable simulcast (again, not recommended in production, unless all connecting clients are in a strictly controlled and guaranteed network). Forcing all clients to send all 3 layers, regardless of use, will not show anything other than that they can if there’s sufficient bandwidth.

#5

Hi Freddie,
Thank your for explaining about layer suspension. For effective use of network bandwidth and CPU resource to the participants in a video conference, we realized that simulcast and layer suspension are both required so that these two options are default to true. We also agree to disable layer suspension is no logical need.
To disable layer suspension just for our test purpose since uplink and download bandwidth usage/data rate per participant could be simply estimated to “the same one” in stage view (e.g. uplink about 3.5Mbps, downlink 3.4Mbps for all 5 participatns). Otherwise, the uplink data rate of participants who are viewed and not viewed are different in stage view.
We speculate that there might be another way to make the same bandwidth requirement for each participant. If we set maxFullResolutionParticipants: 5, disablesimulcast: false, and resolution: 720, the bandwidth requirement per participant in “tile view” would be about uplink 3.5Mbps and downlink 10Mbps(2.5 x 4) for all 5 participants with HD video, and downlink 5Mbps(2.5 x 2) for all 3 participants. Is this right? In addition, how could we make simulcast includes only the three resolution (HD:720p, SD:360p, LD:180p)?

#6

Currently, in Stage view, only the participant on stage is in HD, all others are in LD. The participant on Stage therefore only sends out LD (with layer suspension on), while all the other participants only receive HD.

In Tile view, you can specify how many participants should send HD by changing the maxFullResolutionParticipants value, but this will only be effective if you also change the minHeightForQualityLvl value so it factors in the tile size AND you have sufficient resources to actually support that. Even then, if the maxFullResolutionParticipants value you set equals the number of tiles you’re testing with and layer suspension is enabled, you will only get the HD layer bandwidth (~2.5Mbps). And if I recall correctly, this only worked as expected with VP8.

Again, for efficiency, there is no logical need to allow layer suspension to be disabled, so it makes sense that the option is no longer available. It’s unclear why exactly you’d want it on - even in a test situation. You can safely conclude the following (in Tile view) assuming resources are adequate:

With simulcast on, layer suspension on - all participants have roughly the same uplink and downlink, since they’re all sending and receiving just one layer

With simulcast on, layer suspension off - all participants will still only request one resolution, but they will continue to send 3 resolutions. So, in the default state, for instance, with let’s say 4 participants, each participant will be sending out ~3.3Mbps and receiving only ~600Kbps

Simulcast always includes three resolutions. Layer suspension just signals to the clients not to bother sending resolutions that are not being used until requested. So the two work dynamically to make the most efficient use of available resources. Note that layer suspension is a Jitsi ‘invention’ (to the best of my knowledge), so, bandwidth requirements in Google Meet are different.

#7

Thank Freddie for your kindly reminding. In default configuration, we have changed maxFullResolutionParticipants to 5 and adjusted minHeightForQualityLvl to {standard: 90 and high: 180} for fitting laptop screen, and simulcast and layer suspension are susposed to default to on.

In the conference with 5 participants, we checked the bitrate displayed on tile view for each participant is about uplink 3.3Mbps and downlink 10.1Mbps.The resolution on tile view for each participants except self view(disabled) is either 720p or 540p.

There is still some questions. Is uplink bitrate 3.3Mbps composed by simulcast with 180p(~200Kbps) + 360p(~0.5Mbps) + 720p(~2.5Mbps) and downlink bitrate 10.1Mbps composed by 4 participants of 720p (2.5Mbps x 4)? How many usually the voice bitrate is?
And we saw that there are about 2 participants with 540p on tile view, could we modify the config to let the resolution only be one of the three option(180p, 360p, 720p depend on network congestion)?