Video stop when seeking backwards #2187
Comments
|
Hi @arkadash, Probably I am missing something but I am not able to reproduce this issue. If I didn't understand bad, you are just doing a seek back operation in one of the sample vod streams, isn't it? how frequently you reproduce this issue? Out of videojs and video-contrib-dash, can you reproduce this issue in latest version of the reference player (http://reference.dashif.org/dash.js/v2.6.0/samples/dash-if-reference-player/index.html)? |
|
It happens sometimes. Reproduce instructions:
|
|
Got it, I could reproduce the issue in dash.js reference player after the latest instructions (by the way, your zip file can't be accessed. I get an unauthorized response). I am wonder if this could be related with #2189. Seems a completely different issue, but could be related somehow (issue with management of buffers?). |
|
Uploaded the Html file and console log again as txt: The issue seems to be close to the safari one. The browser is fetching from n+1 which is what I can see in my logs. But I can't be sure if that is the exact same bug origin. Thank you |
|
@arkadash, has your log been recorded with this stream https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps.mpd ? |
|
Yes, I'm using that manifest url. |
|
I think there is two different problems. First one is due to automatic prunning process of buffers done by browser. In your first log, we can see that the video segment at time 308 is already loaded for dash.js. Video buffer range starts at time 310, so actually video segment is not already loaded. |
|
I'm not sure about the second case. I was able to reproduce this issue with many videos that has audio data at the described time. |
|
Hi @arkadash , both use cases can occur with all video streams according to me. I don't think that you can fix the issue with configuration. We have to fix it in the dash.js code. It sould be top priority issue to fix in the next release. Nico |
|
Getting the exact same issue here. Seeking to an unloaded segment (particularly where there is buffer before/after) leads to an eternal pinwheel.. even when seeking to a spot that previously worked in some cases. It seems it will "recover" itself once... if you seek to an already-loaded segment then seek back, but after that the next time it jams it's jammed for good. This can happen even when seeking to 0 leading me to believe it is not related to the mpd file or segmentation of the video. All segments are there, and the video plays perfectly when left to play organically on it's own, also seeking forwards works (even when seeking to the exact same unbuffered section as when trying to "seek backwards"). No network requests are made while this error is happening, leading me to believe the buffer was emptied (by the browser or the player) and the player isn't aware it needs to be reloaeded, and thus doesn't reload from the network (where it infact exists). here is the error after scrubbing backwards: and after some seeking/playing/pausing this happens in perpetuity: |
|
Just an update, it doesn't happen with 2.4.1 - https://cdnjs.cloudflare.com/ajax/libs/dashjs/2.4.1/dash.all.min.js This works fine and doesn't exhibit the same bug. additionally, it has far less debug "spam" in the console. |
|
Unfortunately it even happens with 2.4.1 (and lower versions). That's just a matter of being "lucky" enough and do the seek at the right timing. I am currently working on a fix that will share with all of you for testing as soon as it is ready. Thanks for all the detailed feedback |
|
Fixed in #2272 |
Environment
Steps to reproduce
https://www.npmjs.com/package/videojs-contrib-dash
Observed behaviour
The buffer never loads the requested time index
From that point on, it will just start loading chunks.
On dash 2.6.0 the same issue apears with reference to ScheduleController
Console output
The text was updated successfully, but these errors were encountered: