Issue when seeking across PTS rollovers.

[iamstickfigure]

Description

Seeking in this sample HLS playlist does not work. There is a PTS rollover happening in the file, and that probably is contributing to the issue.

Sources

I went ahead and setup an hls playlist on S3 from the problematic sample file.
https://snapstream-dev-test-public.s3.us-east-1.amazonaws.com/videojs-pts-rollover-issue/playlist.m3u8

Steps to reproduce

Load the sample file in video.js
Try to seek far into the file

Here's a test player that demonstrates the issue.
https://videojs-http-streaming.netlify.app/?debug=false&autoplay=false&muted=false&minified=false&liveui=false&partial=false&url=https%3A%2F%2Fsnapstream-dev-test-public.s3.us-east-1.amazonaws.com%2Fvideojs-pts-rollover-issue%2Fplaylist.m3u8&type=&keysystems=&buffer-water=false&override-native=true

Results

Actual

The seek fails, and it starts playing from the beginning.

Expected

Should seek properly.

Here is an older test player where seeking works properly. You can just load in the s3 link on this page.
https://videojs.github.io/http-streaming/

Additional Information

videojs version

video.js v7.11.2

Workaround

In case it helps, we currently have a workaround hack for this issue. In TimestampRolloverStream, we've commented out the discontinuity() in the reset function.

this.reset = function () {
  // this.discontinuity();
  this.trigger('reset');
};

[video-archivist-bot]

Hey! We've detected some video files in a comment on this issue. If you'd like to permanently archive these videos and tie them to this project, a maintainer of the project can reply to this issue with the following commands:

• for https://snapstream-dev-test-public.s3.us-east-1.amazonaws.com/videojs-pts-rollover-issue/playlist.m3u8: say @video-archivist-bot save KEPKAp
• for https://videojs-http-streaming.netlify.app/?debug=false&autoplay=false&muted=false&minified=false&liveui=false&partial=false&url=https%3A%2F%2Fsnapstream-dev-test-public.s3.us-east-1.amazonaws.com%2Fvideojs-pts-rollover-issue%2Fplaylist.m3u8: say @video-archivist-bot save Mj4DjJ

[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.

[gkatsev]

@video-archivist-bot save KEPKAp

[video-archivist-bot]

OK, we've archived KEPKAp (https://snapstream-dev-test-public.s3.us-east-1.amazonaws.com/videojs-pts-rollover-issue/playlist.m3u8) over at https://storage.playbackproblems.mux.dev/KEPKAp/playlist.m3u8 and we'll keep it there for future reference.

[asoulliereHT]

via @gesinger ,
https://hockeytech-lh.akamaihd.net/i/game939202audio1_1@742830/master.m3u8
from debug logs:
["VIDEOJS:", "DEBUG:", "VHS:", "PlaybackWatcher >", "Trying to seek outside of seekable at time 0 with …84144.29168888889. Seeking to -84144.29168888889."]

it looks like a rollover happens in the stream around segment https://hockeytech-lh.akamaihd.net/i/game939202audio1_1@742830/segment161013552_1_av-p.ts?sd=10&rebase=on
I think the issue is that we should be able to play fine when going sequentially through segments, but if we seek, we don’t use the reference for the last time when determining if a rollover happens or not. This is something we should fix, somewhere around https://github.com/videojs/http-streaming/blob/main/src/segment-loader.js#L2282-L2300

const previousSegment = segmentInfo.playlist.segments[segmentInfo.mediaIndex - 1];

if (previousSegment && previousSegment.timeline === segment.timeline) {
// The baseStartTime of a segment is used to handle rollover when probing the TS
// segment to retrieve timing information. Since the probe only looks at the media's

Yeah, a rollover causes it, but we should be able to handle rollover, as it is valid for TS segments to rollover. They have a max timestamp of 2^33, after which it resets to 0.
So the stream rolls over cause it reaches the max timestamp and then goes back to 0, but the player, if it is seeking and not playing sequentially, doesn’t account for the rollover.
If the segments play sequentially then that line of code will have the previous segment’s timestamp and know that a rollover happened, then account for it.
If the previous segment doesn’t have the timing info then we don’t account for the rollover, and when doing certain calculations, will end up with negative times.

[video-archivist-bot]

Hey! We've detected some video files in a comment on this issue. If you'd like to permanently archive these videos and tie them to this project, a maintainer of the project can reply to this issue with the following commands:

• for https://hockeytech-lh.akamaihd.net/i/game939202audio1_1@742830/master.m3u8: say @video-archivist-bot save vjNk1w
• for https://hockeytech-lh.akamaihd.net/i/game939202audio1_1@742830/segment161013552_1_av-p.ts: say @video-archivist-bot save ljapWE

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[asoulliereHT]

please keep this open

[gkatsev]

root cause is likely #1000.