From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 6C0794C7CC for ; Sun, 8 Jun 2025 20:09:25 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 2175F68C551; Sun, 8 Jun 2025 23:09:21 +0300 (EEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 84FFB68B148 for ; Sun, 8 Jun 2025 23:09:14 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id AA28942E77 for ; Sun, 8 Jun 2025 20:09:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1749413353; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dTTE1C1Fa+lCA0AWEkMOxBfkG7KsvxmMulYVkw+k+sY=; b=OEkPavoL4ALHEAsPiYOoy44S25gWc8klZflG8q99S9uyuDkD12dRxAG0yd85g2EeWnyUtJ f+u3cHBcDzaumB0wPSZWe9luZFfvRLqN0J1V4L0WR7FkQpnqV2IhHlEtfwQLRDjEVGEtq1 Lz+tvBqwd7IEzbBs/RcSv1dUPRPG2OmoXFgfL0w13EYRzWBvslceJcLHfMVFq6Uz2o/jCM 8+8OD9y1QfoCm6YKyGjytdlDsMaAUJMTJQET+qQgDbMtsBXCoOA4kAAx5bG+4GA1mT1DuX nenjrFc7W8+Xg4ES6VVgEGyQRZ2I5BvXmRAAeexlQobnA3b/E6FExf19Q772UA== Date: Sun, 8 Jun 2025 22:09:12 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250608200912.GO29660@pb2> References: <20250607080619.87769-1-peron.clem@gmail.com> <20250607233305.GL29660@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-State: clean X-GND-Score: -85 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdekfeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdduhedmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeelkeeggfffiedufeejueffjeduhedttdduledtheevveevtdeiueelhfdtuedtkeenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH v2] rtpdec: Fix RTP timestamp wraparound in Producer Reference Time X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============4496610591309499751==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4496610591309499751== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dsXSI5/Eh9ST/wYr" Content-Disposition: inline --dsXSI5/Eh9ST/wYr Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 08, 2025 at 09:27:07AM +0200, Cl=C3=A9ment P=C3=A9ron wrote: > Hi, >=20 > On Sun, 8 Jun 2025 at 01:33, Michael Niedermayer = wrote: > > > > Hi > > > > On Sat, Jun 07, 2025 at 10:06:19AM +0200, Cl=C3=A9ment P=C3=A9ron wrote: > > > The rtp_set_prft() function incorrectly calculates the timestamp delta > > > when RTP timestamps wrap around the 32-bit boundary. The current code: > > > > > > delta_timestamp =3D (int64_t)timestamp - (int64_t)s->last_rtcp_ti= mestamp; > > > > > > treats both timestamps as large positive values, causing wraparound to > > > produce a large negative delta instead of the correct small positive = delta. > > > > > > For example, with a 90kHz video clock: > > > - last_rtcp_timestamp =3D 0xFFFFFF00 (near wraparound) > > > - timestamp =3D 0x00000100 (after wraparound) > > > - Current result: delta =E2=89=88 -4.3 billion ticks =E2=89=88 -47,72= 1 seconds > > > - Expected result: delta =E2=89=88 +512 ticks =E2=89=88 +0.006 seconds > > > > > > This causes prft->wallclock to jump backward by approximately: > > > - 90kHz video: ~47,721 seconds (~13.25 hours) > > > - 48kHz audio: ~89,478 seconds (~24.9 hours) > > > - 8kHz audio: ~536,871 seconds (~6.2 days) > > > > > > Fix by casting the subtraction result to int32_t, which correctly > > > handles wraparound through modular arithmetic: > > > > > > delta_timestamp =3D (int32_t)(timestamp - s->last_rtcp_timestamp); > > > > > > This ensures the delta is always in the range [-2^31, 2^31-1], making > > > wraparound produce the correct small positive values. > > > > > > Fixes timing jumps in applications that rely on Producer Reference Ti= me > > > for media synchronization. > > > > > > Signed-off-by: Cl=C3=A9ment P=C3=A9ron > > > --- > > > libavformat/rtpdec.c | 5 +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c > > > index 729bf83685..7664ab58bd 100644 > > > --- a/libavformat/rtpdec.c > > > +++ b/libavformat/rtpdec.c > > > @@ -633,7 +633,8 @@ void ff_rtp_parse_set_crypto(RTPDemuxContext *s, = const char *suite, > > > } > > > > > > static int rtp_set_prft(RTPDemuxContext *s, AVPacket *pkt, uint32_t = timestamp) { > > > - int64_t rtcp_time, delta_timestamp, delta_time; > > > + int64_t rtcp_time, delta_time; > > > + int32_t delta_timestamp; > > > > > > AVProducerReferenceTime *prft =3D > > > (AVProducerReferenceTime *) av_packet_new_side_data( > > > @@ -642,7 +643,7 @@ static int rtp_set_prft(RTPDemuxContext *s, AVPac= ket *pkt, uint32_t timestamp) { > > > return AVERROR(ENOMEM); > > > > > > rtcp_time =3D ff_parse_ntp_time(s->last_rtcp_ntp_time) - NTP_OFF= SET_US; > > > - delta_timestamp =3D (int64_t)timestamp - (int64_t)s->last_rtcp_t= imestamp; > > > + delta_timestamp =3D (int32_t)(timestamp - s->last_rtcp_timestamp= ); > > > delta_time =3D av_rescale_q(delta_timestamp, s->st->time_base, A= V_TIME_BASE_Q); > > > > > > prft->wallclock =3D rtcp_time + delta_time; > > > > will apply >=20 > Thank you >=20 > I found also another place where this rollover could be problematic >=20 > diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c > index 7664ab58bd..aa1ea46469 100644 > --- a/libavformat/rtpdec.c > +++ b/libavformat/rtpdec.c > @@ -670,10 +670,10 @@ static void finalize_packet(RTPDemuxContext *s, > AVPacket *pkt, uint32_t timestam >=20 > if (s->last_rtcp_ntp_time !=3D AV_NOPTS_VALUE && s->ic->nb_streams >= 1) { > int64_t addend; > - int delta_timestamp; > + int32_t delta_timestamp; >=20 > /* compute pts from timestamp with received ntp_time */ > - delta_timestamp =3D timestamp - s->last_rtcp_timestamp; > + delta_timestamp =3D (int32_t)(timestamp - s->last_rtcp_timestamp= ); > /* convert to the PTS timebase */ > addend =3D av_rescale(s->last_rtcp_ntp_time - s->first_rtcp_ntp_= time, > s->st->time_base.den, >=20 > But to be honest I don't have time to properly test it, but I could > send a patch with an RFT tag if you want. better to have a patch than no patch, also this only affects 64bit int systems. I would tend to apply this fix even if noone tests it. Or am i missing something ? Its just more correct after the patch thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The difference between a dictatorship and a democracy is that every 4 years the population together is allowed to provide 1 bit of input to the governm= ent. --dsXSI5/Eh9ST/wYr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaEXt5QAKCRBhHseHBAsP q6GGAJ4hspSAeH+r2PG8k2DhCLIz5OvVaACeN8MClHwppP/GitZyLj/NN49JV0Y= =H6I9 -----END PGP SIGNATURE----- --dsXSI5/Eh9ST/wYr-- --===============4496610591309499751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============4496610591309499751==--