Jitsi-meet: Website is melting my CPU!

[taoeffect]

I have no idea why meet.jit.si, unlike appear.in or any other video conferencing app I've used is melting my CPU, but it is, and it's infuriating.

I think it's because for some reason it decides to add all these unnecessary video effects into the background, blurring, etc.

It would be wonderful if this could be fixed, as everyone I've ever chatted with using this software has complained about it.

[damencho]

Are you using Firefox? Can you test with current meet.jit.si deployment, do you see the issue today?

[taoeffect]

@damencho I'm using Chrome. And yes the problem still exists. It's probably the silly + pointless background video effect that Jitsi has.

[tuncK]

I also suffer from a similar problem. I tested with the current meet.jit.si on Linux Mint 18.3. Memory and network usage are negligible, but:

If the camera and microphone are turned off, Chrome 65 consumes about 2x20% CPU power on two threads, if they are on it consumes 2x30%.

Even more severe with Firefox 59: when camera/microphone off (on) process Firefox takes 50% (80%), "Web Content" 40% (45%).

[dest4]

I am also facing similar performance issues on meet.jit.si confereneces. Config: Linux Mint LMDE2, Firefox 59.0.2 and Chromium 57, with similar intensities as measured by fellow user tuncK. Product is barely usable as is on my laptop Intel i5.

Note that even when the conference is finished and the screen asks to rate the call experience, the CPU usage is still high. It only drops when going back to the main page meet.jit.si

Any pointers to help solve this problem would be appreciated.

[damencho]

Can you share what you see at "chrome://gpu" if you open it in chrome?
What about watching a youtube video, what is the CPU usage then?

[tuncK]

Sure, here is the output: chrome_gpu.txt

A typicalYoutube video consumes much less CPU. 3 threads, 15%, 6%, 6% on the same computer, i.e. somewhat less than the usage when jitsi-meet is idle with camera off. On Firefox CPU usage is somewhat higher, but trend is still similar.

[saghul]

The YouTube example might not be very elucidating because it may use H.264, which is usually hardware accelerated, but Jitsi Meet needs to use VP8, which is not.

On 1-to-1 calls we tried to use H264, but the results were not great, so IIRC it's now disabled by default.

Something I noticed when testing appear.in right now is the resulution: they request 360p by default AFAICT, which is a lot less than the 1080 we require.

@taoeffect Can you test with a URL like so? https://meet.jit.si/testResolution123#config.resolution=360&config.constraints.video.height.ideal=360&config.constraints.video.height.max=360

This will override the default 1080p resolution setting to 360p, like appear.in does.

As for the blurred background, we already disable it on Firefox and Safari, but there is no setting for it.

Last, you can also adjust the received video quality, which will also lower the CPU usage, see the "Manage call quality" option in the "..." menu. Note, however, that this option has no effect on 1-to-1 calls and it doesn't affect the sending side.

[tuncK]

@saghul Maybe I should clarify a bit. Resolution certainly changes the load on CPU, but there is a significant CPU usage by other background processes even when the camera is completely off. This is the case even if the client does not have any other members in the particular room to exchange audiovisual data at all and camera is off.

[taoeffect]

As for the blurred background, we already disable it on Firefox and Safari, but there is no setting for it.

Why is it enabled at all? Nonsensical "feature" that provides no value and just eats at the CPU.

This will override the default 1080p resolution setting to 360p, like appear.in does.

Why is 1080p the default? Nobody needs 1080p video for conference calls.

I'm not going to waste any more time fiddling with jitsi settings. It's ridiculous I even had to open this issue to bring this to your attention, and it doesn't sound like you're interested in fixing it. I'd rather put effort into writing my own WebRTC thing that works and doesn't cause people's CPU fans to blare so loud that you can hear it on the call.

[saghul]

Why is it enabled at all? Nonsensical "feature" that provides no value and just eats at the CPU.

It provides a nicer user experience when the aspect ratio doesn't match.

Why is 1080p the default? Nobody needs 1080p video for conference calls.

This is, of course, debatable, I respect your opinion, and as I pointed out you can configure it dynamically via URL parameters, or by editing config.js if you run your own deployment. What we run on meet.jit.si doesn't have to be what you run on your own installation.

I'm not going to waste any more time fiddling with jitsi settings. It's ridiculous I even had to open this issue to bring this to your attention, and it doesn't sound like you're interested in fixing it. I'd rather put effort into writing my own WebRTC thing that works and doesn't cause people's CPU fans to blare so loud that you can hear it on the call.

I don't know where you get that feeling from. You opened an issue, we responded, more people are giving input as this is being looked into. There are many things at play here, so it's not just a matter of disabling one thing and it will magically be 10x faster. We need to look at the whole picture, and this takes a bit of time.

You are free to build your own thing, of course. If you ever decide to come back to Jitsi Meet, we'll be here.

Good luck with your project.

[dest4]

Not diving into flame wars, here are just CPU measurements on Firefox 59 on Linux. I am alone in a room with audio and video.

1080p (original meet.jit.si) : 70% on main Firefox + 28% on Web Content thread
360p (testResolution123 above): 44% on main Firefox + 28% on Web Content thread

for what it's worth, GPU acceleration seems active (integrated GPU). in about:support, the relevant section gives:
GPU #1
Active Yes
Description Intel Open Source Technology Center -- Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
Vendor ID Intel Open Source Technology Center
Device ID Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
Driver Version 3.0 Mesa 10.3.2

[dest4]

Comment on my previous message: I am not sure GPU acceleration is active on my platform.

Diagnostics
AzureCanvasAccelerated 0
AzureCanvasBackend skia
AzureContentBackend skia
AzureFallbackCanvasBackend none
CairoUseXRender 0

Decision Log
HW_COMPOSITING blocked by default: Acceleration blocked by platform
OPENGL_COMPOSITING unavailable by default: Hardware compositing is disabled
WEBRENDER opt-in by default: WebRender is an opt-in feature
unavailable by runtime: Build doesn't include WebRender
OMTP disabled by default: Disabled by default

[dest4]

I spam you again: I did tests for Chrome 64

CPU usage:
1080p (original meet.jit.si) chrome 12% chrome gpu process 12 chrome renderer 24 chrome utility 28
360p (testResolution123 above) chrome 12% chrome gpu process 8 chrome renderer 16 chrome utility 0

cinnamon (window manager) 28% in both cases (wtf!?), but ~ zero when conference is inactive.

1080p Xorg 16% pulseaudio 12%
360p Xorg 12% pulseaudio 8%

chrome://gpu output here:
https://gist.githubusercontent.com/dest4/8a52e1359f1e1ed3b7eee4d2a5cd07a6/raw/4c94266a05fafa26546f6d509e2475a9b32ab9d3/chrome%2520gpu%2520info%2520dell%25209343%2520lmde%25202.md

[dest4]

On appear.in, when alone in a conf the video uses half the screen (4x less pixels).
CPU usage with Chrome is the following
chrome 16 chrome gpu 8 chrome renderer 16 chrome utility 0

cinnamon 24%, pulseaudio 12% Xorg 12%.

The Chrome utility contribution, 0 on appear.in and on 360p Jitsi, but at 28% on 1080p jitsi, seems like a low-hanging fruit that may be worth looking at. It's 30% of the load for 1080p jitsi.

[taoeffect]

I don't know where you get that feeling from.

I shouldn't have allowed my frustration with the situation to be expressed in the manner that I did above, so I apologize for the bad tone.

But, to answer the implied question there, the feeling comes from a bewilderment at how so much effort can be placed into an important project, only for the result to be entirely unusable for all users (edit: that I've tried it with). Over 200% CPU usage (if I recall correctly), meaning at least two cores are being maxed out, and working on a third. And since there is no better open source alternative... and this issue is over a month old... [/end rant]

[saghul]

Thanks for taking the time to follow up. I understand these things can be frustrating, while this looks like a large project, we don't have unlimited resources and not all priorities are under our control.

I can't make any promises, but already started to see if resources can be allocated for this.

Cheers,

[saghul]

Hey all! So, we have looked into this. See https://github.com/jitsi/jitsi-meet/commit/f015f4edc397e28c139e6638ae1d9a27025db86e#diff-cd77d30daec2652b1752ccd07f6fda61 and https://github.com/jitsi/jitsi-meet/commit/19ce472d4d0f87c3e69982cc370722d227377c64#diff-cd77d30daec2652b1752ccd07f6fda61

TLDR: it's now easier on the CPU, and it can be turned off if don't want it altogether.

[msl-kabo]

This is my laptop in a meeting with one other person, call quality set to "audio only", and the other party has their camera shut off. Meeting is in P2P mode. When we both turn on Video in high def all CPUs are maxed out.

Using Chromium Version 62.0.3202.89 (Developer Build) built on Debian buster/sid, running on Debian buster/sid (64-bit). Firefox uses the same amount of cpu.

Is there anything I can do? I'm really passionate about open source and love not using google meet, but it would also be great if my laptop battery lasted more than 30 mins in a meeting... :)

[saghul]

@msl-kabo Can you reliably reproduce this? When there is no video, there is no blurred background, nor quality setting we can adjust, so TBH I wouldn't know what to try!

[tkoziara]

Hi:) In this context: I was testing Jitsi Meet on a Mac laptop using latest Chrome. Yesterday I talked with a friend for over an hour and CPU fans were on for the most of the call. Today I sat on my own with a call window opened using latest Firefox and after about 20 minutes the fans were again on. The CPU usage (today) as reported by top was about 30-40%, but still the laptop was heating up and only came to rest after Jitsi was turned off.

[saghul]

@tkoziara I'd say that's expected. Video conferencing is taxing on the CPU because we need to use a codec which is not hardware accelerated. (see above for the reasoning)

[tkoziara]

@saghul thank you for explaining; Would the CPU demand increase significantly if there were multiple participants in the call? I would like to use Jitsi Meet for video conferencing with multiple participants.

I use Zoom from time to time and it seems to be less demanding on the CPU; Does it mean that it exploits hardware codecs? Do you think there could be a way to still improve Jitsi in that respect? Or perhaps also other WebRTC based services, such as appear.in or talky.io, produce a similar demand on the CPU? (because they share technology)

Thank you:) Tomek

[saghul]

Would the CPU demand increase significantly if there were multiple participants in the call?

Not by much. Each participant not in the large view is sent in a very small resolution.

I use Zoom from time to time and it seems to be less demanding on the CPU; Does it mean that it exploits hardware codecs? Do you think there could be a way to still improve Jitsi in that respect? Or perhaps also other WebRTC based services, such as appear.in or talky.io, produce a similar demand on the CPU? (because they share technology)

It depends on a number of factors: it's possible they are using H264, and a full-mesh topology, but that won't scale beyond a point. We use 720p by default (down from 1080p for now) and as I mentioned above I've seen other services use lower resolutions like VGA, this can have significant impact on CPU usage.

[tkoziara]

OK, thank you. That closes the topic for me for now:)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[JosjaVanBever]

Hello,

I am using a brand new Dell XPS13 with Ubuntu19 installed. The jitsi web application is eating up to 250% of cpu when having a video conference. Consequently, the cpu fan is turning grazy so loudly that my microphone only hears computer noise. As a result, I cannot access the conversation anymore because my voice is not recognized within the noise of the fan. Using a headset is no option because we participate with two in the video conference and the noise of the fan keeps going anyway. This problem prohibits me of using jitsi and I will need to convince all people participating to our video conferences to not use it anymore. Could you please fix this grazy overconsumption problem asap? As a first step, you could tell how I do set the absolute minimum configuration with only camera and microphone via https using standard wifi, excluding tools as TCP harvesting (sth I've read at https://community.jitsi.org/t/jitsi-videobridge-consuming-200-cpu-utilization-constantly/19482) and so on. I am even not interested to share my screen at this point as talking is already a challenge in these times.

Thanks in advance,
Josja Van Bever

[up_the_irons]

I used Jitsi for the first time yesterday and my CPU load average climbed so high, that eventually I was forced to reboot. Shutting down Chrome didn't solve the issue. There was a single chrome process still running (I run latest Arch Linux). I couldn't even kill -9 it, and I'm not sure why. My mouse stopped working and my Bluetooth keyboard disconnected. It was like a total meltdown.

My friend, who was on the other end of the video conference, was on a Mac and he also had to reboot his machine.

I know this is all mostly anecdotal, but I just want to bring this up because it's still an issue.