[FFmpeg-trac] #9333(undetermined:new): ffmpeg creating mpeg-dash chunk files too slowly resulting in 404 errors

FFmpeg trac at avcodec.org
Sat Jul 17 08:17:29 EEST 2021

#9333: ffmpeg creating mpeg-dash chunk files too slowly resulting in 404 errors
             Reporter:  Danny        |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
 I have a hardware encoder feeding FFmpeg to create a MPEG-DASH Low Latency
 stream. It works well for a while, but after letting FFmpeg run for a
 while and reloading the page there are many 404 errors.

 When that happens, the `dash.js` player tries to fetch the segment file on
 the "live edge" but the file has not been created yet by FFmpeg. For
 example, after running for 20-30 minutes and loading the web page player,
 debug code in the web server shows:

     2021-07-16 16:46:30.64 : GET REQUEST : /data/ott/chunk-
     2021-07-16 16:46:30.67 : NOT FOUND. Latest files on filesystem:

 So you can see the browser requested chunk 702 but the latest on the
 server is (part of) 699.  With 2 second chunks, that is 3-5 seconds of
 content not yet available.

 To analyze, I modified FFmpeg's `dashenc.c` to add a timestamp every time
 a file is opened which displays like:

     [dash @ 0x9b17c0] 21:48:52.935 1626443332.935  : dashenc_io_open() -
 opened /data/ott/chunk-stream0-00060.m4s.tmp

 And loaded the timestamps into Excel.

 Despite a segment duration of 2.000 seconds, the average time between file
 opens is 2.011 seconds.  Over two hours this accumulated to a **45
 second** difference between the calculated live edge and the latest file
 on the server.

 The HW encoder is set to 25 fps and a GOP size of 5.  I've confirmed both
 by analyzing the H.264 NALUs output by the HW encoder.

 Is this a bug in FFmpeg or can I avoid this problem by adjusting the
 settings of either the HW encoder and/or FFmpeg options?


     FFmpeg: Version 4.4
     Centos 8
     Apache 2.4.37

 *FFmpeg command line (pipe is fed by process reading HW encoder)*

     ffmpeg -re -loglevel verbose -an -f h264 -i pipe:17 -c:v copy \
     -f dash -dash_segment_type mp4 -b:v 1000000 -seg_duration 2.000000 \
     -frag_type duration -frag_duration 0.200000 -target_latency 1 \
     -window_size 10 -extra_window_size 5 -remove_at_exit 1 -streaming 1 \
     -ldash 1 -use_template 1 -use_timeline 0 -write_prft 1 -avioflags
 direct \
     -fflags +nobuffer+flush_packets -format_options movflags=+cmaf \
     -utc_timing_url /web/be/time.php /data/ott/master.mpd

 *Modified `dash_io_open()` from dashenc.c*

     static int
     dashenc_io_open(AVFormatContext *s, AVIOContext **pb, char *filename,
 AVDictionary **options)
         DASHContext *c = s->priv_data;
         int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
         int err = AVERROR_MUXER_NOT_FOUND;
         if (!*pb || !http_base_proto || !c->http_persistent)
                 err = s->io_open(s, pb, filename, AVIO_FLAG_WRITE,

                 // My Debug
                     char buf[20], milli[60];
                     struct timeb tp;

                     ftime(&tp); // sec + ms
                     struct tm *tmInfo = localtime(&tp.time);

                     // 2020-05-15 21:15:12.123
                         strftime(buf, sizeof(buf), "%H:%M:%S", tmInfo);
                         snprintf(milli, 59, "%s.%03d %d.%03d ", buf,
 tp.millitm, tp.time, tp.millitm);

                         av_log(s, AV_LOG_INFO, "%s : dashenc_io_open() -
 opened %s\n", milli, filename);
         return err;
Ticket URL: <https://trac.ffmpeg.org/ticket/9333>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list