Switching subtitle tracks in live HLS forces sequential, synchronous download of all prior subtitle segments

[rollcat]

Description

Switching subtitle tracks during live HLS playback forces sequential, synchronous download of all subtitle segments from the newly selected track, which significantly delays the chosen subtitles from appearing.

This is especially problematic with Live-to-VOD playlists, where all segments from the beginning of the stream are kept forever; but any HLS playlist with enough segments listed should cause the problem.

The behaviour is not observed for the initially selected (default) subtitle track, and is not present in the same playlist once it's switched to VOD mode (#EXT-X-PLAYLIST-TYPE with EVENT changing to VOD; placing #EXT-X-ENDLIST).

Steps to reproduce

1. Start playback of a live HLS stream with two or more subtitle tracks
2. Change the subtitle track

Expected

The most recent segment (or the one that is the closest to the playhead) from the subtitle track is downloaded; subtitles from the newly selected track start playing as soon as possible.

Actual

Each and every segment from the newly selected track is downloaded in sequence (no new request is sent before the prior request finishes) before subtitle playback is restarted.

Error output

No additional error output.

Additional Information

versions

videojs

We have tested this with Video.js versions 7.8.4, 7.14.3, 7.18.1; and the behaviour is consistent across all of these.

browsers / OSs

We have tested this on all current versions of Chrome, Edge, and Firefox, across macOS 12.x (Intel and M1) and Windows 10. The behaviour is consistent across all of these. The bug doesn't manifest on any tested version of Safari (which seems reasonable, as Safari supports HLS playback natively).

plugins

We have observed this behaviour with Bitmovin Analytics both enabled and disabled.

related

We've found hls.js has had a very similar issue in versions prior to and including 0.12; however the issue has been resolved as of 1.x. This seems to be the related issue: video-dev/hls.js#3987

testing environment

I've reproduced the issue in a minimal player, per the quick start example:

<link href="https://unpkg.com/video.js/dist/video-js.min.css" rel="stylesheet">
<script src="https://unpkg.com/video.js/dist/video.min.js"></script>
<video
    id="my-player"
    class="video-js"
    controls
    preload="auto"
    data-setup='{}'>
  <source src="..."></source>
</video>

Since a live stream source is required to reproduce this issue, and our encoding capacity doesn't allow us to run it 24/7, I can set it up and publish a URL on request, and keep it up for some time (say 8 hours) - please poke me in this thread or via email to set a time.

[welcome]

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[misteroneill]

Thanks for the detailed report!

The team is currently operating at lower capacity, so it may be a while before we get to this one. It seems like something we should fix, though.

[dkbox]

Hi, @misteroneill want to let you know that we have resources in August and September to prepare a live environment for the test as often as you need.