High CPU utilization on client end

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?

6 Likes

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

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 :confused:

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.

2 Likes

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.

Hi all.

I have same high cpu utilisation on client side.
How fix it? Best practices?

Thank you

You’re probably right about needing more horse power. I should have mentioned, my running at 5% is on a Ryzen 3950x to put that into better perspective.

I am not sure if anyone got any further with this. As far as I can tell jitsi is not at all useable for meetings of 5+ video callers unless you have total control over the client hardware. I am working with a changing audience and want to have 13 people in a video chat. I am running jitsi from my own 8 core server and it the server is only ever hitting about 10% cpu. The client CPU usage is ridiculous; pretty much anyone with a macbook air cannot join, gets audio completely chopped up, has video dropping in and out (PS I need tile view, we all need to see each other at once - no other option).

I have turned off audio levels and all video in our last test was max 480 in height.

We are doing deployment tests and meeting on zoom to discuss issues, with the same machines we can all easily video chat with zoom in grid view with clear audio, with jitsi forget it. We did our initial tests on developer machines with OK specs and they worked mostly well, we were not sure where issues were coming from. With more widely spread tests we see that the problems were rarely internet bandwidth related, but due to the massive CPU consumption of Jitisi.

Changing browser seems to make little difference and at any rate we need to be able to let people use their default browser.

If anyone has found a way to make this useable for a 10- 15 person video call without needing to vet hardware let me know. So far my experience is that for group calls and where these are public (you don’t have control of the client machines) Jitsi is not the answer.

Yes same problem here. Really keen to get a solution to it. Unfortunately zoom appears to be more cpu efficient.

I am on my laptop and just connected to a meeting with just myself. It went virtually to 100%.

I tried downgrading the ubuntu NICE characteristics so it is at the back of the queue for cpu resource but it had no effect.

What about reducing the local FPS rate ? That will mean greatly less data to process. Really we just want to see someone when they have moved their lips so what about motion detection ?

Good Luck.

If you pay good attention to zoom the video quality is terrible, but the audio is priority decoded - this makes a lot of sense and is what is needed for a video chat system. With Jitsi when the CPU load is too heavy clients try to stream all frames of all video- this makes the audio unintelligible and the conversation - what it should be enabling is impossible. Motion detection would most likely use even more cpu, but what about probing CPU usage in clients and dropping the frame rate until it is useable.