Overflow-2 in start_time_realtime calculation in rtsp.c

[IncrediBlame]

Related to ticket #11388.

Summary of the bug:
start_time_realtime calculation was changed in release/7.1 branch: ​​https://github.com/FFmpeg/FFmpeg/blob/bb85423142103d694d97bad1967bd3dc55440e71/libavformat/rtsp.c#L2323
Which introduced overflow for current dates (e.g. Feb 1, 2024).

Overflow was "fixed" here: ​https://github.com/FFmpeg/FFmpeg/commit/d72536008ac377164b00d214a2521e5ce604260b
Now same current dates are shown as year 1888, probably due to another overflow.

How to reproduce:

1. Add pprintf after calculation above.
2. Build ffmpeg.
2. Run
% ffmpeg -i some_rtsp_source -c copy abc.mp4
3. If rtsp source sends RTCP SR the code will eventually be hit, but sets the timestamp to some negative number.

Potential fix:

s->start_time_realtime = av_rescale (rtpctx->first_rtcp_ntp_time >> 2, 1000000, 1LL << 30) - NTP_OFFSET_US;

should stop any overflow.

[Jack Lau]

Hi,

I'm trying to reproduce this issue, but not meet any wrong result, the s->start_time_realtime is always right. Current date UTC time: 2025-04-06 11:58:27.173080 UTC printed very well

So can you give me more details about this overflow? can you provide the value of rtpctx->first_rtcp_ntp_time so i can test?

[IncrediBlame]

Replying to Jack Lau:

I cannot reproduce the bug on master anymore: it returns correct dates. I was testing on an older commit, but don't remember which one exactly. So I guess it was fixed somehow.

Case closed.