Enable video in a Google Meet call makes Nightly stutter and hang.
Categories
(Core :: WebRTC, defect, P3)
Tracking
()
People
(Reporter: alex_mayorga, Unassigned)
References
(Blocks 2 open bugs, )
Details
(Keywords: nightly-community, perf:responsiveness, Whiteboard: [wfh])
Basic information
Steps to Reproduce:
Enable video in a Google Meet call.
Expected Results:
A normal video call.
Actual Results:
Firefox stutters and hangs after the video feed is open for a while.
More information
Screenshot: N/A
Profile URL: https://perfht.ml/3cyBIY7
Basic systems configuration:
OS version: Windows 10 Pro Insider Preview 19613.1000
GPU model:
Number of cores: 4
Amount of memory (RAM): 24GB
Thanks so much for your help.
Comment 1•4 years ago
|
||
I see a lot of GC happening, including a 6.5s GC major and 2s slices. Jon, do you have any ideas?
Updated•4 years ago
|
Comment 2•4 years ago
|
||
That 2s slice looks bad. The GC reason is USER_INACTIVE which indicates that the browser thinks the user is not active and so has triggered a potentially slow compacting GC. I guess we need a way to either inhibit the user inactive signal if the user is doing something that requires the browser to be repsonsive, even if they aren't actually interacting with it, or some other way to tell that this is happening.
Comment 3•4 years ago
|
||
I agree the GCs on Web Content 4/8 look bad, but I don't think that's the main issue - I think Web Content 4/8 only runs background tabs.
The actual problem seems to be in Web Content 3/8: https://share.firefox.dev/3gpFFR9
There's an eight second hang where the main thread is waiting on a WebRTC lock, in PeerConnectionImpl::SetRemoteDescription
. The same happens two more times, each hanging multiple seconds. Other hangs happen during WebrtcVideoConduit::PollStats
and the rtc::TaskQueue
constructor. It seems that some WebRTC threads are completely overwhelmed.
Comment 4•4 years ago
|
||
It looks like webrtc::CallStats::RegisterStatsObserver and webrtc::CallStats::DeregisterStatsObserver are taking a lot of time. Coupled with the mention of WebrtcVideoConduit::PollStats in comment 3, it seems that stats code is part of the issue.
Nico, any idea off the top of your head on what would cause us to hang in webrtc.org stats code?
Comment 5•4 years ago
|
||
Not off the top of my head, I think that this is just another reason to get rid of the stats polling.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 6•4 years ago
|
||
Setting this to P1 for investigation and analysis so we can determine its true impact to the user.
Comment 7•4 years ago
|
||
Hey Paul, I think this is another instance of the bug we discussed yesterday. Do you have a bug # to dupe this to?
Updated•3 years ago
|
Comment 8•3 years ago
|
||
Waiting on the uplift to land so we can generate new profiles with the new library.
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Hey Alex, could you test in our Nightly builds and see if you can still reproduce?
Updated•3 years ago
|
Comment 10•3 years ago
|
||
The recent uplift should have helped here. We'll follow up once we get into video playback performance work for 2022.
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Description
•