[Proposal] Add PlaybackRate-based rebuffering avoidance mechanism #1588
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
peaBerberian
added
the
proposal
peaBerberian
force-pushed
the
feat/playbackRateBasedRebufferingAvoidance
branch
from
f3c5cc1 to
e3d4723
Compare
peaBerberian
force-pushed
the
feat/playbackRateBasedRebufferingAvoidance
branch
2 times, most recently
from
a0d489f to
e4567e7
Compare
peaBerberian
added
Priority: 2 (Medium)
peaBerberian
force-pushed
the
feat/playbackRateBasedRebufferingAvoidance
branch
from
e4567e7 to
3a50743
Compare
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 the `experimentalOptions` 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).
… buffer gap is set to 0
peaBerberian
force-pushed
the
feat/playbackRateBasedRebufferingAvoidance
branch
from
3a50743 to
aa14ba6
Compare
|
Automated performance checks have been performed on commit Tests results✅ Tests have passed. Performance tests 1st run outputNo significative change in performance for tests:
If you want to skip performance checks for latter commits, add the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
loadVideooption for now, meaning that we reserve the right to update this API or even remove it at any time. I re-use theexperimentalOptionsconcept 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).