For your use-case where you are only interested in the HD stream and bandwith is plenty try disableSimulcast, that would make the streamer only send the full HD variant thus then the videobridge has to forward the one and only HD stream.
@xranby hi thanks for you reply.
I did the test and now we can see 720p and more instead of 180p in full screen. thanks.
50Mbits for 4 users with dimultcast disabled
So with disableSimulcat the resolution is good in full screen but now all CPU use 100% (I7 and I9 last generation) lol
The good (not perfect but ok) settings for me could be 360p (instead of 180p) in tile view and 720p for webcam in full screen (instead of 180p) with simulcat but with 360 720 and 1080 (and not always 180p).
Is there something between disabled simulcast and enabled simulcast?
Sorry for all of my questions and problems I trying to find the middle way.
Look at the flame graph, (it is hidden i the profile images you posted) it will reveal what triggers the start that eventually cause the re-layouts. Check the Main flamegraph, zoomed into the spike like shown in the image of this example:
you may save the profile to disk and upload it here.
@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:
@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
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)?
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
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.
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?
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
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