jira-projects/HLS#1: HLS-12: Auto-delete expired segments in live streams

Previously HLS-12

The current implementation will re-use segment names after 2 manifest lengths, so (assuming the manifest contains 3 segments at any given time), numbering will be

seg0, seg1, seg2, seg3, seg4, seg5, seg0, seg1.....etc

Which, for a directly served linear stream is fine.

However, if there's a downstream cache (for example a CDN), then the max-age header would need to be carefully set, otherwise the second request for seg0 would likely lead to a cached copy of the original being served.

There's also an odd, but real-world use-case, where a stream is linear whilst it's first airing, but later becomes VoD (for example, a football match being streamed live, and then made available as catchup afterwards).

The most efficient means of doing this is to use a linear manifest whilst streaming live, and then later republish the manifest with all segments listed to make the stream available as Vod. Because the segment names/paths are unchanged, downstream caches will likely have most or all of the segments in cache (assuming a suitable max-age) already, lowering the impact on the origin and improving delivery times to the end-user.

That use-case isn't possible with the current implementation though, because we're re-using segment filenames, so that needs to become an option (even if it's the default behaviour). Once that's done, it still won't be directly achievable (as the VoD manifest would need to be manually generated), but would at least be feasible.

So, there are 2 tasks left within this issue

• Make segment number wrapping a togglable option
• Fork single bitrate encodes (see earlier comment)
• When wrapping is disabled, there should be an option to delete old segments