From 021c271a926415a05ffd6cbe08f44d1ed65dcf4f 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 abd2dff969b..8b18ff2e51e 100644 --- a/rtpreceiver.go +++ b/rtpreceiver.go @@ -433,7 +433,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 { @@ -483,6 +483,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 } } }()