[FFmpeg-user] HLS program-date-time drifts
Carl Eugen Hoyos
ceffmpeg at gmail.com
Wed Jan 24 02:16:06 EET 2018
2018-01-24 1:14 GMT+01:00 Chris Hiszpanski <chiszp at hotmail.com>:
> I am using the HLS plugin, which is generating a .m3u8 playlist and its corresponding MPEG-2 transport stream segments:
> I'm noticing that if I leave this running for multiple days, the datetime in `EXT-X-PROGRAM-DATE-TIME` drifts from the actual clock time of the system, readily apparent because the segments are named in `YYYY_mm_DD__HH_MM_SS.ts` format (the .ts names match the system `date`). Here is how I am running ffmpeg (`ffmpeg version 3.4.1-static https://johnvansickle.com/ffmpeg/`):
> ffmpeg -re -r 36 -f h264 -i /var/run/my_named_pipe.h264 -vcodec copy -an -r 36 -use_localtime 1 -f hls -flags +cgop -g 25 -hls_time 6 -hls_list_size 5 -hls_start_number_source datetime -hls_allow_cache 1 -hls_flags program_date_time -hls_segment_filename http://localhost/%Y_%m_%d__%H_%M_%S.ts -method PUT http://localhost/myfeed.m3u8
> My hardware generates a 36 frames-per-second h.264 byte stream (baseline profile, with 25 frame group-of-pictures) and writes it to a named pipe, from which ffmpeg reads. Here is the m3u8 that shows the issue:
> Notice how the datetimes differ by almost a minute. These were the same value some 24 hours ago.
> Is this a bug, or am I missing something?
Complete, uncut console output missing but since you are overwriting
input timestamps, I don't think the report is valid. (How likely is it that
your hardware provides *exactly* 36fps?)
More information about the ffmpeg-user