WebVTT: Some CUES_PARSED events contain stale data when changing subtitle track, leading to duplicate text cues

What version of Hls.js are you using?

Latest (1.5.15)

What browser (including version) are you using?

Latest Chrome (128.0.6613.114)

What OS (including version) are you using?

Windows 11

Test stream

https://storage.googleapis.com/shaka-demo-assets/angel-one-hls/hls.m3u8

Configuration

{
  renderTextTracksNatively: false
}

Additional player setup steps

// Custom cue appender function
const addCue = cue => console.log('Cue:', cue);

hls.on(Hls.Events.CUES_PARSED, (e, data) => {
  const { cues, ...cuesParsed } = data;
  console.log('CuesParsed:', cuesParsed);

// Current workaround - Matching: https://github.com/video-dev/hls.js/blob/f16746580ed0bb027efc2f093bdbd00b57afbe43/src/controller/timeline-controller.ts#L640
// const currentTextTrack = this.player.subtitleTracks.find(value => value.id === this.player.subtitleTrack);
// if (
//   (data.track === 'default' && !currentTextTrack?.default) ||
//   data.track !== `subtitles${currentTextTrack?.id ?? -1}`
// ) return;

  cues.forEach(cue => addCue(cue));
});
hls.on(Hls.Events.SUBTITLE_TRACK_SWITCH, (e, data) => {
  console.log('SubtitleTrackSwitched:', data.id);
});
hls.once(Hls.Events.BUFFER_APPENDED, (e, data) => {
  hls.subtitleTrack = 2;
});

Checklist

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

Steps to reproduce

Change subtitle track after the player has started loading some subtitle segments. Example above in player setup steps - changing subtitle track after the first BUFFER_APPENDED reproduces the issue 100% of the time for me.

Minimal reproduction available here: https://hyddan.github.io/hls.js-cues-parsed-stale-cues-reproduction/

Expected behaviour

Ideally I would like that the player didn't emit these stale cues but an alternative would also be to have the track id included as its own property in the CUES_PARSED event. That way I would not have to rely on duplicating the naming scheme used for the track property of the event which could change without me knowing it.

What actually happened?

New cues from the previous subtitle track are sent out after a track change has been confirmed with the SUBTITLE_TRACK_SWITCH event.

Log: hls js-cues-parsed-stale-cues-reproduction log

Console output

See image above.

Chrome media internals output

N/A

video-dev / hls.js