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
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):
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.
Activity
2015-06-10 23:34:00
2015-06-10 23:34:38
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
Other than that, looks good, so merging.
2015-06-10 23:34:49
2015-06-10 23:34:54
2015-06-10 23:34:54
2015-06-10 23:34:58
2015-06-11 12:12:17
2015-06-16 17:33:14
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):
The target duration of 17 comes from a segment further down the manifest
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.