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

[Hyddan]

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:

Console output

See image above.

Chrome media internals output

N/A

[robwalch]

Relates to #6798 (both comment on SUBTITLE_TRACK_SWITCH event). Consider addressing these issues together.

Ideally I would like that the player didn't emit these stale cues

CUES_PARSED will continue to emit for all cues parsed. It may be that a segment was not aborted prior to a switch, or was already being transmuxed and not dropped because of a context switch after coming out of the transmuxer.

have the track id included as its own property in the CUES_PARSED event.

Currently, CuesParsedData has as track property of type string which has a unique value based on the subtitle media option it was extracted from; it has a value of 'default' for the default track and 'subtitles<fragLevel-or-id>' for the others. It's possible that the level number is not unique

We should add the track Level object as a property to CuesParsedData on CUES_PARSED. This would provide track name, language and other properties.

[Hyddan]

Sounds good! Having the level object would be more than sufficient for this.