Our use case requires short looping videos on the app’s front screen. These videos include subtitles for accessibility, so they are delivered as HLS (m3u8) rather than MP4, allowing subtitles to be natively rendered instead of burned into the video.
Since moving from MP4 to HLS, we’ve observed that video time segments (.ts / .m4s) are not fully cached between loops. When the video reaches the end and restarts, the same time segments are re-requested from the network instead of being served from cache.
This behavior occurs even though:
The playlist and segments are identical between loops
The content is short and fully downloaded during the first playback
No explicit cache-busting headers are present
We have investigated available caching options in AVFoundation but have not found a way to persistently cache HLS segments for looping playback without implementing a full offline download using AVAssetDownloadURLSession, which feels disproportionate for this use case.
Using Proxyman, I can clearly see repeated network requests for the same HLS time segments on every loop, resulting in unnecessary network usage and reduced efficiency.
I would like to understand:
-
Whether this is expected behavior for HLS playback?
-
Whether there is a supported way to cache HLS segments across loops?
-
Or whether there is a recommended alternative approach for looping accessible video with subtitles without re-requesting time segments?