Jitsi automatically reduces Video Quality

Dear Community,

My problem is as far as i saw the opposite to most other quality related threads, but if i just didn’t find the solution in this forum i apalogize :slight_smile:

I experienced this behaviour before, but thought it could be a “server” related issue (it was an ex-Desktop-PC with an i5, 8 GB of RAM and a 100 Mbit up&down Line, but it worked … kind of :grin: ), so i rented a virtual server from Strato (Ubuntu 18.04, 8 vCores, 32 GB of RAM, 500 Mbit up&down) but it still did what it did before.
My problem is, that Jitsi automatically reduces the video quality during a conference even though there’s no reason for it. Both participants are connected via a 100 Mbit down and 40 Mbit up DSL-Line (LAN of course) and only one participant is sendung a video stream. After a few minutes the quality at the receiver side is reduced from “High Definition” to “Standard Definition”.
The -config.js file is configured to prefer 720p and define it as max. resolution.

If i forgot to provide any information or you need additional, please ask :smile:

Thanks in advance!
john2151

Another strange behaviour i’ve seen is that Jitsi doesn’t transfer more than 1280x720 pixels, even though the -config.js allows a resolution (height) between 240 and 1080 and also prefers 1080 (set as ideal). When this setting is applied the maximum resolution is under 720p (around 500) and as soon as i set the resolution settings back to max. 720 the full 1280x720 are transmitted …

P.S. The camera is capable of FullHD :wink:

Something similar happens to me when I use Chromium (and I guess Chrome) in linux. It doesn’t happen while using Firefox. I found that in Chromium quality is reduced if the other user has a lo resolution camera, but not if it has an HD or more res camera.

Thanks for the reaction @Pato_Gonzalez!
Actually this is interesting because this is not quite the behaviour i experienced. If i use Firefox Jitsi seems to be unable to determine the available bandwidth and reduces the quality to low on both sides. If i use Chrome(ium) the quality is at least for a few minutes at high, but also decreases after a while.

So let me reformulate my question: Is there a possibility to deactivate the adaptivity in videobridge and force it to a specific quality?

Note: you can bring back an old thread by adding a reply and saying that you still need help; the ‘install and config’ tag is fine for your problem. A convention is to just say:

bump

In your place the first thing I’d try is to actually enable the video in both directions. If there was a bug that could bring the bridge in deciding that the connection is bad because it does not receive any video data, it could be something like that. It seems impossible but you never can be sure if you don’t actually test it.

also it could be interesting to know what is the video quality reported by the UI.

As of reducing the choices for the videobridge, the usual way is to disable simulcast. It’s bad for big meetings, but it could be interesting to test.

You can also try to test VP9, it will not work well with some devices but if you use only PCs with Chromium it could be interesting also. To enable VP9 add

org.jitsi.jicofo.ENABLE_H264=false
org.jitsi.jicofo.ENABLE_VP8=false
org.jitsi.jicofo.ENABLE_VP9=true

to sip-communicator.properties for jicofo.

Thanks @gpatel-fr! I could have thought about that myself :smile: :man_facepalming:t2:

I also think this is very unlikely but will test it on monday (then i’ll have the same equipment again).

So the quoted Qualities are those shown in the UI at the top right corner. HD usually means 1280x720; SD 640x360 and LD 360x180 (info from the connection field)

I applied this change and as far as i can see (with 3 devices) it works perfectly.
Why is this bad for big meetings? Does it mean higher workload for the server, because it has to downscale the streams or is there no more possibility for videobridge to adapt to the measured bandwidth?

I will try this if it doesn’t work with simulcast disabled :slight_smile:

Thank you very much @gpatel-fr for the tips!

It raises the bandwidth requirements first. It may raise the Cpu load particularly if the network adapter is not smart.

Ok i get it, thanks!
In my particular situation the bandwidith requirements are a necessary problem, because with a lower resolution the viewers couldn’t read what is written at the blackboard. (This server is meant as a fallback solution if schools have to be closed again)
So if i’ve got you right, without simulcast jitsi has no other option as to send the full resolution stream it gets from the sender?

I just read in the changelog for the latest stable release (jitsi-meet 1.0.4370) that there now is a feature to manually set the video height for the different quality levels: “* feat: configurable quality levels for video height”
My question is now where to do this? As far as i can see there is no new option inside the -config.js file.

Thanks in advance!

I think (not 100% sure) it’s this:

-- a/config.js
+++ b/config.js
@@ -232,6 +232,21 @@ var config = {
     //     90: 2
     // },
 
+    // Specify the settings for video quality optimizations on the client.
+    // videoQuality: {
+    //
+    //    // Provides a way to configure the maximum bitrates that will be enforced on the simulcast streams for
+    //    // video tracks. The keys in the object represent the type of the stream (LD, SD or HD) and the values
+    //    // are the max.bitrates to be set on that particular type of stream. The actual send may vary based on
+    //    // the available bandwidth calculated by the browser, but it will be capped by the values specified here.
+    //    // This is currently not implemented on app based clients on mobile.
+    //    maxBitratesVideo: {
+    //        low: 200000,
+    //        standard: 500000,
+    //        high: 1500000
+    //    }
+    // },

about your config.js, you have to remember that your options are not wiped out by every update… That’s why there is a file named /usr/share/jitsi-meet-web-config/config.js - to document the newer options.