DescriptionWhen the script has been told that an input stream is linear, it supports two options
- Generate full manifest
- Generate manifest with a sliding window
The latter of the two means that older segments will never be requested by the downstream client after a given period (as clients retrieving the manifest for the first time will see a newer segment as the new entry).
Those segments are therefore redundant, so should be removed.
Need to work out the best calculation to use when deciding whether a segment falls into that category though - (manifest length * segment length) * 2 may be slight overkill, but should be sufficient to ensure we don't accidentally remove something that's still live.
As this only applies to live streams, the encoding process(es) should have been forked into the background, the deletion watcher should also be forked so that the script can continue watching for encoding completion (and then kill the deletion watcher).
Activity
2015-06-15 13:05:17
Without changing that, we can't run the cleanup process at the same time. So either we need to make sure it forks into the background, or auto-deletion is only supported on Adaptive streams (and to be fair, more bitrates == more files == more disk space wastage).
2015-06-18 04:05:35
So, if the manifest has a sliding window of 5 segments, the highest numbered segment will be 10 - ffmpeg will then go back to 0 (overwriting the earlier file)
2015-06-18 04:07:15
Webhook User-Agent
View Commit
2016-05-19 07:56:44
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
2019-11-23 12:09:12
2019-11-23 12:09:12