Fix: CMAF HLS. Source buffer change type is called with wrong codecs sometimes when append segment without init data because of a race condition. #1375
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.
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