High CPU utilization on client end

We were seeing high CPU utilization on all clients who are connected to our jitsi meet server. The CPU utilization is 80-100% on the client machine. Then we decided to test in meet.jit.si and we are seeing the same results. We tried with Chrome on both Mac and Chrome. The call just had 3 participants with video on. Is this a normal behaviour? Is there any config changes that could be done to minimize CPU usage of the client? Any help or advice is highly appreciated.

8 Likes

Same issue on my Mac. 100% CPU usage in normal meetings.
165% (unusable) on large conferences
Any suggestions? or fix?

2 Likes

Same issues here today:-
I was one of ten users. Using Linux Mint 19.3, Chromium browser, on a Lenovo G550 laptop (an old machine but still quite usable in most situations). No other software or browser tabs open. Video quality set to lowest option.
I had very poor sound and video quality. I could not see nor hear a couple of the other users. Both cores of the CPU were running at 100% constantly. Laptop was barely usable, even the chat function had a very bad lag.
This was a poor first impression of Jitsi.

2 Likes

I see the same issue which is a real shame :cry:

My own PC is a beast and can manage without breaking a sweat, but all of my colleagues have laptops which jump to 100% CPU utilisation as soon as video starts.

I built the backend using a decent DigitalOcean server running Ubuntu 18.04 - it’s capable of handling a lot more participants.

I’ve read on other posts that the high CPU on the client side is caused by the video codec used by Jitsi not having hardware acceleration. Can one of the devs confirm that this is still the case?

Thanks

Steve

3 Likes

Hi there, we are also seeing the same issue. Both with on prem instalation but also upstream. The cpu usage increases rapidly with :

  • Multiple video streams showing even in “thumbnail”
  • Increasing vidoe quality
  • Size of the browser window

All the machines tested are laptops, i5-7300 or newer. All windows computers.
Also tested on a Linux desktop, 6 core Ryzen and dedicated GPU where the performance wasn’t catasthropic but CPU utiliziton was still rather high (30-35% on each thread).
Firefox and Chrome both had equivalent effect on the cpu usage. Same as a Riot desktop client running the website in Electron/Chromium.

Same issue. Any suggestions? or fix?

Same here, my laptop shoot to 100% as soon as jitsi starts. And coworkers complain that jitsi eat away the battery of their laptop too.

I tried to list every options that can influence the CPU usage of end-client, is this accurate ? is there anything else ?

  • Size of the local window
  • Set LastN to a low value, less stream to decode
  • Avoid using firefox. Firefox cannot do simulcast so if no constraints, it will only send the HD stream, even if others need just thumbail video, big burden to decode the stream
  • enableLayerSuspension: true
    If nobody needs the HD stream of someone, then this person will not encode in HD (needs chrome >69)
    https://jitsi.org/news/new-off-stage-layer-suppression-feature/

In config.js
resolution: resolution of the local video. But something is not clear for me, if we set a low resolution here, does this option is forwarded to jvb so that jvb can send only low resolution stream to this participant (if available) ?
constraints: Put constraint on the video capture, if low resolution here, there is less encoding work.

Anything else ?

1 Like

Hi,

I’m experiencing the same type of issues across all platform and browsers.

My understanding is that with each new participant the client side gets to decode a full vp9/h264 stream and given the lack of hw decoding, it quickly becomes a pileup that takes out clients due to lack of processing power.

Windows clients seem to deal with this a bit better, but too start to crumble after a dozen+ participants.

All machines in my test are Intel 6th to 8th platform.

From what I can tell, hw encoding and playback acceleration is available (a bit dodgy / uncertain on Linux clients) yet it’s not surprising that after 12 or more parallel video streams performance wooes.

Very desperate to understand if it is at all possible to have a larger Jitsi video group calls working.

EDIT: This image from Ubuntu site sheds some light regarding hw video acceleration in Linux:


src: https://wiki.ubuntu.com/IntelQuickSyncVideo

1 Like

I Have the Same Problem with my Macbook Air.
When there are more than 5 Peopole on a call CPU Usage is over 100%
When I use Webex there Computer is still running smoth with 10 Users on a call

2 Likes

I didn’t do a proper benchmark, but since Jitsi Meet Electron 2.0.0 (or the beta a few days before), the performance on my client (Fedora and/or Debian VM on Qubes) seems to have improved noticeably. I still have high CPU utilization, but the videos are much smoother now.

I have only tested the new Electron app with a maximum of ten other people sharing video+audio.

@damencho is there any solution to avoid using CPU and force always the hardware acceleration on client?

2 Likes

Solution to the Client computer bottleneck
Jitsi meet work out of the box with up to about 15 participants. After that you will start to run into bottlenecks for users with slow computers that the user-interface redraw itself too much and consume 100% cpu.
This can be solved by profiling using the chrome performance monitor and disable all things that consume CPU time.

For example audio level monitoring that render the blue dots when someone talk trigger GUI updates. With many users these GUI updates will cause the client web-browser to redraw too frequently that will cause the user to have a bad audio experience due to missed audio updates. The solution is to simply disable the AudioLevels monitoring.
disableAudioLevels: true,

On the left only 10% CPU when audio levels are disabled. On the right 100% CPU time when audio levels are enabled due to frequent audioLevelReport processing and GUI re-layout.

2 Likes

So I just tried this on some of our machines - mostly Macbook Pros, reasonably decent spec from the last 2-3 years. It seems to have helped a little bit perhaps, but not by any significant amount.

I also tried the same using https://meet.jit.si/someroom#config.disableAudioLevels=true and while the blue dots did in fact vanish, the CPU utilization was not much better. Still 95-120% on my 3.5ghz Intel i7 Macbook Pro.

Which Jitsi version did you try this on? Did you make any other changes? I’m dying to find a way to get the CPU utilization down myself - when using the profiler it all seems to be Scripting that takes time, in small bursts. Sometimes related to mouseover events, sometimes just the timer functions.

Any extra ideas on this @xranby would be amazing!

2 Likes

Try use the chrome browser inspect page -> performance tab analyser and check what is causing high CPU/GPU load on your machine. You may experience something different that cause your high load.

Open the chrome browser page inspector, switch to the Performance tab, then press record for about 5-20 seconds.

With the capture allows you to zoom using the scroll view and highlight sections of the capture with high CPU load and investigate what function calls cause the CPU load. The “flame graph” will reveal what scripting function is causing the high CPU/GPU load.

Please share a screenshot of the performance tab or share the saved capture from the performance tab so that we can see what is happening on your machine without guessing.

This is how it look when you are profiling: High CPU utilization on client end

Chrome profiling and evaluation tips: https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/

2 Likes

Same issue here, of high CPU load.

DELL Latitude 7480
OS: Windows 10 (1909)
Browser: Google Chrome (81.0.4044.113)
CPU: Intel Core i3-7100U @2.4GHz
GPU: Intel HD Graphics 620
RAM: 8Go

Initially my Google Chrome browser was in “compatibility mode Window 8”, due too a bug link to Symantec Endpoint Protection.
In compatibility mode, even in a simple conference with 3 participants, it was unusable. CPU at 100%, laggy computer, robotic voice etc.

After applying the workaround from Symantec, and disabling compatibility mode, it’s better, but CPU usage is still high, between 80% and 100%. It regularly hit the 100%, but it comes down a little (around 85%) quickly enough to not affect audio quality.

On my typical 3 participants conference test, the two others are a Chromium Browser (80.0.3987.162), and a android phone using Jitsi-Meet app (20.2.1)

2 Likes

Having the same issue.

OS: Windows 10 (1909)
Browser: 81.0.4044.113
CPU: Intel J2900 @2.4GHz (Quadcore)
RAM: 4 GB
Webcam: Logitech C270

As soon as the Jitsi meeting starts, the Video Capture process shows up with a high CPU load in Chrome Task Manager (Shift ESC). This is already the case when I’m the only one in the meeting.

When the someone joins, the CPU load of the Video Capture process increases slightly and the CPU load of the tab Jitsi Meet also goes up a lot.

On this PC this makes using Jitsi with video unuseable.

We see the same issue on Chrome. Can anybody from the community give us some advice?

please share a screenshot of the performance profile, or attach the performance profile so that we can look at it and examine what is causing the high cpu load instead of guessing: instructions: High CPU utilization on client end

OK, hopefully I got it right with the performance profile. Basically I had it running for 20 secs. During this time the CPU was at 100% all of the time (was not able to find that back in the performance profile). Please let me know if you need another view of the profile. Thanks a lot!

Hi,
I have the same type of issues.
However I noticed that if I use Chrome and I set the view to tiles the CPU load is reduced significantly.
I also set disableAudioLevels: true in jitsi meet config, reduced max resolution to 480p and disabled p2p.
I tested this configuration also in meet.jit.si by joining with 3 pertecipants (to disable p2p) and the behavior is confirmed: CPU load seems ok.
In Firefox the problem still persists.
So this test makes me think that the problem is around the dominant speaker detection, but only a guess.

thank you all for your help.

Riccardo.

1 Like