High CPU usage with attending meetings on Jitsi [WebRTC] on my Raspberrypi 4

I have been using my Raspberry Py 4 [4GB RAM] to attend meetings on Jitsi meet connected to a Logitech 720P USB Camera. It works fine and I don’t see any issues [like buffering or frame delays during the meeting] in the meeting even with 6-8 people with video at times.
What I notice however is that the CPU is at 98 -100% usage [All 4 cores of the Pi]. Ram utilization is low, but CPU hits the roof as soon as the meeting starts even with just 2 people. If I turn off my video the CPU utilization drops to around 92%]. And as soon as i stop/end the meeting the CPU immediately comes down to 30% utilization.

This problem is with this high utilization I feel opening other application to share screen will be an issue and not sure if its even a good idea to run CPU at 100% for long duration. I have noticed the same behavior on GoToMeeting meetings as well. [ Zoom I have not been able to get it to work on my Pi].

Do you have any suggestion on how the CPU utilization can be brought down? or at this moment this is the best we can expect on a RPi. Any suggestion is greatly appreciated.

I am using the Raspberry Pi OS [Latest Raspian] and have a Fan on the Pi’s processor so the Temp of the Pi is not going above 60 C. I have tried Joining the meeting using Chromium or Vivaldi.


Encoding and decoding video is CPU intensive and this is expected. Switching off video will reduce CPU.

1 Like

Thank you very much for your response Damian.


Doesn’t happen like that on Zoom though. At least not to that extent, any ideas why?


Is that a code name for something? What’s Zoom multistreaming? and YES I tried Googling it

This is how webrtc works using multiple streams, servers do just packet routing clients are those getting the multiple streams decoding and showing them.
Zoom is using the MCU technology where client receive only one stream, which is composed from multiple steams, but the servers must decode everything, mix it and encode it, per participant. This requires enormous amount of powerfull servers, that’s why the SFU technology is the modern one, where a server can handle thousand of streams and with less resources serve more participants.
Search and read about SFU and MCU.

1 Like

Hmm interesting. Only thing is, as this post mentions, that it kills our computers using large number of participants. Even more so when not using full hardware acceleration cause of VP8.

Is there a way to reduce it somehow? Maybe by just sending high quality streams or let’s say 480p and 720p taking out the lower resolution one on simulcast.

Or is it possible to force H264 which will allow HW acceleration? I tried forcing the JVB to send H264 on Jicofo config file but the results are painful. Video gets stuck and delayed.

What are your thoughts about this @damencho?

Jvb is already sending lower resolutions for thumbnails and high for the on stage. You can try forcing using h264, but then I think simulcast is not working so you will have a lot of traffic which also can cause problems …
Or you can force all clients to use lower resolution. Or just set lastN to the number of streams you think it is safe, this way jvb will forward only the last N number of active speaker streams …

For some reason I have not been able to get Zoom work on my Raspberrypi. GotoMeeting, Jitsi meet work fine [ with FULL CPU usage].
I even tried after installing the Chrome Media Edition based on the below URL as many had
suggested zoom works with the media edition installed https://blog.vpetkov.net/2020/03/30/raspberry-pi-netflix-one-line-easy-install-along-with-hulu-amazon-prime-disney-plus-hbo-spotify-pandora-and-many-others/.

While netflix and Amazon Prime work but Zoom still does not.

Any pointers on how you got Zoom to work on RPi?


There is another thread discussing the High CPU usage on clients in Jitsi but not limited to RaspberryPi.

I think you should ask Zoom questions in Zoom forum :man_shrugging:

1 Like