Open dbkr opened 1 year ago
could that be related to hiDPI displays?
Seems to be scaling with participant (peerConnection) count
In red there is the number of peerConnections (this is not a good experiemtn but it definitly gives strong hints): Does the amount of CPU scale with number of participants in the call? yes
I've noticed this same behavior as well and it makes Element Call no good for me and my friends. It's an absolute dream with only 1 other user in the call but as soon as anyone else joins, almost any medium to high performance application I try to run stops working. I don't know why software encoding is being used at all, but I really don't get why it seems to be reencoding it multiple times for each user?? (This is conjecture, I don't know how the system's internals work)
FYI I've tried it on firefox and chromium with the same behavior, both running on Arch Linux. I've gotten 100% CPU usage just trying to have a screenshare and a video feed between two clients, on my 5600X. Interestingly, other times, I get 20% usage streaming a video feed and a screenshare between 3 clients despite no visible loss in stream quality/framerate, so, I have no idea whats up really.
Steps to reproduce
Often when I start a screenshare, it will max out every core on machine. Reports of similar from others too. We should investigate if there's something wrong here, or if this is just actually how much CPU it takes to encode a screenshare to full mesh participants. Does the amount of CPU scale with number of participants in the call?
Outcome
What did you expect?
What happened instead?
Operating system
No response
Browser information
No response
URL for webapp
No response
Will you send logs?
Yes