Opened 9 years ago
Closed 9 years ago
#4210 closed defect (invalid)
First HLS segment missing from the m3u8 file
Reported by: | ElGalloGringo | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | unspecified | Keywords: | hls |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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.
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.