Hi Carl, Here is the uncut console output:
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 ffmpeg version 3.4.1-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2017 the FFmpeg developers built with gcc 6.4.0 (Debian 6.4.0-7) 20170920 configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gray --enable-libfribidi --enable-libass --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzimg libavutil 55. 78.100 / 55. 78.100 libavcodec 57.107.100 / 57.107.100 libavformat 57. 83.100 / 57. 83.100 libavdevice 57. 10.100 / 57. 10.100 libavfilter 6.107.100 / 6.107.100 libswscale 4. 8.100 / 4. 8.100 libswresample 2. 9.100 / 2. 9.100 libpostproc 54. 7.100 / 54. 7.100 Input #0, h264, from '/var/run/my_named_pipe.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (Constrained Baseline), yuv420p(progressive), 1280x960, 36 fps, 36 tbr, 1200k tbn, 72 tbc [hls @ 0x1ccdd450] Opening 'http://localhost/2018_01_24__13_04_32.ts' for writing Output #0, hls, to 'http://localhost/myfeed.m3u8': Metadata: encoder : Lavf57.83.100 Stream #0:0: Video: h264 (Constrained Baseline), yuv420p(progressive), 1280x960, q=2-31, 36 fps, 36 tbr, 90k tbn, 36 tbc Stream mapping: Stream #0:0 -> #0:0 (copy) Press [q] to stop, [?] for help [hls @ 0x1ccdd450] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly [hls @ 0x1ccdd450] Opening 'http://localhost/2018_01_24__13_04_38.ts' for writing [hls @ 0x1ccdd450] Cannot use rename on non file protocol, this may lead to races and temporary partial files [hls @ 0x1ccdd450] Opening 'http://localhost/2018_01_24__13_04_44.ts' for writing By overwriting the timestamp, do you mean the `-r 36` flag preceding `-f h264`? Without this, 25 fps were assumed and the EXTINF durations in the .m3u8 were incorrect, 8 or 9 seconds when the actual segments were between 5 and 6 seconds. Are you (and the warning about timestamps being unset) saying that the h264 byte stream needs to have timestamps? Should I be wrapping each NAL unit in a PES packet? Chris ________________________________ From: ffmpeg-user <[email protected]> on behalf of Carl Eugen Hoyos <[email protected]> Sent: Tuesday, January 23, 2018 4:16 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] HLS program-date-time drifts 2018-01-24 1:14 GMT+01:00 Chris Hiszpanski <[email protected]>: > Hello, > > 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: > > ```m3u8 > #EXT-X-VERSION:3 > #EXT-X-MEDIA-SEQUENCE:0 > #EXT-X-TARGETDURATION:7 > #EXT-X-PROGRAM-DATE-TIME:2018-01-23T15:03:35-08:00 > #EXTINF:6.250, > 2018_01_23__15_04_33.ts > #EXT-X-PROGRAM-DATE-TIME:2018-01-23T15:03:41.25-08:00 > #EXTINF:6.250, > 2018_01_23__15_04_39.ts > #EXT-X-PROGRAM-DATE-TIME:2018-01-23T15:03:47.5-08:00 > ... > ``` > > 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?) Carl Eugen _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
