[FFmpeg-devel] [PATCH] avformat/rtpdec: fix integer overflow in start_time_realtime calculation

Jonathan Baudanza jon at jonb.org
Wed Sep 11 03:44:54 EEST 2024


Does anyone have any thoughts on this? This is a pretty small one-liner.

I also noticed that there is a ff_parse_ntp_time() in utils.c. Maybe this functionality should be consolidated in one place.

On Wed, Sep 4, 2024, at 5:06 PM, jon at jonb.org wrote:
> From: Jonathan Baudanza <jon at jonb.org>
> 
> 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.
> ---
> libavformat/rtsp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 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);
> -- 
> 2.41.0
> 
> 


More information about the ffmpeg-devel mailing list