I joined a Jitsi call with this try build https://treeherder.mozilla.org/jobs?repo=try&revision=4e1656a88e5ba5916ca5eeb0e6d22db7fb6e5728 with the libwebrtc update. Since Jitsi has transport-cc disabled for Firefox right now I assume that REMB was in use for bandwidth estimation.

Initially I saw the video of all other participants. But within a few seconds the Jitsi SFU turned off the video from all other participants due to low bandwidth.
When I opened about:webrtc to look at the bandwidth numbers I noticed that all values appeared to be frozen, see attached screen shot.

I then joined the same call with Fx 92 Nightly and video was working fine for all participants.

Do we have any updates here? We are experiencing the same issue. It's worse once we get more participants joining.

csantos, can check if this is broken in Chrome 86. That's the version of Chrome that corresponds to the version of libwebrtc that we're using.

Michael, is this something that might be fixed in the newer version of libwebrtc you're tracking? If you think so, would you be able to provide a try link for folks here to test?

It might be - I'm not paying specific attention to individual commit content beyond fixing conflicts or build issues so I can't say for certain. As we push updates to the elm tree, builds/tests are run automatically. They can be found here: https://treeherder.mozilla.org/jobs?repo=elm

@jrmuizel It's not reproducible in Chrome 86. I also verified and this is still reproducible in Firefox 102. I attached a screenshot similar to OP.

For context, we have at least 25 participants manually turning off/on video tracks. And at some point, our SFU turns off the video from all other participants due to low bandwidth. I ran chrome at the same time on the same machine and the issue is not happening on chrome (version 86 and 103).

This might not be related to libwebrtc update but I'm not 100% sure. Please let me know if I should submit a separate bug and if you need more information.