Implemented smooth audio switching #7575
Conversation
github-project-automation
bot
moved this to Top priorities
in HLS.js Release Planning and Backlog
# Conflicts: # src/controller/stream-controller.ts
…smux complete, which is before buffering the new audio track's audio segment
src/types/media-playlist.ts
Outdated
| nextAudioTrackSwitchingSafetyDelay?: number; | ||
| nextAudioTrackBufferFlushDelay?: number; |
There was a problem hiding this comment.
AudioSelectionOption is intended to describe the preferred audio of the user, not how to get the option or switch between options. AudioSelectionOption should remain limited to a subset of MediaPlaylist attributes and audio characteristic adjacent properties.
If these new options are necessary, then they should be added to HlsConfig with defaults. Since I don't see any defaults, are they even necessary?
There was a problem hiding this comment.
Just removed nextAudioTrackSwitchingSafetyDelay & renamed nextAudioTrackBufferFlushDelay to nextAudioTrackBufferFlushForwardOffset to be more accurate and put that into HlsConfig with a default value.
| ) { | ||
| const previousFrag = this.fragPlaying; | ||
|
|
||
| super.checkFragmentChanged(type); |
There was a problem hiding this comment.
Instead of having audio-stream-controller pass in AUDIO and stream-controller pass in MAIN, you can use this.playlistType in the base checkFragmentChanged method. (I'm assuming that only the fragment type relevant to each controller is ever checked.)
| const track = this.switchingTrack; | ||
| if (track) { | ||
| this.bufferedTrack = track; | ||
| this.switchingTrack = null; |
There was a problem hiding this comment.
Ensure no issues are encountered from this change with LL-HLS
|
Add unit tests before aproving/merging. |
2 participants
This PR will implement smooth audio track switching.
Why is this Pull Request needed?
Are there any points in the code the reviewer needs to double check?
Resolves issues:
Checklist