High CPU utilization on client end

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

1 Like

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.