I looked at your profile.
The summary looks OK, the page is mostly idle. According to this your CPU is 89% idle.
9% of used CPU time is spent in calculateAudoFrameVAD.
Thus from a first glance the profile you sent do not show any massive CPU use…
However the frames looks a bit odd… it looks like some frames take half a second to render! Normal frame time is 30ms (for 30fps)… not 577ms !!! Do the image stutter?
Yes, video was stuttering as well. And the rest of the machine could not be used practically anymore (Quad-core Macbook Pro…)
Because i could not see any CPU related issue:
Can you try disable the hardware accelerated codec:
disableH264: true,
( found at 2 locations in /etc/jitsi/meet/*-config.js )
I can’t edit the config.js files as I’m using meet.jit.si service
The guys from „freifunk münchen (Munich) https://meet.ffmuc.net/ did a lot of adjustments including disabling the blue speeking dots and harder downscaling. My cpu usage is slightly lower on my Mac than using meet.jit.si but still ultra high compared to Zoom or Google meet .
Nevertheless Jitsi is the number one tool for me .
I found a workaround by disabling hardware acceleration in Google Chrome on my Mac in the Advanced Settings section. Then the massive CPU usage is no longer there and everything else works in video calls. So seems an issue with the hardware acceleration?
@mkrecek is there anyway to invoke this… by default when we open the jitsi meet deployment… Like how it asks for permission of camera n mic… can we do something to ask the user turn off the hardware acceleration on a click before starting the meeting…
Thanks in advance…
I’d think this can be a bug in Mac OS in combination with Google Chrome which will be fixed soon I hope? May be we wait for the official next Mac OS X release coming soon and check again.
Anyone else confirming this workaround?
it’s not our bug or something… normally every client end user of Jitsi meet… is facing this issue on high CPU usage… so… yeah
This is a really old blog post that shown that for some circumstances, ofter the HW acceleration make everything worse.
I’m trying to figure out if there’s a JS way to disable it or maybe a browser extension
Edit: after 1 hour of search I figured out that there’s no way to disable HW acceleration, the only possible good solution could be fo force H264 as video codec in jitsi to avoid a huge impact from jitsi
a combo of both… actually is making a great difference… on CPU Usage… and it really works… problem is publicly trying to turn of HWA of the browser… n make sure it works… by default whenever the user land in the meeting…
I can’t find this option SET_FILMSTRIP_ENABLED in the documentation of the configuration file
You are right, the SET_FILMSTRIP_ENABLED option do not exist in the stable or unstable branch. Hmm I was apparently using my own branch with the following pull request merged:
https://github.com/jitsi/jitsi-meet/pull/4631
And on my current branch i always start with filmstrip hidden like this:
APP.store.dispatch(setFilmstripVisible(false));
https://github.com/xranby/jitsi-meet/commit/00ba1287322579937d09a16ecebe033afe81cd54#diff-17b5d861b829a8bed4ae36841e20b8a9R170-R171
There is no configuration option yet, sorry. I hide the filmstrip by compiling my own webview userinterface.
I have to admit I’m a bit baffled that the solution here is to analyze the variety of high-memory/performance impacting Jisti processes and go through a process of experimentation to disable these and see what works. IMO the Jitsi defaults should be prioritized to minimize performance issues and there should be a config UI for users to opt-in to whatever features these performance-impacting configurations support. Would love to contribute that, but I’m not a Java guy.
I’ve just set up docker-jitsi-meet on a Debian 9 2 core 4GB VPS. I had a 10 person call with multiple OS’s and browsers and two participants on macbooks had high CPU usage with one crashing his machine and being unable to join the call. The tile view would also constantly switch between video and the black/profile placeholder for most of the users.
I don’t even have a macbook, the users are non-technical, and I’m not in a position to get them back on the line and have them troubleshoot the issue with me using dev tools (much less get 10 people back on the line for apples-to-apples testing).
I was really hoping Jitsi would work well enough out of the box for up to around a 10 person call given the above specs and default configuration - or at least that there would be a clear and documented manner for a configuration that prioritized usability. As it stands, my participants gave the experience a 5/10.
I guess I’ll give Big Blue Button a try.
Good luck!
My experience is very much opposite, but I think this conversation is going to have lot of variety due to system specs. My client machine runs at about 5% during an average conference. The Jitsi server is on a quad core 2.4Ghz system all defaults.
That said, it is relatively higher than Microsoft teams on my same system. I know Teams isn’t browser based, but it runs around 2% on my system compared to 5% with Jitsi in chrome. Doesn’t sound significant, but It would be like an older machine running Teams at 40% requiring 100% to run Jitsi.
yes recent updates has made it cpu hungry (15 to 20 percent getting… )
tried the switches but but not helping reduce it much.
and the video is corrupting now…
I need a 24 thread laptop now 
Win 10… 12 thread.6core low end MSI I have.
using browser BRAVE to Chrome USer only p2p
Can you run a profile using the chrome or firefox performance inspector?
Only such a tool allow you to see what is consuming the CPU.
Im using this after the URL and roomname… so this dont stop HW you mean? see last line
#config.disableAGC=true&config.disableAudioLevels=true&config.disableH264=true
Done that… didnt change. jitsi used to work better then this months back.
