HLS-5: PR#6 FFMPEG will be called only once



Issue Information

Issue Type: Pull Request
 
Priority: Major
Status: Closed

Reported By:
Ben Tasker
Assigned To:
Ben Tasker
Project: HLS Stream Creator (HLS)
Resolution: Merged (2015-06-10 23:34:54)

Created: 2015-06-10 23:32:28
Time Spent Working


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 Links

Pull Request #6
Toggle State Changes

Activity


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.
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
-segment_list_flags +live

Other than that, looks good, so merging.
Merged 9 June 2015
btasker changed status from 'Open' to 'Resolved'
btasker added 'Merged' to resolution
btasker changed status from 'Resolved' to 'Closed'
Raised HLS-8 for implementation of the live flag.
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):
#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

The target duration of 17 comes from a segment further down the manifest
#EXTINF:16.720000,
test.fifo.avi_512_00098.ts

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.