rtpjitterbuffer: Avoid integer overflow in max saveable packets calculation with...

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: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5318>

diff --git a/subprojects/gst-plugins-good/gst/rtpmanager/gstrtpjitterbuffer.c b/subprojects/gst-plugins-good/gst/rtpmanager/gstrtpjitterbuffer.c
index 063e39b..2cf4ba9 100644 (file)
--- 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