Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

video jumps backward instead of forward - since version 0.13.0 #2494

Closed
5 tasks done
jony89 opened this issue Jan 12, 2020 · 7 comments · May be fixed by tjenkinson/flowplayer-hlsjs#2
Closed
5 tasks done

video jumps backward instead of forward - since version 0.13.0 #2494

jony89 opened this issue Jan 12, 2020 · 7 comments · May be fixed by tjenkinson/flowplayer-hlsjs#2

Comments

@jony89
Copy link
Contributor

jony89 commented Jan 12, 2020

What version of Hls.js are you using?

0.13.0 or 0.13.1

What browser and OS are you using?

mac, high sierra, chrome

Checklist

  • The stream has correct Access-Control-Allow-Origin headers (CORS)
  • There are no network errors such as 404s in the browser console when trying to play the stream

Expected behavior

live sync position should be calculated correctly, and definitly should not return a value that is smaller than the current video time.

Actual behavior

htmlVideoElement.currentTime
25.010486
bufferEnd
25.041
start
8.126
config.maxFragLookUpTolerance
0.25
maxLatency
2
end
27.334

yet the calculated liveSyncPosition is 22.625999 which is smaller than the video current time.

config.liveSyncDurationCount = 1

Console output

Screen Shot 2020-01-12 at 3 29 17 PM

Screen Shot 2020-01-12 at 3 29 04 PM

Again, this works fine with hls.js version 0.12.4. while debugging 0.12.4 I don't even get to _ensureFragmentAtLivePoint.

@robwalch
Copy link
Collaborator

Hi @jony89. Thanks for the bug report. I'll take a look at how liveSyncPosition is being calculated.

Please include your player configuration and stream details (target duration, live, etc..) in the bug description.

For now, have you considered increasing liveMaxLatencyDuration or liveMaxLatencyDuration? The calculated max latency of 2 is pretty unrealistic for traditional hls playback.

@jony89
Copy link
Contributor Author

jony89 commented Jan 14, 2020

Please include your player configuration and stream details (target duration, live, etc..) in the bug description.

here is the custom configuration that I was using while getting this bug :

    startFragPrefetch: true,
    fragLoadingMaxRetry: 1,
    initialLiveManifestSize: 1,
    liveSyncDurationCount: 1,
    liveMaxLatencyDurationCount: 2,

everything else is by default.

For now, have you considered increasing liveMaxLatencyDuration or liveMaxLatencyDuration? The calculated max latency of 2 is pretty unrealistic for traditional hls playback.

yup, that is what I did.

@robwalch
Copy link
Collaborator

robwalch commented Jan 16, 2020

@jony89 _ensureFragmentAtLivePoint and computeLivePosition have not changed between v0.12.4 and v0.13.0 (computeLivePosition was only moved and we no longer seek while paused).

v0.12.4...v0.13.0#diff-92ec9c117a188d62ae4becd0540933d6L307

I don't see how this could be a regression, so please update the issue accordingly and provide the expected behavior for _ensureFragmentAtLivePoint given the details you've provided. Is the only expectation that we never seek backwards here?

As far as I can tell this is expected behavior based on your configuration. I believe it is being live sync position is being calculated correctly based on your settings and stream state, the issue is only that we seek backwards, instead of waiting for playback to underbuffer or hope we get an update to keep playback going.

The bufferEnd of 25.041 is less than end - maxLatency of 25.334, so the player seeked to liveSyncPosition. This is performed not only when you fall behind, but when you get too close to the edge. I don't see any logic that prevented that from happening. If you spot anything in the diff above let me know.

I do see a flaw in using computeLivePosition here in that it uses the stream start as input for sliding, so if your live stream does not maintain a consistent number of segments (for example the first is removed before a new one is added, or removed after a new one is added) the result will shift by one target duration. And at this point, we really just want to maintain maxLatency (not whatever min latency the sync position would give us).

@jony89
Copy link
Contributor Author

jony89 commented Jan 17, 2020

@jony89 _ensureFragmentAtLivePoint and computeLivePosition have not changed between v0.12.4 and v0.13.0 (computeLivePosition was only moved and we no longer seek while paused).

correct, but as I described, it is because _ensureFragmentAtLivePoint is being called in 0.13.x more than 0.12.4. the bug was exist in 0.12.x version as well. so the bug just got exposed on 0.13.x

Is the only expectation that we never seek backwards here?

yup. we can set the minimum return value to the videoHtmlElement.currentTime. and not trying to seek at all at this case. i.e we should not update videoHtmlElement.currentTime. I think there is no logic whatsoever to seek backward during live streaming.

I can try create PR with test for this if the logic is acceptable.

@robwalch
Copy link
Collaborator

Thanks @jony89 !

I can try create PR with test for this if the logic is acceptable.

That would help. Let me know either way. We can get a fix for this in 0.13.2

@jony89
Copy link
Contributor Author

jony89 commented Jan 18, 2020

@robwalch added PR

@robwalch
Copy link
Collaborator

Thanks @jony89!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Release Planning and Backlog
  
Top priorities
Development

Successfully merging a pull request may close this issue.

2 participants