[FFmpeg-user] HLS program-date-time drifts

Wed Jan 24 23:19:29 EET 2018

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 <ffmpeg-user-bounces at ffmpeg.org> on behalf of Carl Eugen Hoyos <ceffmpeg at gmail.com>
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 <chiszp at hotmail.com>:
> 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
ffmpeg-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".