[meet.jit.si] Firefox presenter mode video stream stop

This following issue happen in my own deployment whit latest stable, but also on meet.jit.si

When I do plain screen sharing with Firefox, everything is fine. But when I turn my camera on to start presenter mode, then, after a few seconds, the other participant can not see my video stream anymore, just my avatar with initial. It’s not systematic but I can reproduce it about one time out of five on meet.jit.si.

When the video stop, this kind of log appear in the console:

2021-08-25T06:33:29.660Z [modules/RTC/JitsiRemoteTrack.js] <h._onTrackMute>:  "onmute" event(1629873209660): RemoteTrack[userID: 4bde2acb, type: video, ssrc: 176938859, p2p: false, status: readyState: live, muted: true, enabled: true]
Logger.js:154 2021-08-25T06:33:29.660Z [modules/connectivity/ParticipantConnectionStatus.js] <g.onTrackRtcMuted>:  Detector track RTC muted: 4bde2acb 1629873209660
Logger.js:154 2021-08-25T06:33:39.663Z [modules/connectivity/ParticipantConnectionStatus.js] Set RTC mute timeout for: 4bde2acb                     of 10000 ms
Logger.js:154 2021-08-25T06:33:39.664Z [modules/connectivity/ParticipantConnectionStatus.js] <g.figureOutConnectionStatus>:  Figure out conn status for 4bde2acb, is video muted: false is active(jvb): true video track frozen: true p2p mode: false is in last N: true currentStatus => newStatus: active => interrupted
Logger.js:154 2021-08-25T06:33:39.664Z [modules/connectivity/ParticipantConnectionStatus.js] <g._changeConnectionStatus>:  Emit endpoint conn status(1629873219664) 4bde2acb: interrupted
Logger.js:154 2021-08-25T06:33:39.672Z [modules/UI/videolayout/LargeVideoManager.js] hover in 4bde2acb

I can not reproduce the issue with Chrome or Edge. One thing I noticed is that the bitrate with Firefox in presenter mode can get really high, sometimes more than 3500kpbs. However with Chrome, the bitrate stay around 2000kpbs

Chrome screensharing (bitrate 164kbps): OK

Chrome presenter mode (bitrate2142kbps): OK

Firefox screensharing (bitrate 548kbps) OK

Firefox screenshare (bitrate 3115kpbs) FAIL

@arzar It appears that participants that don’t see the presenter share don’t have enough downlink b/w (or atleast that is what the bridge thinks based on its BWE calculations) for receiving the full 30 fps stream. The bridge tries to oversend for share but it only oversends up to 500 Kbps, i.e. if your available downlink is 2500 Kbps, the bridge will try to send screenshare as long as it bitrate is < 3000 Kbps. If the screenshare bitrate jumps above the value then it drops the stream all together.

Chrome stops sending the low resolution resolution layers when the client suspends those but Firefox doesn’t because of a missing implementation there. Mozilla folks are working on fixing this.
Ideally this shouldn’t be happening if you have enough downlink bandwidth on the downstream clients that are receiving the screenshare.

1676855 - Implement RTCRtpEncodingParameters.active for reference.

Thanks a lot! Unfortunately, looks like Firefox continue its proud tradition of implementing simulcast partially…

After reading your explanations, I found that the oversending limit can be tuned in the bridge, so I could “fix” my firefox + presenter mode issue by adding in jvb.conf:

cc {
  trust-bwe=true
  max-oversend-bitrate=3000 kbps
}

But it feels a bit silly :sweat_smile: Is there any possible really bad side effects of letting the bridge oversend that much?