From 2364173cedda65030a8a5f2110416387deb0083e Mon Sep 17 00:00:00 2001 From: cnderrauber Date: Fri, 26 Jul 2024 09:52:44 +0800 Subject: [PATCH] Fix our-of-order twcc fb cause by rtx blocked Fix #2830. The TrackRemote.Read could block in readRTP if the buffer is empty then rtx packets arrival before next media rtp packet will be readed after the next media rtp packet and cause out-of-order fb and mess up remote peer's bandwidth estimation. --- rtpreceiver.go | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/rtpreceiver.go b/rtpreceiver.go index ea3dddc0e0b..28d72246da3 100644 --- a/rtpreceiver.go +++ b/rtpreceiver.go @@ -424,7 +424,7 @@ func (r *RTPReceiver) receiveForRtx(ssrc SSRC, rsid string, streamInfo *intercep track.repairInterceptor = rtpInterceptor track.repairRtcpReadStream = rtcpReadStream track.repairRtcpInterceptor = rtcpInterceptor - track.repairStreamChannel = make(chan rtxPacketWithAttributes) + track.repairStreamChannel = make(chan rtxPacketWithAttributes, 50) go func() { for { @@ -474,6 +474,8 @@ func (r *RTPReceiver) receiveForRtx(ssrc SSRC, rsid string, streamInfo *intercep r.rtxPool.Put(b) // nolint:staticcheck return case track.repairStreamChannel <- rtxPacketWithAttributes{pkt: b[:i-2], attributes: attributes, pool: &r.rtxPool}: + default: + // skip the RTX packet if the repair stream channel is full, could be blocked in the application's read loop } } }()