When investigating bug 1224845 I did some profiling of Firefox Hello calls on Linux with the following results: A) plain A/V WebRTC call via appr.tc: ~80% CPU B) Firefox Hello call with screen share: ~140% CPU C) Firefox Hello call with screen share and without the patch from bug 1224845: ~220% CPU Note: this is on an ASAN build with jprof on. So don't compare absolute numbers with your local numbers. But the question is: can we reduce the overhead of screen share somehow?
backlog: --- → webrtc/webaudio+
Priority: -- → P2
Created attachment 8715472 [details] apprtc call profile JProfile from a plain Audio & Video call between my Linux machine and my Mac. Note: this was done on an ASAN build.
Created attachment 8715473 [details] Firefox Hello call profile JProfile from a Firefox Hello call with the automatic screen share. Again from the same Linux machine to the same Mac. Note: again ASAN build
Encoded resolution for screen sharing is large, up to 1920x1920. At the default 30 fps a significant hit to CPU isn't unexpected. You could try setting the fps to 15 or setting a lower max resolution for the screen share. Lowering the resolution will impact the ability to read shared text on the screen however.
In the profile I took, most of the time is spent in poll: https://cleopatra.io/#report=f71a7c620f0cbd72ff6fabc15352bb1743d99aff (this is with a plain A/V call)
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.