Playback freezes when seeked to very beginning #3146
Comments
|
Hi @tomraut , according to my comprehension, it's another issue....we have the same behavior but origin is different. In this one, audio buffer is not fully cleared when the user seeks to 0. Nevertheless, in playbackController, commonEarliestTime is reseted....without no new audio data to push, so the internal seek command to 1.782s is not done..... :-( The question is why the audio buffer is not fully cleared..... Nico |
|
We have to reopen this as the fix applied in #3149 introduced some regression for live playback. We have to find a different solution for the problem described in this issue |
|
@tomraut : To be sure. Do you seek back using the progressbar or do you seek using the the API oder the native video element (video.currentTime = 0) |
|
@dsilhavy we have implemented our custom progressbar so all the seeking happens through API. |
|
I can only reproduce the problem when I manually set video.currentTime = 0:
When I use the Mediaplayer.seek function (which is the correct way to seek) it works fine for me. Mediaplayer.seek triggers a reset of the earliest time. This on the other hand will trigger a recalculation of the commonEarliestTime using the onBytesAppended function. @nicosang : Did you manage to reproduce it a different way? |
|
@dsilhavy are you testing with 3.0.2 version? If so, then I guess it is fixed and that is way MediaPlayer.seek(0) works correctly. With 3.0.1 version it didn't work. We are using MediaPlayer.seek() in our custom timeline implementation. |
|
Tested here in the nightly build: http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html There we had to remove the fix which was referenced in this issue as it introduced some regression as described above. |
|
@tomraut We applied a fix in #3307 can you please check if this solves the problem. It is already available in the nightly build: |
|
@dsilhavy seems to work better now regarding seeking meaning that it no longer freezes. However, if suggestedPresentationDelay is set to for instance 4, playback begins with buffering for 2-6 seconds leaving stream eventually from -23s from liveEdge. Same seems to happen also when seeked back to live after first seeking back within DVRWindow. If I don't set suggestedPresentationDelay, things work smoothly and liveEdge is approx. at -16s. |
|
@tomraut Is this behavior deterministic? From my experience: In your manifest is no valid segment for a live delay of 4 seconds. So the player tries to find the request/segment closest to this live delay. At some point this might be 23 seconds in other cases it might be 16. Depending on what is available at the time the manifest is requested. I will try to check again as well. |
|
@dsilhavy you are right, issue with SPD set to 4 is originated from our manifest. Thanks for pointing that out. |
|
Fixed in #3285 please reopen if any more problems occur. |
Environment
Steps to reproduce
Start to play asset and after some time try to seek to very beginning on the timeline.
Observed behaviour
Initial playback of the asset starts just fine but if user then seeks back to very beginning, dash.js is not able to play stream from there unless user seeks a little bit back to forward.
Console output
I had reported this already when testing 3.0.0 (#3042) and it was closed as "fixed" back then but issue still exists in 3.0.1. I guess issue is caused by presentationTimeOffset having different value than video's first t:
@nicosang @epiclabsDASH can you please comment how fixes #3045 and #3118 (both mentioned in closed issue #3042 ) should've fixed this kind of behaviour?
The text was updated successfully, but these errors were encountered: