1743694 - Frame hangs on Google Meet

Status: RESOLVED DUPLICATE of bug 1875201

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

Description

[Jeff Muizelaar [:jrmuizel]]

I was running Google Meet on the same machine between Firefox and Chrome. Firefox had occasional moments where the incoming video would freeze where as in Chrome it always played.

What's the best way to debug this?

Comment 1

[Michael Froman [:mjf]]

Capturing a profile when this happens is probably the best place to start. Saving a copy of about:webrtc and attaching it here is helpful as well.

Comment 2

[Michael Froman [:mjf]]

Also, does this happen when between Firefox and Firefox? Does it happen when the browsers are not on the same machine?

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Here's a profile of it happening:
https://share.firefox.dev/3rGi6LT

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Attachment: aboutWebrtc.html from a little while later.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

It seems worse when it's between Firefox and Firefox and doesn't seem to make a difference whether the browsers are on the same machine or not.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jib, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Thanks Jeff, I'm not seeing anything concerning in the profile, but will cc others. Are you seeing this in release or nightly? 96 has a big libwebrtc update, so it would be useful to learn if this is a regression in Firefox or in Meet itself.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

I believe I've seen it in both Release and Nightly

Comment 9

[Jeff Muizelaar [:jrmuizel]]

The profile of the WebrtcWorker threads shows that we stop decoding frames. Is it possible for us to add more information/markers about why that's happening?

Comment 10

[Paul Adenot (:padenot)]

I've seen that as well. pehrsons had a theory. My calls were not local, so I ended up adding more (network) markers to diagnose, but it's probably safe to say that it's not network related.

Comment 11

[Andreas Pehrson [:pehrsons]]

The profile I looked at from padenot showed gaps of 3.3s-3.5 during which we wouldn't decode any frames. That correlated with a 3 second timeout that triggered a keyframe request to be sent to the remote side. We didn't however figure out why frames ended up undecodable, causing the timeout to set off.

However in the profile in comment 3 things do seem a bit slow more than anything. The biggest gaps seem to be 100ms to 200ms long.

If things are slow I could imagine it being load related, but encoding is chugging along fine so I would guess this is not the case.

Paul's and Jeff's cases seem different. But I think for both cases the way forward is to have some network markers with seq numbers, so we can try to at least rule the network (or the remote peer) out.

Also markers wherever we (well, libwebrtc) handle errors would be good. As in places where we decide to skip decoding a number of frames, there should be a marker telling us the reason and the number of frames skipped. It might be harder to find full coverage of these places but it would certainly be the way forward.

Comment 12

[Andreas Pehrson [:pehrsons]]

There is also a "WebrtcCallThread #1" which I don't see in this profile. We might have to update the preset to catch that.