Resolution Problem and CPU problem

My workaround is to change between Tile View and Stage View couple times.
Every set to Stage View try better resolution in my case.
You should try it.

1 Like

@xranby thanks a lot for your time. It a little bit better with disable video background thank you.
So it’s high but not at 100% so for the moment it’s ok.

I come back to my first issues with quality, it’s ok but some of my users tried Microsoft teams Free and the quality is exceptionnal (I just try too). Also with very bad connection. 600Kbits with teams the quality is better than Jistsi with 3Mbps. I don’t who they do that but I search on google and I see the use VP9 codec, do you know if we can use VP9 with jitsi please?
I tried the sharing screen with Teams and the quality is perfect, it’s fast and there is no blur like I have with Jitsi. Maybe it’s also a difference with VP9 I don’t know.
I want to improve and optimise my jitsi at the maximum for my users because I prefer to us our internal services than Microsoft services I think Jitsi is easer to use than Teams.

Screen video VP9 on teams with a slow network connection:

Screen video H264 on Jitsi with a slow network connection:

@Anton_Karlan thanks for your reply, you are right if we switch couple times the Tite View is better.
Do you know why or do you know how to always have a good quality in Tile View without doing this technic please?

I hope this post help other admin with video quality and CPU usage


I wish I knew!
Maybe @damencho can clarify that.

Hi xranby,

Any findings for “calculateAudioFrameVAD” and how we can modify/disable this to reduce CPU usage at client side?

I think its used for calculating vadScore for PCM audio. I am not sure whether setting a static value for vadScore instead of calculating it would solve or reduce the CPU problem.


I can recommend the following two client side optimizations:



Reducing CPU further is usually not required.


We’ve also experienced the very low resolution described by @jbeunel (+ video freezing, or video going black) in this setting with 4-6 users, but the audio was stable.

@xranby, Based on your suggestion above, but given that our users had good audio, would it still be worth setting disableAudioLevels: true in hopes of improving the video resolution?

What exactly does this setting do? I thought it disabled the “Blur my background BETA” feature, but it does not. Had to remove that from the TOOLBAR_BUTTONS, even though it’s not a toolbar button.

I’m trying to understand correct the impact on simulcasting on CPU usage, after watching the Simulcast video that @xranby link to. According to that video, with simulcast enabled, each client encodes their outgoing video feed in multiple resolutions and bitrates, so that should increase CPU utilization. Simulcast disabled only encodes in one format, so that should decrease CPU utilization. Why does @jbeunel see increased CPU utilization with disableSimulcast: true ?

And is it possible to have the Jitsi server (instead of each client) do this encoding in different resolutions for different devices instead, since that server can be a powerful machine, under our control (as opposed to clients)?

This is similar to what Zoom is doing. You will need to invest tons in your server’s CPU power.

That’s why Need help for scaling and high E2E values

here are some numbers (I did not invent them, they are from a post by one of the Jitsi dev)
low res = 180 = 200kbits/s
middle res = 360 = 500kbits/s
high res = 720 = 2500kbits/s

if one assume that the CPU load is proportional to the number of bits that it has to handle, let’s play with numbers for say 10 clients

with Simulcast:
each client will send 3200 kbits so cpu load in = 32000 in
the client having the focus will receive 9 vignettes weighing 200 = 1800
the other clients will receive each 1 high res image = 2500 + 8 vignettes weighing 200 so that means 4100 per client so for all clients without the focus(4100 x 9) = 36900
For all client, 36900 + 1800 = 38700 load out for the server
total load in and out 38700+32000 = 70700

without Simulcast, each client sends only its best resolution so the CPU load in is 2500x10 = 25000
The server will also push these high res channels to the clients so load out = 2500x9 per client x 10 clients = 225000 (each client will do the job of changing the displayed image, reducing a high res flow to a small vignette)
total load = 225000+25000 = 250000

Theoretical result : load could be 3 times higher without simulcast.

I don’t know if LastN can be used without Simulcast but if if’s true it would lessen the impact.

There are more tricks with Simulcast but I’m not an expert so I prefer to not speculate furher.

1 Like

Hello, @damencho @gpatel-fr @voxter I am getting a full-screen error on my Jitsi meet installation. I install jitsi via docker and I am getting full-screen error on my 4K TV. Can you please tell me what is the problem and how I can fix it?

HI rakibulinux,

I know you did not address your question to me, I apologise for that, but…

Does your TV have a camera?

Are you using your TV as a monitor attached to a computer, or are you using a web browser built into your TV?

I ask this as when I looked at your picture, I was not seeing the familiar camera icon in the web browser’s address bar. This indicates to me that the web browser is not detecting a camera.


I have the same resolution as here:
Screen video H264 on Jitsi with a slow network connection:

Changing the Qualiti resolution at the Host screen does not change anything fro Low Resolution to HD
I tried everything written her but I have no success
The server is near Idle aprrox 0.3 with a 12 core CPU
The VM for Jitsi has GB Ram used only 1Gb 4 cpus provided with appr 4% cpu time

Any hints for me?

It is the Android Jitsi App which is causing the problems !!!
Jitsi is working in HD Mode using the browser Mode (tested with Firefox) HD mode is activated and working fine.
There is no chance at the app to force HD mode - the app is choosing the resolution.
Does not matter what connection is enabled. I tried with WLAN/FTTH 100Mb/25Mb and the resolution of the smartphone video was set to low :slightly_frowning_face: