From 2bd21a6f4063072468d6d8e9153d073efcfbc705 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Sebastian=20Dr=C3=B6ge?= Date: Thu, 7 Sep 2023 17:23:37 +0300 Subject: [PATCH] rtpjitterbuffer: Avoid integer overflow in max saveable packets calculation with negative offset The timestamp offset can be negative, and it can be a bigger negative number than the latency introduced by the rtpjitterbuffer so the overall timeout offset can be negative. Using the negative offset for calculating how many packets can still arrive in time when encountering a lost packet in an equidistant stream would then overflow and instead of considering fewer packets lost a lot more packets are considered lost. Part-of: --- .../gst-plugins-good/gst/rtpmanager/gstrtpjitterbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/subprojects/gst-plugins-good/gst/rtpmanager/gstrtpjitterbuffer.c b/subprojects/gst-plugins-good/gst/rtpmanager/gstrtpjitterbuffer.c index 063e39b9f7..2cf4ba9274 100644 --- a/subprojects/gst-plugins-good/gst/rtpmanager/gstrtpjitterbuffer.c +++ b/subprojects/gst-plugins-good/gst/rtpmanager/gstrtpjitterbuffer.c @@ -2669,7 +2669,7 @@ gst_rtp_jitter_buffer_handle_missing_packets (GstRtpJitterBuffer * jitterbuffer, /* based on the estimated packet duration, we can figure out how many packets we could possibly save */ - if (est_pkt_duration) + if (est_pkt_duration && offset > 0) max_saveable_packets = offset / est_pkt_duration; /* and say that the amount of lost packet is the sequence-number -- 2.34.1