> On 7 Feb 2025, at 17:15, Sean Phelan via ffmpeg-user <ffmpeg-user@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 _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
