Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
robwalch opened this issue Jun 2, 2021 · 4 comments · May be fixed by #6356
Open

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

robwalch opened this issue Jun 2, 2021 · 4 comments · May be fixed by #6356
Labels
New Feature
Milestone
1.8.0

Comments

@robwalch
Copy link
Collaborator

robwalch commented Jun 2, 2021 •
edited
Loading

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
@robwalch robwalch changed the title Hinted Part and Map Preloading Implement support for LL-HLS #EXT-X-PRELOAD-HINT part loading Jun 2, 2021
@streamthing
Copy link

We need this! When?

@getroot getroot mentioned this issue May 30, 2022
Closed
@kanongil kanongil mentioned this issue Aug 4, 2022
Merged
3 tasks
@Qizot
Copy link
Contributor

Qizot commented Aug 8, 2022

Any update on this?

@robwalch robwalch added this to the 1.5.0 milestone Aug 25, 2022
@robwalch robwalch moved this from To do to In progress in Low-Latency HLS (LL-HLS) Apr 17, 2023
@robwalch robwalch modified the milestones: 1.5.0, 1.6.0 Jul 23, 2023
@robwalch robwalch modified the milestones: 1.6.0, 1.8.0 Aug 10, 2023
@robwalch
Copy link
Collaborator Author

robwalch commented Sep 30, 2023 •
edited
Loading

Waiting on the author to file the PR: master...feature/preload-hint
The feature is scheduled for a later release (Roadmap #5194) but can be released earlier with review and testing.

@robwalch robwalch mentioned this issue Apr 13, 2024
Open
@iamboorrito iamboorrito linked a pull request Apr 15, 2024 that will close this issue
Open
3 tasks
@vk342
Copy link
Contributor

vk342 commented May 28, 2024

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 #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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
New Feature
Projects
Low-Latency HLS (LL-HLS)
Status: In progress
Milestone
1.8.0
Development

Successfully merging a pull request may close this issue.

Feature: Implement support for LL-HLS #EXT-X-PRELOAD-HINT part loading video-dev/hls.js
4 participants
@robwalch @Qizot @vk342 @streamthing