I usually watch a Twitch stream on Tuesdays, and Larry, the person doing that one, is complaining that since January 18 (the first one he did after Jan 11, where it still was fine, but also where Firefox 96 was released) his video is blurry (low resolution) when using Firefox. On Chrome OTOH it works fine, i.e. the resolution is significantly higher.
He since tried and Firefox 97.0 is also low resolution while 91.5.1 ESR still works with higher resolution.

https://www.twitch.tv/videos/1291696774 (as long as it's available) has a good comparison where he started on Firefox 96.0.3 and about 48 minutes in switched to Chrome. (For later, https://www.youtube.com/watch?v=7n1FuKfQDrg is an archived portion of the Firefox stream and https://www.youtube.com/watch?v=-rFc0Kxkp5g from the Chrome part).

The issue is 100% reproducible for him, he is on a relatively recent Mac IIRC, definitely on MacOS though. He is using a service called "Restream" to go out to Facebook, YouTube and Twitch at the same time, streaming just his camera image.

The issue seems to be in how bandwidth constraints are being dealt with, as Chrome shows some phases of the image freezing but in general uses higher resolution and therefore "looks better".

OK, here's a speedtest from Larry: https://www.speedtest.net/result/12745307185

And he says "But as for the other … "about:webrtc… I browse to that address but don’t see any reports to grab or view. I have action buttons, but don't see any activity, or how/where to go see it."
How can he get the logs we want from this?

in addition, he found out that with ESR, while the video itself is better, the Restream service seems to hide some other features he'd like to use and which are there with Chrome and Firefox release (I guess they have some UA detection or similar for some features).

OK, here's a speedtest from Larry

The 22 Mbps uplink is likely the bottleneck, and not a lot for streaming. Chrome and pre-96 Firefox appear to do a better job with it.

Sidenote: Bug aside, something like Fios (which has upload/download parity) would be night and day here for your friend's streaming use case. Most (non-streaming) users only care about download, the target his current service seems aimed at. Just a friendly tip. We're still looking to fix the bug in Firefox of course!

"But as for the other … "about:webrtc… I browse to that address but don’t see any reports to grab or view.

He needs to open or ↻ refresh the about:webrtc page while he's streaming in the other tab, for "Session Statistics" to appear. He would then use the Save Page button at the top to save the page to a file (no need to use the other buttons).

in addition, he found out that with ESR, while the video itself is better

This is a good sign this is a regression. Marking as such.

the Restream service seems to hide some other features he'd like to use

ESR is missing some new feature perhaps. Downloading Firefox 95 might solve this if he wants to use Firefox, or use Chrome of course until we fix this.

Set release status flags based on info from the regressing bug 1654112

The issue is reproducible only when simulcasting is enabled. Right now it's disabled in Firefox 96 (so the issue will no longer appear), but it's possible to force simulcasting using that URL https://studio.restream.io/?simulcasting

WebRTC tab shows that all 3 layers of the video were negotiated as a simulcast, and the upper level even reports that 5mbps is constantly used, though, the image looks bad. Interestingly, 2 other layers almost do not report any data transfer which is odd since they should be active.

I also must highlight that it's not a badnwidth-related issue. The issue is reproducible both on the near-to-perfect connection and even in the local environment.

:jib, based on comment 4 this does not seem to be related to bandwidth and might affect more people/services which might affect our prioritization here.

Sorry for the late response. I've been out for a few days.

Thanks Serj for this link. I seem able to reproduce (on Fios) with a free account and "Enter studio" with my camera on (assuming this is all that's needed to reproduce full-speed upload):

• In nightly without ?simulcasting, about:webrtc reports an estimated "Send Bandwidth (bytes/sec)" of 18750,
• In nightly with ?simulcasting it's only 5000.
• in 95 with ?simulcasting it was 118454.
• In nightly with https://jsfiddle.net/jib1/yvg81otc/ which exercises a=simulcast:send 0;1;2 locally it's 729326.

In the 5000 case, the RTP stats confirm only the first SSRC is sending data, the other two stay at zero bps. This seems to match your report.

Comparing simulcast SDPs, the only significant difference I saw from 95 was this line is missing in nightly (which may be unrelated):

- a=rtcp:64447 IN IP4 172.18.0.3

Attached is the SDP from restream in nightly.

As a control, here's the SDP from the working fiddle in comment 7. Some notable differences (limitations in it don't let me easily test sendonly or different rid names unfortunately):

- a=sendonly
+ a=sendrecv
  ...
- a=rid:r2 send
- a=rid:r1 send
- a=rid:r0 send
+ a=rid:0 send
+ a=rid:1 send
+ a=rid:2 send
+ a=rtcp:56519 IN IP4 192.168.1.158
  ...
- a=simulcast:send r2;r1;r0
+ a=simulcast:send 0;1;2

The answer is significantly different of course, one being from mediasoup, the other faked locally, but some highlights:

- a=ice-lite
- a=msid-semantic:WMS *
+ a=setup:active
  ...
- a=recvonly
+ a=sendrecv
  ...
- a=rid:r2 recv
- a=rid:r1 recv
- a=rid:r0 recv
+ a=rid:0 recv
+ a=rid:1 recv
+ a=rid:2 recv
- a=rtcp-rsize
- a=setup:passive
- a=simulcast:recv r2;r1;r0
+ a=simulcast:recv 0;1;2

There's also no audio in my fiddle, but I doubt that's significant. Byron, any ideas?

So, I'm not sure if it is relevant, but I do not see transport-cc or remb in the remote answer, either with 95 or 99. I would expect bandwidth estimation to not be happening at all because of this (which will not work very well at all), but nevertheless our bandwidth seems to be capped artificially low. I wonder what libwebrtc is doing under the hood here.

Any idea what might be going on here? Are you aware of any bug in Firefox regarding answers without remb or transport-cc rtcp-fb, specifically when interoperating with mediasoup?

I wonder what libwebrtc is doing under the hood here.

Here's what's logged from here the first 10 seconds of connecting to https://studio.restream.io/?simulcasting for me:

★ /tmp $ grep pushback_target_bps jib.log.child-4.moz_log
2022-03-08 21:17:45.194967 UTC - [Child 23379: WebrtcWorker #1]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 9062 pushback_target_bps=300000 estimate_bps=300000
2022-03-08 21:17:46.898289 UTC - [Child 23379: WebrtcWorker #1]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 10766 pushback_target_bps=325000 estimate_bps=325000
2022-03-08 21:17:47.894751 UTC - [Child 23379: WebrtcWorker #3]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 11762 pushback_target_bps=352000 estimate_bps=352000
2022-03-08 21:17:48.098211 UTC - [Child 23379: WebrtcWorker #1]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 11966 pushback_target_bps=352000 estimate_bps=352000
2022-03-08 21:17:48.346821 UTC - [Child 23379: WebrtcWorker #4]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 12214 pushback_target_bps=281600 estimate_bps=281600
2022-03-08 21:17:49.349095 UTC - [Child 23379: WebrtcWorker #3]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 13216 pushback_target_bps=225280 estimate_bps=225280
2022-03-08 21:17:49.396279 UTC - [Child 23379: WebrtcWorker #4]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 13264 pushback_target_bps=225280 estimate_bps=225280
2022-03-08 21:17:49.646518 UTC - [Child 23379: WebrtcWorker #2]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 13514 pushback_target_bps=102090 estimate_bps=102090
2022-03-08 21:17:50.371284 UTC - [Child 23379: WebrtcWorker #2]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 14239 pushback_target_bps=81672 estimate_bps=81672
2022-03-08 21:17:51.397406 UTC - [Child 23379: WebrtcWorker #1]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 15265 pushback_target_bps=65338 estimate_bps=65338
2022-03-08 21:17:51.796066 UTC - [Child 23379: WebrtcWorker #3]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 15663 pushback_target_bps=65338 estimate_bps=65338
2022-03-08 21:17:52.422371 UTC - [Child 23379: WebrtcWorker #1]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 16290 pushback_target_bps=52270 estimate_bps=52270
2022-03-08 21:17:53.445696 UTC - [Child 23379: WebrtcWorker #1]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 17313 pushback_target_bps=41816 estimate_bps=41816
2022-03-08 21:17:54.448245 UTC - [Child 23379: WebrtcWorker #2]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 18315 pushback_target_bps=40000 estimate_bps=40000
2022-03-08 21:17:55.473244 UTC - [Child 23379: WebrtcWorker #4]: D/webrtc_trace (goog_cc_network_control.cc:687): bwe 19340 pushback_target_bps=40000 estimate_bps=40000
★ /tmp $ 

From here on, the bwe timestamp keeps increasing but the two values remain stuck at pushback_target_bps=40000 estimate_bps=40000 forever (40000 bit/sec == 5000 bytes/sec)

- a=simulcast:recv r2;r1;r0
+ a=simulcast:recv 0;1;2

Interestingly, the order of layers is different. Could it be related? I remember the order of RtpEncodings in RtpSender was always for some reason reversed in Firefox on contrary to Chrome. I've tried to not reverse encodings in FF 96, but it didn't help.

(In reply to Serj Lavrin from comment #14)

I've tried to not reverse encodings in FF 96, but it didn't help.

Alas, I tried reversing it as well in https://jsfiddle.net/jib1/mxtesu4b/13/ and that still worked.

RtpEncodings in RtpSender was always for some reason reversed in Firefox on contrary to Chrome.

That's odd. The fiddles above produce the same order for me in both Chrome and Firefox.

The issue is reproducible only if transport-cc is disabled (removed from the SDP) and goog-remb is used instead. In our case, transport-cc was disabled because of the https://bugzilla.mozilla.org/show_bug.cgi?id=1690832. Re-enabling it fixed the issue.

Since goog-remb is considered to be deprecated, not sure whether it is worth exploring why REMB is broken in Firefox.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:mjf, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

According to comment 16, this issue appears to be resolved after re-enabling transport-cc. I'm marking resolved/inactive, but we can re-open if the issue resumes.

I what version (or by what bug) was transport-cc re-enabled? I'd like to check back with Larry, who i filed this issue for originally, if it's fixed for him.

Don't remember what version it was. It was a stable release, so it must be Firefox 100.

Note though that when goog-remb is used, it's still broken. Not sure whether Firefox has statistics on whether anyone still uses it with a simulcasting. If people do use it though, the experience would be quite bad for them.