You get 180p streams when in Tile View unless you change the settings for the resolution in Tile View. This is intentional so you save tremendous amounts of bandwidth when viewing all streams at once.
@voxter thanks for your reply.
In tile View I have 180p and in full screen 180p too. it’s my problem.
I don’t want to save bandwidth , the video flow can use 10Mbits, 100Mbits 500Mbits or 1Gbit per user it’s not a problem for us. I just need to find the good setting and where to fix or force the best resolution everytime in Tile View and in full screen. For me the minimum should be 720p.
You say it’s intentional but do you know where I can change this setting please for example to put 720p or 1080p or I don’t know 4K 8K please?
Also with 2 users I have 720p everytime I have the 180p problem with more than 2 user. So it should be a settings on the jitsi server somewhere
In 180p our the resolution is bad we are pixelised: see my head or try to read this book.
Our users complain every day about the Tile View bad quality.
An other thing with no link with my problem if somebody doesn’t know that :
If you share you screen then enable your webcam then disable the webcam you will have a good resolution 2560X720 and 30-33 frame per second.
You can share a video game or a film without problem.(1.4Mbps)
I’m not using the youtube share but the standard full screen sharing.
Also If somebody know how to have everytime the max resolution and max frame per second without doing this technic , let me know.
And I did a sharing test in tile view: I have 3840X1080 not 180p why we can’t have high resolution with webcam? (our webcam are 720P Full HD and 4K but stay at 180p)
I did a test again with sharing full sreen with a video running in full screen in 720P 33 Frame per second it’s perfect:
And forza 4 trough Jitsi in 720p using full screen sharing (it’s not a video it’s the game) :
When I see that I don’t understand why we see webcam in 180p and sometime 135p.
If the sharing can do high resolution with 32 frames per second it mean the network is good and the server too but why 180p for webcam lol.
If you see 180p on stage view, this means that datachannels do not work and basically jvb is not receiving information who is on stage to be able to switch to HD layer.
Here is an example of 180p in full screen
Only the screen sharing is perfect with the technic I explained but webcam video stay at 180p.
In which file can I check the configuration or where can I see if there is a problem please?
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.
Good to hear that HD is working.
I am interested to know what is causing 100% CPU, can you profile the user-interface using chrome or firefox inspect performance tab and see what is consuming most CPU time?
To further improve optimal bandwidth I think you need to change the react user-interface to change the video mode on the fly depending what mode the remote user is at possibly in combination with Off stage layer suppression: https://jitsi.org/blog/new-off-stage-layer-suppression-feature/
As you can see now it’s in HD. we se my face and the resolution is good compare to my previous post.
everything in close on this laptop and the CPU is at 100%
OK i’m going to check the performance
Thanks again for your help
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.
Everything is closed on this computer. All application, all signet and all programm is the taskbar.
We are only 3 in the meeting.
Please find the capture here (remove .txt):
The cpu was not completly at 100% for this test but very very high
Profile-20200420T183756.zip.txt (3.1 MB)
Thank you, I have taken a look at your profile and examined the two top CPU eaters:
28% of CPU time have been used for _updateCanvas -> drawImage - this is done by LargeVideoBackground …
Try disable the LargeVideoBackground in interface_config.js !
25% of CPU time have been used for VAD (voice activity detection) “calculateAudioFrameVAD”, this is unexpected high!
Not sure why… i have to think about it.
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.
@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.
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.
@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
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.