1637636 - Enabling transport-cc breaks simulcast

Status: RESOLVED FIXED

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

Description

[Dan Minor [:dminor]]

Testing with Mozregression on https://fippo.github.io/simulcast-playground/firefox, gives https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=eef42d39ab68bc9b4f1e25194e1dc9d1fa298f9d&tochange=065c7a87c66dca9a73ff989fc0e8f48827506e99, which is Bug 1625803.

Comment 1

[Dan Minor [:dminor]]

It looks like only one of the three streams is being sent.

Comment 2

[Dan Minor [:dminor]]

Does not reproduce if I comment out the call to receive_side_cc_.OnReceivedPacket() at: https://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/call/call.cc#1467-1469.

Initial guess is that only one stream is being allocated bandwidth.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 4

[Dan Minor [:dminor]]

Try job here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=13569adfd40519aad94a931a932f023737d8412e

Comment 5

[Dan Minor [:dminor]]

Filed Bug 1637971 to see if we can improve testing around this.

Comment 6

[Dan Minor [:dminor]]

Attachment: Bug 1637636 - Add callback to Call::OnSentPacket in conduits; r=ng!

In order for the SendSideCongestionController to work properly, it needs the
timestamp at which the packets were sent. This is set by calling
Call::OnSentPacket when a packet is sent. Without the sent timestamp, it drops
the estimated available bandwidth so low that only one simulcast stream will
be allocated any bandwidth.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/731d0c1c3adf
Add callback to Call::OnSentPacket in conduits; r=ng

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/731d0c1c3adf