start_time overflow after 95379 seconds

[Alex Kapustin]

Summary of the bug: looks like it's not possible to have start_time after 95379. It resets.
How to reproduce:

ffmpeg -y -fflags nobuffer \
    -v 9 -loglevel 99 \
    -rtsp_transport tcp \
    -i 'rtsp://login:pass@host:554/cam/realmonitor?channel=9&subtype=1' \
    -use_wallclock_as_timestamps 1 \
    -reset_timestamps 1 \
    -avoid_negative_ts 1 \
    -vcodec copy \
    -movflags frag_keyframe+empty_moov+genpts+discardcorrupted \
    -hls_flags append_list \
    -f hls \
    -segment_list_flags live \
    -output_ts_offset 95379 \
    -hls_time 1 \
    -hls_list_size 3 \
    -hls_segment_filename ./v9/%06d.ts ./v9/index.m3u8

Wait 10 seconds and interrupt command.

Then:

$ ffprobe -v error -show_entries format=start_time,duration -of default=noprint_wrappers=1:nokey=1 000000.ts 
95383.420000
1.860011

$ ffprobe -v error -show_entries format=start_time,duration,start_pts -of default=noprint_wrappers=1:nokey=1 000001.ts 
-58.297689  <- overflow
1.860011


$ ffmpeg version
ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 13.2.1 (GCC) 20230801
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-version3 --enable-vulkan
  libavutil      58. 29.100 / 58. 29.100
  libavcodec     60. 31.102 / 60. 31.102
  libavformat    60. 16.100 / 60. 16.100
  libavdevice    60.  3.100 / 60.  3.100
  libavfilter     9. 12.100 /  9. 12.100
  libswscale      7.  5.100 /  7.  5.100
  libswresample   4. 12.100 /  4. 12.100
  libpostproc    57.  3.100 / 57.  3.100
[AVFormatContext @ 0x5dfd110c9140] Unable to choose an output format for 'version'; use a standard extension for the filename or specify the format manually.
[out#0 @ 0x5dfd110c9040] Error initializing the muxer for version: Invalid argument
Error opening output file version.
Error opening output files: Invalid argument

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[Gyan]

Not a bug.

The MPEG-TS format used here to store the HLS segments has 33 bits* to store the timestamp, so that leads to a maximum timestamp of ~95443 seconds. The timestamps roll over upon reaching that point. FFmpeg, at present, has the ability to handle one such rollover. As part of its handling, it prerolls timestamps within 60s of the limit to a negative timestamp. This is later handled by ffmpeg (not ffprobe) for monotonic timestamps.

*technically 48 but the extra 15 are used for subdividing the main timestamp.