Due to lack of RR?

Find a tolerable max delay

Sending REMB can make the browser stop sending the better quality streams.
However, the browser may alternate between send and stop quickly, therefore cannot use a naive approach.
The server knows the bandwidth, therefore it does not need to rely solely on the browser to tell which streams might be active. However, this requires an accurate estimation.

After switching track quality, the sender often experiences momentary freezing of up to 3s. This is not present without timestamp offset and packet-drop. The solution was determined to be to update the timestamp even when the packet should be dropped.

The router might be buffering the packets and send all of them when the buffer is full. This results in periods where no packets are received, followed by all the packets arriving together. By the time they arrive, they might be too late and might be dropped.

Solution

If a batch finally arrives, instead of dropping them, play them at increased speed.

In Pion, there's a library called vnet for testing ICE/NAT traversal. We can set SettingEngine with vnet.Net so that the packet will be passed through vnet.Router. Inside the router, we can fork and change the processChunks() function to simulate our delay. For simulating our loss rate, we can add chunkFilter to vnet.Router.