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.

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

Schedule live reload based on start of last update request #4961

Conversation

robwalch
Copy link
Collaborator

@robwalch robwalch commented Oct 12, 2022

This PR will...

  • Schedule live reload time measuring from the last scheduled time the client began loading the Playlist file
  • Use last fragment duration rather than target duration when playhead is less than three target durations from the live edge
  • Eliminate any latency in refresh interval added by setTimeout or JavaScript execution
  • Move clock logic out of computeReloadInterval and into playlistLoaded where timer is set and last request request time (requestScheduled) is maintained
  • Fix blocking reload schedule when low latency mode is disabled to start one part duration or one second from when an update is expected (Improves upon Fix blocking playlist requests with lowLatencyMode is set to false #3792)

Why is this Pull Request needed?

Prevent saw-tooth forward buffer length pattern as playlist refreshes drift from playlist update interval or target duration.

Resolves issues:

Data provided by @wilaw showing CMCD forward buffer length on playlist requests getting shorter overtime until the difference wraps by one target duration.

Checklist

  • changes have been done against master branch, and PR does not conflict
  • new unit / functional tests have been added (whenever applicable)
  • API or design changes are documented in API.md

@robwalch
Copy link
Collaborator Author

CC @mattzucker
This PR is needed as a followup to #4940.

@robwalch robwalch added this to the 1.3.0 milestone Oct 12, 2022
Use last fragment duration rather than target duration when playhead is less than two target durations from the live edge
@robwalch robwalch force-pushed the bugfix/live-reload-interval-relative-to-last-request-start-and-fragment-duration branch from c4263ac to a9d1fb3 Compare October 12, 2022 00:18
littlespex
littlespex previously approved these changes Oct 12, 2022
mattzucker
mattzucker previously approved these changes Oct 12, 2022
@robwalch robwalch dismissed stale reviews from mattzucker and littlespex via 4859ed1 October 19, 2022 01:43
@robwalch robwalch requested review from littlespex, mattzucker and cjpillsbury and removed request for mattzucker October 19, 2022 01:50
littlespex
littlespex previously approved these changes Oct 19, 2022
cjpillsbury
cjpillsbury previously approved these changes Oct 20, 2022
Copy link
Collaborator

@cjpillsbury cjpillsbury left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

…t end is less than or equal to four target durations

(Reload is scheduled on update. With a default live sync of 3 target durations, without interruption, a distance of 3x-4x is most likely.)
@robwalch robwalch dismissed stale reviews from cjpillsbury and littlespex via e2f2f24 October 24, 2022 17:27
@robwalch robwalch merged commit e38d5b7 into master Oct 24, 2022
@robwalch robwalch deleted the bugfix/live-reload-interval-relative-to-last-request-start-and-fragment-duration branch October 24, 2022 23:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants