Switching audio tracks is not working properly

[gjanblaszczyk]

What version of Hls.js are you using?

1.5.19

What browser (including version) are you using?

Chrome 132.0.6834.83

What OS (including version) are you using?

Windows 10, Mac OS X, Ubuntu 22.04

Test stream

https://hlsjs.video-dev.org/demo/?src=https%3A%2F%2Fqcdn.screen9.com%2Fmedia%2Fm%2FH%2FmHZBquU3eCmLzwO3vXq0Vg_auto_hls.ssl.m3u8%3Fauth%3DPGeCUq3_tpmkQlOOdC3ALUPdIvQ21OPGUDvSbUe2jOyHo1jn2fTXw0vOyynaj02hYzdamtkti3LZt69sXFpjjw&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==

Configuration

{
  "debug": true,
  "enableWorker": true,
  "lowLatencyMode": true,
  "backBufferLength": 90
}

Additional player setup steps

No response

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• The issue occurs in the stable client (latest release) on https://hlsjs.video-dev.org/demo and not just on my page
• The issue occurs in the latest client (main branch) on https://hlsjs-dev.video-dev.org/demo and not just on my page
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

1. Go to https://hlsjs.video-dev.org/demo/?src=https%3A%2F%2Fqcdn.screen9.com%2Fmedia%2Fm%2FH%2FmHZBquU3eCmLzwO3vXq0Vg_auto_hls.ssl.m3u8%3Fauth%3DPGeCUq3_tpmkQlOOdC3ALUPdIvQ21OPGUDvSbUe2jOyHo1jn2fTXw0vOyynaj02hYzdamtkti3LZt69sXFpjjw&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==
2. Start the video and enable sound if it is muted. You should hear the default audio track without audio description.
3. Go to the Audio Tracks tab and switch the audio track to the second one in the list. This track should include audio description. The narrator's voice should play from the 1st to the 13th second.
4. Then, switch the audio track back to the first one (without audio description) and rewind the playback to the first second to listen to the track.

Expected behaviour

Throughout the entire length of the video, you should hear the original audio track without any narrator comments from the audio description.

What actually happened?

When the audio track is switched to the audio description track between 0-5 seconds of the video, then after switching back to the original track and replaying the video from the beginning, you will hear the narrator's voice from the audio description track until the 5th second. After the 5th second, the correct original audio track will play.

If the switch to the audio description track occurs between 5-10 seconds, then after switching back to the original track, you will hear the original track from 0 to 5 seconds and from 10 seconds to the end of the video. However, between 5-10 seconds, the narrator's voice from the audio description track will still play.

In general, strange behavior occurs when switching between audio tracks multiple times. I tested this video on other players, and audio track switching worked without issues, so I believe this is unlikely to be a problem with the HLS playlist itself but who knows...

I would appreciate any suggestions and would be happy to provide additional information if needed.

Console output

Console output looks normal except for this warning that sometimes occurs: 
`transmuxer-interface.ts:394 [warn] > MPEG-TS PMT found at 5828 after unknown PID '256'. Backtracking to sync byte @0 to parse all TS packets.`

Chrome media internals output

[robwalch]

The buffered audio is not being flushed because both audio tracks share the same name and language.

You could workaround the issue by changing the name of the media tag with CHARACTERISTICS="public.accessibility.describes-video" to something like "Svenska (audio description)"

Tracks with different characteristics are not identical so hls.js should flush the buffered audio on track change. Thank you for reporting this bug. I'll come up with a fix and patch the latest stable release.

[robwalch]

hls.js/src/controller/audio-stream-controller.ts

Lines 1022 to 1031 in 8a7812e

	private flushAudioIfNeeded(switchingTrack: MediaPlaylist) {
	const { media, bufferedTrack } = this;
	const bufferedAttributes = bufferedTrack?.attrs;
	const switchAttributes = switchingTrack.attrs;
	if (
	media &&
	bufferedAttributes &&
	(bufferedAttributes.CHANNELS !== switchAttributes.CHANNELS ||
	bufferedTrack.name !== switchingTrack.name ||
	bufferedTrack.lang !== switchingTrack.lang)

There are helper functions like mediaAttributesIdentical and matchesOption which would be better suited to handle this conditional.

[robwalch]

Here's the fix in main #6963. After merging we can cherry pick it into patch/v1.5.x and cut release v1.5.20.

[gjanblaszczyk]

Thank you so much, @robwalch , for checking and solving the issue. You make my day! :)

[gjanblaszczyk]

btw I created a simple example with a video tag and the same HLS video source here:
https://codepen.io/gregbla/pen/raBbEyr
On my iPhone (iOS 18.2.1), when I open the example, only the first audio track plays, but the second one is not visible at all.

Is it possible that the native Safari player has the same issue as HLS.js before your fix?

[robwalch]

Is it possible that the native Safari player has the same issue as HLS.js before your fix?

It would appear that Safari HLS playback enumerates audio tracks by #EXT-X-MEDIA NAME as well. I wouldn't expect this as the URIs differ, and one contains CHARACTERISTICS while the other does not. File an issue with Feedback Assistant against Safari/WebKit stating why this is important to you and whether or not you can provide unique NAME attributes for each audio option.

HLS audio and subtitle option NAME attribute values should be unique for other reasons too. See the "Displaying Rendition Names" and "Localization Dictionary" sections of the HLS spec. The value of the NAME attribute is used as a key when looking up translations in a localization dictionary. Using the same name makes in impossible to provide unique localizations. In this case, appending a label derived from CHARACTERISTICS (Video Description) would be recommended.

[gjanblaszczyk]

Super, thanks for the answer, Rob. I submitted a ticket to Apple Feedback, but I have a feeling I'll be waiting looooooong for a response... :)