Closed dzianis-dashkevich closed 1 year ago
Merging #1374 (03a25b5) into 2.x (1c93e79) will increase coverage by
0.02%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## 2.x #1374 +/- ##
==========================================
+ Coverage 86.35% 86.37% +0.02%
==========================================
Files 39 39
Lines 9871 9887 +16
Branches 2301 2307 +6
==========================================
+ Hits 8524 8540 +16
Misses 1347 1347
Impacted Files | Coverage Δ | |
---|---|---|
src/master-playlist-controller.js | 94.86% <100.00%> (+<0.01%) |
:arrow_up: |
src/segment-loader.js | 96.38% <100.00%> (+<0.01%) |
:arrow_up: |
src/manifest.js | 93.57% <0.00%> (+0.12%) |
:arrow_up: |
src/dash-playlist-loader.js | 90.35% <0.00%> (+0.27%) |
:arrow_up: |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
Description
We have a race condition issue that breaks playback during quality switch:
Here is a visual representation of the race condition:
As you can see from the visual representation, we have a pending segment request which is from the previous playlist, because the
seeking
event kick-starts the segment loader before we have a new playlist loaded. But we receivetrackInfo
after the new playlist is loaded. That means that during codec calculation it will get codecs from the new playlist, while the segment loader is about to append a segment from the previous one. Because initialization data is not added and codecs do not match with the source buffer's current codecs setup - the source buffer fails to append this segment. The problem is reproducible mainly with CMAF HLS since the transport stream is usually self-initialized.Specific Changes proposed
I was thinking about possible ways to solve this problem. The first idea was the following: Do not load segments while we are waiting for a playlist. Possible solutions could be: Ignore this seeking event after setting the current time after a segment loader resets everything. Visually it would look like this:
It works fine and fixes the issue, but! Users will always see a loading spinner during the quality switch because the player removes everything from the source buffer and does not append anything. It will append only after the playlist + first segment are loaded. So, users will lose a seamless quality switching experience. This problem led me to the second idea: Keep segments loading but ensure that the player always adds initialization data after the quality switch, and the player always uses the segment's playlist for source buffer codecs calculation for consistency.
Requirements Checklist