First HLS segment missing from the m3u8 file

[ElGalloGringo]

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.

[ElGalloGringo]

I closed this, as I am an idiot. Too bad there isn't an "Idiot reporter" option in that dropdown.

The problem was that I had never seen the "-hls_list_size" option in any of the examples I had been following and we only occasionally had videos longer than 5 segments, and never more than 6. I thought it was just always chopping the first segment.