jira-projects/HLS#4: HLS-26: Ability to override WRAP_POINT

Was previously HLS-26

When creating a live stream, the point at which to start re-using segment names is currently automatically calculated on line 343 and set as WRAP_POINT.

It only fires if the script has been told to limit the number of segments in the manifest (by way of the -c flag)

if [ "$LIVE_SEGMENT_COUNT" -gt 0 ]
then
WRAP_POINT=$(($LIVE_SEGMENT_COUNT * 2)) # Wrap the segment numbering after 2 manifest lengths - prevents disks from filling
FFMPEG_ADDITIONAL+=" -segment_list_size $LIVE_SEGMENT_COUNT -segment_wrap $WRAP_POINT"
fi

When WRAP_POINT is reached, segment filenames will reset, so we might see

• stream_00001.ts
• stream_00002.ts
• stream_00003.ts
• stream_00004.ts
• stream_00005.ts
• stream_00006.ts
• stream_00001.ts

For standard latency HLS streams this will generally be fine, however, for ultra-low latency HLS streams we risk recycling names before the TTL on any downstream HTTP caches has expired. Due to the very short segment length you risk increasing cache churn if the TTL is lowered too much (and also meaning that if a player gets a bit behind, it may well start skipping)

So, I'd like to add a flag (-w) that allows WRAP_POINT to be explicitly defined (and if it isn't present, stick with the existing method of calculation), as well as perhaps having the ability to tell it never to wrap (though, as it stands, that would mean the older segments are never removed from disk - that might be desirable if you're intending to republish as VOD later though).