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?

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.

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

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

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.

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

For more information, please visit auto_nag documentation.

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.

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

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?

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.

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.

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