diff options
| author | Jonathan Baudanza <jon@jonb.org> | 2024-09-04 17:06:15 +0900 |
|---|---|---|
| committer | Anton Khirnov <anton@khirnov.net> | 2024-09-23 17:08:33 +0200 |
| commit | 6b3f9c2e92ba1973de031554c6929a8eace3c87c (patch) | |
| tree | d5e45815594b6277053d54552684c6699aaa5f13 | |
| parent | 660e7e6a0ef0981c968e95d192b1ef094dbc53ad (diff) | |
| download | ffmpeg-6b3f9c2e92ba1973de031554c6929a8eace3c87c.tar.gz | |
avformat/rtpdec: fix integer overflow in start_time_realtime calculation
I encountered this problem with NTP timestamps that are extremely old,
like from January, 1990.
Although RFC3550 suggests that the timestamps in the RTCP packets use
the actual wallclock, some implementations use other clocks, such as
the CLOCK_MONOTONIC on linux.
I'm my case, I'm dealing with packets from mediasoup.
Without this patch, start_time_realtime shows up in the distance future
instead of around Jan 1900.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
| -rw-r--r-- | libavformat/rtsp.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c index d8f45cf8d5..c48fa26d90 100644 --- a/libavformat/rtsp.c +++ b/libavformat/rtsp.c @@ -2320,7 +2320,7 @@ redo: } // Make real NTP start time available in AVFormatContext if (s->start_time_realtime == AV_NOPTS_VALUE) { - s->start_time_realtime = av_rescale (rtpctx->first_rtcp_ntp_time - (NTP_OFFSET << 32), 1000000, 1LL << 32); + s->start_time_realtime = av_rescale (rtpctx->first_rtcp_ntp_time, 1000000, 1LL << 32) - NTP_OFFSET_US; if (rtpctx->st) { s->start_time_realtime -= av_rescale_q (rtpctx->rtcp_ts_offset, rtpctx->st->time_base, AV_TIME_BASE_Q); |