[FFmpeg-user] restarting ffmpeg corrupts EXT-X-PROGRAM-DATE-TIME ??

[Sean Phelan]

> On 7 Feb 2025, at 17:15, Sean Phelan via ffmpeg-user <ffmpeg-user at ffmpeg.org> wrote:
> 
> I have an ffmpeg instance reading an rtsp stream from a camera and recording two HLS streams (lo and hi b/w).
> 
> The HLS streams include EXT-X-PROGRAM-DATE-TIME, which the HLS client uses to jump to precise times in the recordings.
> 
> ffmpeg is restarted at midnight with a new destination directory, so one directory per day.  So the EXT-X-PROGRAM-DATE-TIME timestamps normally start at ...T00:00:00.000+0000
> 
> If  ffmpeg has to restart during the day, ie for maintenance of camera, server, network, etc. then I add the HLS_FLAGS "append_list" and "discont_start" so that the file sequence numbers continue and do not restart (which would delete previously recorded video).
> 
> When these restarts happen ffmpeg continues to append to the .m3u8 file and add .ts files with incremented sequence numbers. However, it also appears to overwrite the timestamps.  with incorrect ones.  If I restart at 9:00 then when the .m3u8 file is updated the (previously correct, 00:00:00.000) timestamp for the first video file of the day will be replaced by an (incorrect) 00:09:00.000 value.  All the EXT-X-PROGRAM-DATE-TIME timestamps are overwritten to show that the playlist started at 9:00.  In reality it started at 0:00 and recording was re-started at 9:00.
> 
> I suspect that this is some weird interaction of my HLS_FLAGS... unless somebody has another suggestions?
> 
> init string:
> ffmpeg -hide_banner -loglevel info -rtbufsize 20M -f rtsp -rtsp_transport tcp -stimeout 1000000 -probesize 10M \
>    -i rtsp://192.168.0.52:554?recv_buffer_size=2000000&timeout=15000000/cam/realmonitor?channel=1&subtype=0 -f hls \
>    -hls_playlist_type event -hls_flags program_date_time+independent_segments+append_list+discont_start \
>        -hls_time 5 -an -c:v h264_nvmpi -b:v 2M /mnt/vod/Gate/2025-02-07/0-.m3u8 \
>    -hls_playlist_type event -hls_flags program_date_time+independent_segments+append_list+discont_start \
>        -hls_time 5 -an -c:v h264_nvmpi -b:v 750K /mnt/vod/Gate/2025-02-07/lo/0-.m3u8
> 
> ffmpeg -version
> ffmpeg version 1076d31 Copyright (c) 2000-2023 the FFmpeg developers
> built with gcc 7 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)
> configuration: --enable-nvmpi
> libavutil      56. 31.100 / 56. 31.100
> libavcodec     58. 54.100 / 58. 54.100
> libavformat    58. 29.100 / 58. 29.100
> libavdevice    58.  8.100 / 58.  8.100
> libavfilter     7. 57.100 /  7. 57.100
> libswscale      5.  5.100 /  5.  5.100
> libswresample   3.  5.100 /  3.  5.100
> 
> Any and all suggestions welcome, to investigate further and/or to fix!

OK; I've made progress and am testing a fix. After further research I found a detailed description of the problem, and fix, from 2020: https://trac.ffmpeg.org/ticket/8989

This led me to compile and install the latest ffmpeg 7.1.  After a couple of restarts the timestamps do not appear to have been messed with. More tests needed, but I'm optimistic.

Cheers
Sean