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.
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 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.