Improve "direct"
audioTrackSwitchingMode compatibility by re-seeking
#1246
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.
Some RxPlayer users had an issue of unaudible audio after an audio track switch on Chrome when the
audioTrackSwitchingMode
option was set to"direct"
(meaning that the track switch will happen - roughly - in place after a small rebuffering the time to load the new audio segments).That issue seems to be at the browser-level (or may even be at a lower level), but as it can be prevented in the RxPlayer with no much disadvantage, it is still a win to work-around it at the RxPlayer-level.
Lately, while PoCing an HLS media player personal project, I tried a new technique which seems to fix this issue reliably.
When changing the audio track, here's the new behavior in my PoC:
The first flush thus prevent from still having the lower-level buffer considering old data in the previous track, the second one fixes the muted audio issue - for some reasons. Most of the time no interruption is visible/audible and when it is, it just seems linked to the audio track switch and does not seem shocking.
For the RxPlayer, only the first flush was performed until now.
This commit adds the second one, though it does not happen once the new push operation is
"""validated"""" like for the original implementation, but once the media element on the page announces that it has playable data around the current position instead.
This is because implementing the former is much harder in the RxPlayer. There shouldn't be any real difference between the two implementations, though, and I tested it with success on Chrome and Firefox, with various bandwidth settings (to see if it was audible/visible when the audio track switch is quasi-instantaneous for example).