Bugzilla

> what is causing the available bandwidth to decrease?

The bandwidth can't be decreasing because before the patch we observe the same code sending 4 videos at 30 fps without problem.

Also, at the end of comment 9, we've called `pc.removeTrack` *and* `transceiver.stop()` on all but one transceiver and renegotiated, so all transceivers but one have `transceiver.sender.track == null` so there should be no competition bandewidth, yet the remaining video is still transmitting at poor quality and low frame rate. There's also no simulcast being done, so why is simulcast logic kicking in?

> what is causing the available bandwidth to decrease?

The bandwidth can't be decreasing because before the patch we observe the same code sending 4 videos at 30 fps without problem.

Also, at the end of comment 9, we've called `pc.removeTrack` *and* `transceiver.stop()` on all but one transceiver and renegotiated, so all transceivers but one have `transceiver.sender.track == null` so there should be no competition for bandwidth, yet the remaining video is still transmitting at poor quality and low frame rate. There's also no simulcast being done, so why is simulcast logic kicking in?

> what is causing the available bandwidth to decrease?

The bandwidth can't be decreasing because before the patch we observe the same code sending 4 videos at 30 fps without problem.

Also, at the end of comment 9, we've called `pc.removeTrack` *and* `transceiver.stop()` on all but one transceiver, and renegotiated, so all transceivers but one have `transceiver.sender.track == null` so there should be no competition for bandwidth, yet the remaining video is still transmitting at poor quality and low frame rate. There's also no simulcast being done, so why is simulcast logic kicking in?

> what is causing the available bandwidth to decrease?

The bandwidth can't be decreasing because before the patch we observe the same code sending 4 videos at 30 fps without problem.

Also, at the end of comment 9, we've called `pc.removeTrack` *and* `transceiver.stop()` on all but one transceiver, and renegotiated. All transceivers but one have `transceiver.sender.track == null` at this point, so there's no real competition for actual bandwidth, yet the remaining video is still transmitting at poor quality and low frame rate. There's also no simulcast being done, so why is simulcast logic kicking in?