videojs / http-streaming

HLS, DASH, and future HTTP streaming protocols library for video.js
https://videojs-http-streaming.netlify.app/
Other
2.49k stars 421 forks source link

Problems scrubbing for long audio streams #152

Open ghost opened 6 years ago

ghost commented 6 years ago

mayank-gupta commented on Aug 17, 2017, 9:44 PM UTC:

Description

When we use the videojs-contrib-hls library to go from one point to another in long audio streams say more than 30 hours, player behaves weirdly. It goes to random locations and doesn't give any error.

Here is an HLS stream which can be used to reproduce the bug. Try playing it in the player here and try to skip to a position that is more than half of the stream. It will jump to some random location in the stream.

videojs-contrib-hls version

what version of videojs-contrib-hls does this occur with? videojs-contrib-hls 5.8.3

videojs version

what version of videojs does this occur with? video.js 6.2.4

Browsers

what browsers are affected? please include browser and version for each

Platforms

what platforms are affected? please include operating system and version or device and version for each

This issue was moved by forbesjo from videojs/videojs-contrib-hls#1237.

ghost commented 6 years ago

mjneil commented on Aug 17, 2017, 10:09 PM UTC:

Timestamps in MPEG2TS streams are 33 bits, with a max value around ~26.5 hours, so there will be multiple segments with the same exact timestamp. Currently, we don't have a great way of dealing with seeks that span very large time ranges. During the transmuxing stage, we try and account for this rollover by comparing and adjusting the timestamps when a rollover is detected. https://github.com/videojs/mux.js/blob/master/lib/m2ts/timestamp-rollover-stream.js#L34 This is something we'd like to address but has not been prioritized

ghost commented 6 years ago

forbesjo commented on Jul 11, 2018, 8:12 PM UTC:

Putting this in the VHS backlog

/move to http-streaming