1735951 - [jitsi] Disabling an outgoing track with simulcast continues to send

Status: UNCONFIRMED

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

Description

[Nils Ohlmeier [:drno]]

When the outgoing track for a sender is configured to do simulcast (with three resolutions in this case - not sure if that matters) and the enabled attribute gets set to 'false' Firefox continues to send RTP video packets instead of reducing the output to almost zero.

If RTX is negotiated for the track the outgoing traffic switches to sending RTX packets only. If not RTX is configured then the RTP PT is just the negotiated video codec.

The following page demonstrates the problem https://nils-ohlmeier.github.io/simulcast-playground/firefox-bug.html
The page turns on simulcast. And 30 seconds after connecting flips the enabled attribute to false. As you can see all the videos turn black as expected. The outgoing bitrate (plotted right next to the source video in the upper left corner) drops, but is far away from zero.

Comment 1

[Byron Campen [:bwc]]

So, I'm not totally sure what the spec says about setting enabled to false on a send track and the effects that should have on RTP, but we certainly do seem to be sending way more data than is reasonable for a stream of black frames. Same thing seems to happen with the libwebrtc update. The test-case does not seem to work on Chrome, so I cannot see what Chrome is doing in this scenario. I wonder if we get better behavior with replaceTrack(null)?

Comment 2

[Nils Ohlmeier [:drno]]

I did not mean to focus on the RTP side of things. Yes the expectation is to send black frames, with a reasonable low bandwidth usage. I haven't verified this, but is it a concern that this higher then expected network usage does influence the bandwidth estimation and therefore other streams from the conference might get turned off even though the user has already tried to save bandwidth by turning off his/her own video stream.

As a workaround we do remove the stream for now. But it obviously would be better if enabling and disabling simulcast enabled streams behave the same way as without simulcast (in sending black frames with low bandwidth usage).

Comment 3

[Jim Mathies [:jimm]]

Andreas, mind taking a look at this? Maybe the issue has been addressed, the bug was filed back in 2021.

Comment 4

[Andreas Pehrson [:pehrsons]]

For the sake of making rid-as-mid work I test on https://jsfiddle.net/pehrsons/fLcjn9tr/ instead. I set it up to do 3 layers VP8, "Split" layers, i.e. simulcast.

Then I disable the sent track in console by: document.getElementById("videoSource").srcObject.getTracks().forEach(t => t.enabled = false);

Monitoring the sent bitrate on about:webrtc shows that all layers encode black frames at 1fps. The lowest layer still shows ~235 packets/s sent at ~2Mbps. The other layers do ~1 packet/s.

The issue remains.

That said, this is probably bandwidth probing through RTX. Perhaps we can signal libwebrtc something to turn it down. I wonder what happens if we inactivate all the encodings per https://issues.webrtc.org/issues/42230757#comment21.

Comment 5

[Andreas Pehrson [:pehrsons]]

Inactivating the encodings make them stop sending packets entirely.

libwebrtc also offers periodic ALR bandwidth probing instead of the continuous padding we exhibit here. It's not enabled by default in Chromium and I'm not sure of the experiment state.

Comment 7

[Andreas Pehrson [:pehrsons]]

Note that the padding is up to the sum of the target bitrate of all layers.

We could also disable all layers but one when the source track is disabled. That should make it behave like for singlecast. The question is what happens when the track is enabled again.