Implement support for LL-HLS #EXT-X-PRELOAD-HINT part loading

[robwalch]

Adding support for Hinted Part and Map Preloading could reduce LL-HLS latency by an additional part duration. This feature was left out of v1.0 because of timing and the complexity involved in dropping hinted parts in situations that still need to be cataloged and tested. We also lacked multiple MAP support which has not landed in v1.0.4.

Feature summary and resources:

1. Parse EXT-X-PRELOAD-HINT tags and attributes:

   • EXT-X-PRELOAD-HINT:TYPE=MAP,URI=”init.mp4”preload init segments (usually followed by a discontinuity)

   • EXT-X-PRELOAD-HINT:TYPE=PART,URI=”part.m4s”

   • with byterange (length known)

     EXT-X-PRELOAD-HINT:TYPE=PART,URI=”part.m4s”,BYTERANGE-START=0,BYTERANGE-LENGTH=4044

   • with byterange chunk-transfer

     EXT-X-PRELOAD-HINT:TYPE=PART,URI=”part.m4s”,BYTERANGE-START=0

2. Make preload-hint requests and handle the response
   • request part files and hold result for part update (no byterange)
   • request part byterange and hold result for part update (length known)
   • stream part file, hold result for part update byte-range(s) is received in part-update (chunk-transfer)
   • do not sample TTFB for blocked part-hint responses
3. Handle part updates following preload-hint a. If part update matches preload-hint request/response push update b. If part update invalidates preload-hint drop request/response

https://developer.apple.com/wwdc20/10229 https://developer.apple.com/wwdc20/10232

[streamthing]

We need this! When?

[Qizot]

Any update on this?

[robwalch]

Waiting on the author to file the PR: https://github.com/video-dev/hls.js/compare/master...feature/preload-hint The feature is scheduled for a later release (Roadmap https://github.com/video-dev/hls.js/discussions/5194) but can be released earlier with review and testing.

[vk342]

I have run the code in this PR against a proprietary low-latency live stream, and I am happy to report that my LL stream ran well.

While this PR did not resolve the stalling issues I reported in https://github.com/video-dev/hls.js/issues/6350, I did not observe any additional errors or latency.

I can confirm that download of PRELOAD-HINT part begins as soon as the new manifest is fetched and also, quite importantly, a bug in my encoder that could potentially affect LL playback did not have a negative effect on the hls.js performance:

For example, my encoder would generate this playlist:

#EXT-X-PART:DURATION=0.52,URI="media-u07v181yd_b837632_vo_sfm4s_286023577.10_m3u8.cmfv"
#EXT-X-PART:DURATION=0.28,URI="media-u07v181yd_b837632_vo_sfm4s_286023577.11_m3u8.cmfv"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="media-u07v181yd_b837632_vo_sfm4s_286023578.0_m3u8.cmfv"

but the next time manifest is updated, the encoder would return

#EXT-X-PART:DURATION=0.52,URI="media-u07v181yd_b837632_vo_sfm4s_286023577.10_m3u8.cmfv"
#EXT-X-PART:DURATION=0.28,URI="media-u07v181yd_b837632_vo_sfm4s_286023577.11_m3u8.cmfv"
#EXTINF:6.0,
media-u07v181yd_b837632_vo_sfm4s_286023577.m3u8.cmfv
#EXT-X-PART:DURATION=0.28,URI="media-u07v181yd_b837632_vo_sfm4s_286023578.0_m3u8.cmfv"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="media-u07v181yd_b837632_vo_sfm4s_286023578.1_m3u8.cmfv"

The problem here is that for the first playlist the PRELOAD-HINT for media-u07v181yd_b837632_vo_sfm4s_286023578.0_m3u8.cmfv was mis-attributed to fragment 286023577, while in fact it was the first part for then next fragment 286023578.

hls.js handles this case correctly: it just discards cashed data for media-u07v181yd_b837632_vo_sfm4s_286023578.0_m3u8.cmfv without trying to append it to fragment 286023577.

When the same part is advertised as a part for fragment 286023578, hls.js tries to download it again, but, helpfully, it is already in the local browser cache.

Many thanks to @iamboorrito for the robust code!