Closed Bug 1702609 Opened 10 months ago Closed 3 months ago

GMeet broke completely when sharing the screen on a meeting

Categories

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

Firefox 89
x86_64
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox89 --- wontfix

People

(Reporter: alex_mayorga, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: nightly-community, Whiteboard: [wfh])

¡Hola y'all!

GMeet broke completely when sharing the screen on a meeting.

Had to start up Chromium to continue presenting.

Managed to capture this profile https://share.firefox.dev/3ufnAeM

¡Gracias!
Alex

So how exactly was it broken? Browser became non-responsive? Screensharing stopped updating frames? Did you stop getting audio/video also (or did other participants stop getting audio/video from you)?

Flags: needinfo?(alex_mayorga)

¡Hola Byron!

I would say, all of the above.

It was pretty terrible.

Sorry if this doesn't really help much.

Other participants video started to have artifacts and pixelate.

I stopped getting any audio nor video.

Browser unresponsive.

Hope this helps.

Happy to meet with somebody to try and replicate the bug if the profile is not good enough.

¡Gracias!
Alex

Flags: needinfo?(alex_mayorga)

Yeah, meet is pretty much unusable right now (for me, on Nightly, on OS X at least). Turning off remb seems to at least make it usable, although I see signs that bandwidth estimation is not functioning properly (repeated bandwidth collapse). Looking closer.

Also unusable on release.

Also totally broken on ESR 78.

Seems like meet has made some sort of change that has broken Firefox pretty badly. On a tab-to-tab call, the second tab renders a single (or maybe another very small number) blurry video frame. Occasionally, video frames begin flowing somewhat normally, but before long the video feed will freeze again. Disabling REMB seems to work around the brokenness.

Edit: Still seeing freezes with REMB enabled, although recovery is faster and cleaner.

Comparing with Chrome, Firefox is trying to use way more bandwidth. Chrome seems to top out at 100KBps sent for each side, whereas Firefox ends up trying to send around 4 times that, which then seems to trigger a congestion collapse.

I should point out that the work-in-progress from bug 1654112 does not seem to fix this problem.

FWIW, l was told Meet was (is?) very broken in Safari too.

Nils, FYI. Have we reached out to the Meet team here?

Flags: needinfo?(drno)

(This is tracked as part of wfh. No need for qf here, I hope.)

Whiteboard: [qf?][wfh] → [wfh]
Flags: needinfo?(drno)

Tested again, seems fine now. Probably was a site issue?

Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.