You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The RFC for NACK talks about using heuristics to decide if it's worth resending RTP packets when receiving a NACK. For example, one can consider the age of the original packet and the known round trip time to make this decision.
The current implementation naively responds to all NACKs by sending every requested RTP packet. This is problematic as it can cause retransmissions to consume all available bandwidth and if the peer falls too far back it can mean media decoding ends up in a broken state.
A first step to improve this might be to introduce a configurable max elapsed time when NACKs are actioned e.g. in pseudo code:
// When handling incoming RTCP NACKs
for packet in feedback.requested_packets {
if packet_sent_at.elapsed() > max_nack_age {
// Don't send this packet and discard it from buffers
} else {
// resend requested packet
}
}
The text was updated successfully, but these errors were encountered:
The RFC for NACK talks about using heuristics to decide if it's worth resending RTP packets when receiving a NACK. For example, one can consider the age of the original packet and the known round trip time to make this decision.
The current implementation naively responds to all NACKs by sending every requested RTP packet. This is problematic as it can cause retransmissions to consume all available bandwidth and if the peer falls too far back it can mean media decoding ends up in a broken state.
A first step to improve this might be to introduce a configurable max elapsed time when NACKs are actioned e.g. in pseudo code:
The text was updated successfully, but these errors were encountered: