[FFmpeg-trac] #9234(undetermined:new): Empty m3u8 after a Ctrl+C

FFmpeg trac at avcodec.org
Mon May 10 23:25:07 EEST 2021


#9234: Empty m3u8 after a Ctrl+C
-------------------------------------+-------------------------------------
             Reporter:  Gonzalo de   |                     Type:  defect
  Brito                              |
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:  hls m3u8     |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 == Summary of the bug: ==

 In ffmpeg version 4.4, if we kill ffmpeg during a m3u8 copy process,
 '''sometimes''' the output m3u8 file results completly empty. During the
 copy process a cat on the file exhibits the expected content, but after
 the Ctrl+C the file results completly empty.

 We couldn't reproduce this behaviour in ffmpeg v4.2.4, it seems to work
 perfectly fine in that version.



 == How to reproduce: ==

 The command we're running is the following:
 {{{
 ./ffmpeg_staging/ffmpeg -user_agent "Mozilla/5.0 (Windows NT 10.0; Win64;
 x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3554.0
 Safari/537.36" -i <url> -c copy -f hls -hls_list_size 86400 -hls_flags
 delete_segments+append_list+program_date_time+temp_file
 -hls_segment_filename $segment_path $m3u8_path
 }}}


 == FFmpeg versions & builds: ==

 This bug shows up in the following ffmpeg version, compiled from source:
 {{{
 ffmpeg version n4.4-10-g75c3969292 Copyright (c) 2000-2021 the FFmpeg
 developers
 built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04)
 configuration: --arch=amd64 --enable-gpl --enable-gnutls --enable-libx264
 --toolchain=hardened --disable-stripping
 libavutil      56. 70.100 / 56. 70.100
 libavcodec     58.134.100 / 58.134.100
 libavformat    58. 76.100 / 58. 76.100
 libavdevice    58. 13.100 / 58. 13.100
 libavfilter     7.110.100 /  7.110.100
 libswscale      5.  9.100 /  5.  9.100
 libswresample   3.  9.100 /  3.  9.100
 libpostproc    55.  9.100 / 55.  9.100
 }}}

 We '''CAN'T''' reproduce this bug (works perfectly fine) in the following
 ffmpeg version, also compiled from source:

 {{{
 ffmpeg version 4.2.4 Copyright (c) 2000-2020 the FFmpeg developers
 built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04)
 configuration: --arch=amd64 --enable-gpl --enable-gnutls --enable-libx264
 --toolchain=hardened --disable-stripping
 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
 libpostproc    55.  5.100 / 55.  5.100
 }}}

 Os: Ubuntu 20.04

 If you need any further information, please ask me.
 Best regards,
 Gonzalo.-
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9234>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list