########################################################################################## HLS-5: PR#6 FFMPEG will be called only once ########################################################################################## Issue Type: Pull Request ----------------------------------------------------------------------------------------- Issue Information ==================== Priority: Major Status: Closed Resolution: Merged (2015-06-10 23:34:54) Project: HLS Stream Creator (HLS) Reported By: btasker Assigned To: btasker Targeted for fix in version: - 1.0 Time Estimate: 0 minutes Time Logged: 0 minutes ----------------------------------------------------------------------------------------- Issue Description ================== Fairly major change to take advantage of _ffmpeg_'s _segment\_list_ parameter. Also added a few environment variables to allow finer control over ffmpeg ----------------------------------------------------------------------------------------- Issue Relations ================ - relates to HLS-8: Implement ability to tell FFMPEG the input is a linear stream - relates to HLS-19: Re-Asses Suitability of FFMPEGs HLS functionality - Pull Request #6 (https://github.com/bentasker/HLS-Stream-Creator/pull/6) ----------------------------------------------------------------------------------------- Activity ========== ----------------------------------------------------------------------------------------- 2015-06-10 23:34:00 btasker ----------------------------------------------------------------------------------------- Note that the Copyright statement also changed slightly in this PR - https://github.com/bentasker/HLS-Stream-Creator/pull/6/files - though I think it's only fair given the size of the change. ----------------------------------------------------------------------------------------- 2015-06-10 23:34:38 btasker ----------------------------------------------------------------------------------------- *Comment added on the PR* Last time I looked at the segment_list parameter, they were making a mess of m3u8's (from a HLS perspective), but does seem they've fixed that now. One thing we do lose is the ability to handle a live rather than a VoD stream. Not sure the script was being used for that anyway, but should simply be a case of having the user identify whether we need to pass the following to ffmpeg -- BEGIN SNIPPET -- -segment_list_flags +live -- END SNIPPET -- Other than that, looks good, so merging. ----------------------------------------------------------------------------------------- 2015-06-10 23:34:49 btasker ----------------------------------------------------------------------------------------- Merged 9 June 2015 ----------------------------------------------------------------------------------------- 2015-06-10 23:34:54 ----------------------------------------------------------------------------------------- btasker changed status from 'Open' to 'Resolved' ----------------------------------------------------------------------------------------- 2015-06-10 23:34:54 ----------------------------------------------------------------------------------------- btasker added 'Merged' to resolution ----------------------------------------------------------------------------------------- 2015-06-10 23:34:58 ----------------------------------------------------------------------------------------- btasker changed status from 'Resolved' to 'Closed' ----------------------------------------------------------------------------------------- 2015-06-11 12:12:17 btasker ----------------------------------------------------------------------------------------- Raised HLS-8 for implementation of the live flag. ----------------------------------------------------------------------------------------- 2015-06-16 17:33:14 btasker ----------------------------------------------------------------------------------------- Although letting _ffmpeg_ create the manifest is a cleaner implementation that earlier revisions, I'm not overly happy with the way in which _ffmpeg_ creates HLS. Because it seeks to the nearest keyframe, specifying a target segment duration gives rough results. For example, although the user may have specified a segment length of 10 seconds, _ffmpeg_ may well create 17 second segments if that's the nearest keyframe. It's not particularly clean, and gives a (IMO) messy looking m3u8 (the following specified a 10 second segment length): -- BEGIN SNIPPET -- #EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-ALLOW-CACHE:YES #EXT-X-TARGETDURATION:17 #EXTINF:10.400000, test.fifo.avi_512_00000.ts #EXTINF:9.760000, test.fifo.avi_512_00001.ts #EXTINF:10.160000, test.fifo.avi_512_00002.ts #EXTINF:9.920000, test.fifo.avi_512_00003.ts #EXTINF:12.920000, test.fifo.avi_512_00004.ts #EXTINF:7.080000, test.fifo.avi_512_00005.ts #EXTINF:12.360000, test.fifo.avi_512_00006.ts #EXTINF:9.480000, test.fifo.avi_512_00007.ts #EXTINF:8.840000, test.fifo.avi_512_00008.ts #EXTINF:10.360000, test.fifo.avi_512_00009.ts #EXTINF:10.120000, test.fifo.avi_512_00010.ts #EXTINF:10.240000, test.fifo.avi_512_00011.ts #EXTINF:10.120000, test.fifo.avi_512_00012.ts #EXTINF:9.280000, test.fifo.avi_512_00013.ts #EXTINF:11.400000, test.fifo.avi_512_00014.ts #EXTINF:8.400000, test.fifo.avi_512_00015.ts #EXTINF:10.080000, test.fifo.avi_512_00016.ts -- END SNIPPET -- The target duration of 17 comes from a segment further down the manifest -- BEGIN SNIPPET -- #EXTINF:16.720000, test.fifo.avi_512_00098.ts -- END SNIPPET -- Although it's expected that there'd be some variance, a segment being 67.2% longer in duration than intended isn't exactly great. I'm not sure it's worth reverting over, as merging this PR made it simpler to implement other functionality (such as support for ABR streams) but it's definitely pretty messy. Probably worth looking to see whether there are _ffmpeg_ flags we can pass to tidy this up a bit.