WebVTT: Some CUES_PARSED events contain stale data when changing subtitle track, leading to duplicate text cues #6680
Labels
Bug
Needs Triage
If there is a suspected stream issue, apply this label to triage if it is something we should fix.
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
Additional player setup steps
Checklist
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
Chrome media internals output
The text was updated successfully, but these errors were encountered: