[Proposal] Add PlaybackRate-based rebuffering avoidance mechanism #1588
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While admittedly checking what other media players were doing that we don't do yet, I saw an interesting opportunity.
Some players have a mechanism where they lower very slightly the playback rate (the speed at which we play) - for example at
0.95
(meaning we play 0.95 seconds of content every second) - if the current buffer size is low, until it gains back an acceptable size again.I'm not sure of the actual impact this mechanism has in terms of rebuffering avoidance but it seems that it can help.
Because it has potential but has high uncertainties, I propose adding this mechanism as an experimental
loadVideo
option for now, meaning that we reserve the right to update this API or even remove it at any time. I re-use theexperimentalOptions
concept I already proposed in several of the currently-open PRs for this.Because we might want to check the buffer size often when it's close to
the potentially-very-low value where this mechanism activates, I reduced our PlaybackObserver's regular interval from 1s to 500ms. This is the same interval we already tested on low-latency contents so it shouldn't be an issue.
I also for now only enable this mechanism if the application plays at x1, not if it is already updating the playbackRate as I found the wanted behavior in thoses cases harder to define.
Some players also only enable this mechanism on VoD contents, not on live contents. I think that this is a mistake as there's no reason timeshifted live shouldn't be treated the same.
I didn't do the API documentation yet nor link it to the demo because I'm somewhat unhappy for that mechanism's name, for now called
playbackRateBasedRebufferingAvoidance
.Even if it describes well what it does, I found that name too long even in the code. I think we may prefer finding it a nicer-sounding name to make the code more readable and the API more approachable, like we did for our "fast-switching concept" (which sadly has now a new meaning for DASH low-latency contents different than ours or dash.js's usage, but that's always a risk and I'm willing to take it).