[FFmpeg-trac] #4210(avformat:new): First HLS segment missing from the m3u8 file

[FFmpeg]

#4210: First HLS segment missing from the m3u8 file
-------------------------------------+-------------------------------------
             Reporter:               |                     Type:  defect
  ElGalloGringo                      |                 Priority:  normal
               Status:  new          |                  Version:
            Component:  avformat     |  unspecified
             Keywords:  hls          |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug: I have a process where I take an MP4 file generated on
 an iOS device (H264 Main 3.1), upload it to a server and then have a
 server script convert the videos to HLS. I do this is a two step process.
 I first convert the MP4 to single TS files at the various target bitrates
 with H264 Baseline 3.0 and second use the HLS segmenter to segment each TS
 file. I then make the master playlist from the individual qualities.

 The strangest thing is that it actually creates all the segments
 appropriately, it just isn't including the zero-th segment in the .m3u8
 file. Fore example, with the commands below, it results in a file called
 stream_110k0.ts, but the contents of the resultant m3u8 file is:
 {{{
 #EXTM3U
 #EXT-X-VERSION:3
 #EXT-X-TARGETDURATION:7
 #EXT-X-MEDIA-SEQUENCE:1
 #EXTINF:6.300000,
 stream_110k1.ts
 #EXTINF:6.200000,
 stream_110k2.ts
 #EXTINF:6.200000,
 stream_110k3.ts
 #EXTINF:5.800000,
 stream_110k4.ts
 #EXTINF:0.300000,
 stream_110k5.ts
 #EXT-X-ENDLIST
 }}}

 I have been looking through the code to see if I could see where the
 problem was occurring, and it looks like it might have something to do
 with whichever part of the code is calling hls_write_packet in hlsenc.c.
 The problem is that it looks like hls_write_packet corresponds to a plugin
 system where write_packet is defined as hls_write_packet and I haven't had
 the time to go back and try to sort out how that interface works. I think
 whatever is calling hls_write_packet is not calling this with the zero-th
 segment.

 How to reproduce:

 FIRST STEP
 {{{
 %/opt/pichme/bin/ffmpeg -y -i /tmp/37A10519-AB0B-
 4DBB-B654-0FE90A901B0D.mp420141227-16687-8hxt8t -c:v libx264 -preset
 veryslow -profile:v baseline -level 3.0 -mpegts_copyts 1 -b:v 110k
 -minrate 110k -maxrate 110k -bufsize 110k -r 10 -g 10 -pass 1 -passlogfile
 37A10519-AB0B-4DBB-B654-0FE90A901B0D_110k -c:a libfdk_aac -b:a 48k -f mp4
 /dev/null && /opt/pichme/bin/ffmpeg -y -i /tmp/37A10519-AB0B-
 4DBB-B654-0FE90A901B0D.mp420141227-16687-8hxt8t -c:v libx264 -preset
 veryslow -profile:v baseline -level 3.0 -mpegts_copyts 1 -b:v 110k
 -minrate 110k -maxrate 110k -bufsize 110k -r 10 -g 10 -pass 2 -passlogfile
 37A10519-AB0B-4DBB-B654-0FE90A901B0D_110k -c:a libfdk_aac -b:a 48k -vbsf
 h264_mp4toannexb /tmp/37A10519-AB0B-4DBB-B654-0FE90A901B0D_110k.ts
 ffmpeg version git-2014-11-13-5c805d6 Copyright (c) 2000-2014 the FFmpeg
 developers
   built on Nov 13 2014 20:31:40 with gcc 4.4.7 (GCC) 20120313 (Red Hat
 4.4.7-4)
 }}}

 SECOND STEP
 {{{
 %/opt/pichme/bin/ffmpeg -i /tmp/37A10519-AB0B-
 4DBB-B654-0FE90A901B0D_110k.ts -c copy -map 0 -mpegts_copyts 1 -f hls
 -hls_time 6  /tmp/37A10519-AB0B-4DBB-B654-0FE90A901B0D/stream_110k.m3u8
 ffmpeg version git-2014-11-13-5c805d6 Copyright (c) 2000-2014 the FFmpeg
 developers
   built on Nov 13 2014 20:31:40 with gcc 4.4.7 (GCC) 20120313 (Red Hat
 4.4.7-4)
 }}}

 If you need the actual MP4 file that is causing this, let me know and I
 will make it available.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4210>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker