PR #22449 opened by Nariman-Sayed URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22449 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22449.patch
According to RFC 3550 section 6.4.1, the cumulative number of packets lost can be negative if duplicate packets are received, causing the received count to exceed the expected count. In this case the lost value must be clamped to zero instead of wrapping around as an unsigned integer. Signed-off-by: Nariman-Sayed <[email protected]> >From c5e8a22f5608273be98ae268e72e97e0ae6825ec Mon Sep 17 00:00:00 2001 From: Nariman-Sayed <[email protected]> Date: Mon, 9 Mar 2026 04:11:28 +0200 Subject: [PATCH] avformat/rtpdec: fix negative packet loss count in RTCP RR According to RFC 3550 section 6.4.1, the cumulative number of packets lost can be negative if duplicate packets are received, causing the received count to exceed the expected count. In this case the lost value must be clamped to zero instead of wrapping around as an unsigned integer. Signed-off-by: Nariman-Sayed <[email protected]> --- libavformat/rtpdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c index 5872c0f59c..eac91b07f7 100644 --- a/libavformat/rtpdec.c +++ b/libavformat/rtpdec.c @@ -355,7 +355,7 @@ int ff_rtp_check_and_send_back_rr(RTPDemuxContext *s, URLContext *fd, // RFC 1889/p64 extended_max = stats->cycles + stats->max_seq; expected = extended_max - stats->base_seq; - lost = expected - stats->received; + lost = stats->received > expected ? 0 : expected - stats->received; lost = FFMIN(lost, 0xffffff); // clamp it since it's only 24 bits... expected_interval = expected - stats->expected_prior; stats->expected_prior = expected; -- 2.52.0 _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
