Remain in buffering state until text is buffered

[interlark]

Using hls streams, for example this shaka-demo, you can notice than on seek ts-segments and webvtt-segments don't get loaded evenly.

Expected:

fileSequence64.ts
fileSequence64.webvtt
fileSequence65.ts
fileSequence65.webvtt

or

fileSequence64.webvtt
fileSequence64.ts
fileSequence65.webvtt
fileSequence65.ts

That's why sometimes when you seek your hls-streams you could catch your videos without subtitles for a while.

[TheModMaker]

I notice the TS segments are grey, so the browser is probably caching the segments, so they get downloaded immediately. Since the first TS segment is downloaded quickly, we fetch the second soon. We don't have any scheduling for segments, we just download segments in order as quickly as we can. We also play the video once audio+video is downloaded, so we'll start playing even if we don't have the text available.

[interlark]

How can I avoid playing without vtt segment? Like add subtitles as required as audio+video.

[interlark]

I think it's sorta bug, because if text track is enabled and selected, then player ought to wait for a text fragment as well as audio and video.

[joeyparrish]

This doesn't appear to be a bug to me. We have logic that no stream should be more than 1 segment ahead of any other, and that restriction appears to be working. Your audio doesn't get 10 segments ahead of your video (as it used to once upon a time in an old version of Shaka Player). The same is true for text.

The buffering of media (pausing until more is loaded) is done at the level of the media element (<video> or <audio> tag in the HTML). This does not include text, which is handled separately.

Text does not need to be fetched ahead of audio or video being fetched, it only needs to be processed ahead of audio or video being played. It's possible that your buffering goal (what is fetched ahead of playback) is really close to your segment size. We can't tell what your segment size is, but 10s is surprisingly common still, and that's also our default buffering goal in current versions of Shaka Player.

Therefore I would recommend you increase the buffering goal of the player so that what is fetched and processed is further ahead of what is being played. Try this:

player.configure('streaming.bufferingGoal', 20);

If that doesn't work, try increasing it to 30.

Does this help?

[interlark]

Parameter bufferingGoal could help with playing without seeks, when you seek a stream (or walk through specific time points), the player doesn't wait for subtitles and start playing without them. That's why you could miss one vtt-cue if it has relatively heavy size or short duration (which could disturb hear-impaired persons), currently the only way of walk-around the problem is rewind a little back the stream to re-watch it with already downloaded text segment.

[TheModMaker]

I think it's reasonable to change our buffering logic to also wait for text tracks. We currently manually enter a buffering state when we don't have enough data and only move forward when we have buffered streaming.rebufferingGoal amount of content. We could extend this logic to apply to text too. If the user has enabled text tracks, it's because they may need it so it should be the same priority as audio.

[avelad]

Is anyone interested in seeing this implemented? Otherwise the issue will be closed in 7 days.

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.