Closed Bug 1361131 Opened 8 years ago Closed 3 years ago

Firefox and Window Manager CPU usage climbs during webrtc video calls, until FF is minimized

Categories

(Core :: WebRTC: Audio/Video, defect, P3)

Product:
Core
Component:
WebRTC: Audio/Video
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ng, Unassigned)

References

(Blocks 1 open bug)

Details

After a matter of a few minutes in webrtc video calls, the CPU usage of Firefox and the Window Manager both begin to steadily climb. When I minimize Firefox, the CPU usage of both Firefox and the Window Manager drop within a few seconds back to normal values. Upon un-minimizing both CPU usages begin to climb from normal again. On a 6+ person call, the machine is rendered unusable within several minutes. This happened in both macOS 10.12 and 10.11. Steps to reproduce: 1) Get in an appear.in audio video call with someone. 2) Wait, and watch CPU usage. (I am using iStat Menus) to watch. 3) CPU Firefox CPU usage will slowly climb. Window Manager CPU usage will climb from ~10% to over ~40% sometimes. System Info: OS: macOS 10.12.4, 10.11.(latest) Hardware Overview: Model Name: MacBook Pro Model Identifier: MacBookPro11,5 Processor Name: Intel Core i7 Processor Speed: 2.8 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 16 GB Boot ROM Version: MBP114.0172.B16 SMC Version (system): 2.30f2
I forgot steps 4 and 5. 4) Minimize Firefox once CPU usage has climbed, watch CPU usage as it falls quickly to normal levels. 5) Un-minimize Firefox, watch CPU usage climb again. 4 & 5 can be repeated
Rank: 25
Priority: -- → P2
I can confirm this behavior. I was on Release (53.0.3) and OSX 10.12.5. Hardware Overview: Model Name: MacBook Pro Model Identifier: MacBookPro11,5 Processor Name: Intel Core i7 Processor Speed: 2.8 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 16 GB Boot ROM Version: MBP114.0172.B16 SMC Version (system): 2.30f2
One hour's worth of call used ~45% of battery.
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Blocks: webrtc-perf

Setting this to P1 for investigation and analysis so we can determine its true impact to the user.

Priority: P3 → P1

Asking some time back in the media IRC channel, I was told that this looked like a compositor issue. Perhaps that would be a good place to start.

Patricia, how would you feel about changing the component so that the graphics team can have a look?

Flags: needinfo?(plawless)

I just tried to reproduce this on 10.15.7 on a 1:1 call on whereby.com. I noticed the parent process consuming a lot of CPU, ~100%, and sometimes spiking to ~130%. But it always came down. The window server hover around 60% and did not climb over a one hour call.

Might be worth checking on multi-party call.

In a large call we can have >12 videos playing simultaneously. Perhaps someone who knows the compositor could chime in with what their expectations would be under those conditions?

The window server in idle just with Firefox and the Activity Monitor on display (with an external monitor in use) is somewhere between 10-25% for me.

Talking to: jrmuizel, 1) 12 videos should not be problematic, 2) we can inspect the WindowServer process with instruments to get a better picture of what is going on.

(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #7)

Patricia, how would you feel about changing the component so that the graphics team can have a look?

Happy to change the component if it makes more sense in Graphics :)

Flags: needinfo?(plawless)

Nico, are you still seeing this?

Severity: normal → S4
Flags: needinfo?(na-g)
Priority: P1 → P3

Not that I have noticed. I'll reopen it if I see it again in the future.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(na-g)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.