HLS text segment timestamp issues

[joeyparrish]

When we fetch segments in the HLS parser to extract their timestamps, we fail if that process fails. This means that empty text segments cause a playback failure.

Furthermore, if the text segment is not empty, we still handle it wrong in many cases. We extract the start time of the first cue, which is not the same as the start time of the first segment. If the first cue is at time 2, we expect that this is the starting time of the segment itself.

When we then treat the timestamps as segment-relative, we add the segment start time to all cue times, which causes them to be delayed more and more as time goes on. In the HLS version of "Angel One", you can see the cues spreading out subtly over the 60-second clip. In Axinom's HLS live stream, you won't see cues at all, since the timestamps are already large enough for this skew to be extreme.

In HLS, we can usually expect that the X-TIMESTAMP-MAP header is present, which will give us a clue as to the segment start time. When this header is missing, the HLS spec says we should treat it as being present with a mapping of 0 to 0.

We should use this mapping-based offset as the first text segment's start time. This will solve the playback failure on empty segments. We should also stop treating HLS-based VTT as segment-relative.

(Related to #1558)

[kqyang]

We should use this mapping-based offset as the first text segment's start time.

The media segment may not start from 0. Do you mean to use the offset + the earliest media segment start time as the first text segment's start time?

[ChristiaanScheermeijer]

Hi @joeyparrish,

Is the following issue also being caused by the problem you are describing?

https://shaka-player-demo.appspot.com/demo/#asset=https://dutchchannels.nl/demo/videodock/hls/Manifest.m3u8;lang=nl-NL;build=uncompiled

• HLS playback starts at the same position as the first VTT cue (you can't seek before that position).
• The same "offset" is being used for the VTT rendering. So all cues are delayed by the startTime of the first cue.

We are having this issue in the Chromecast receiver. The test stream from above is an extracted from Axinom.

The first issue seems to be resolved in the master branch though.

[ChristiaanScheermeijer]

A workaround for this issue:

By adding a placeholder cue in the WebVTT file at 0 seconds, the offset issue seems to be fixed.

WEBVTT

00:00:00.000 --> 00:00:00.010
...

[joeyparrish]

@ChristiaanScheermeijer, yes, I believe that is the same issue.

[Romain-Bernier]

I have an issue of synchronization between the subtitles and the video in the following media on the shaka demo page : https://mpdsample.s3.amazonaws.com/SHARE/vtt_singleoutput_hls/master.m3u8
I believe it's the same issue, correct me if I'm wrong.
Any update on a upcoming fix ?
Thanks

[joeyparrish]

@Romain-Bernier, it's probably the same issue. I don't have an ETA on a fix yet, but hopefully, we will find time to address this for v2.6.

[joeyparrish]

Starting now on the nightly build, we will no longer parse text segments to get timestamps. Please re-check your content on the nightly and let us know if you have any further issues. Thanks!