fix: Only check for bad seeks after seeking and an append #1195
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1195 +/- ##
==========================================
- Coverage 86.61% 86.60% -0.01%
==========================================
Files 39 39
Lines 9651 9652 +1
Branches 2235 2231 -4
==========================================
Hits 8359 8359
- Misses 1292 1293 +1
Continue to review full report at Codecov.
|
| const audioBuffered = sourceUpdater.audioBuffer ? sourceUpdater.audioBuffered() : null; | ||
| const videoBuffered = sourceUpdater.videoBuffer ? sourceUpdater.videoBuffered() : null; | ||
|
|
||
| // verify that at least two segment durations have been | ||
| // appended before checking for a gap. | ||
| const twoSegmentDurations = (this.media().targetDuration - Ranges.TIME_FUDGE_FACTOR) * 2; | ||
| const bufferedToCheck = [audioBuffered, videoBuffered]; | ||
|
|
||
| for (let i = 0; i < bufferedToCheck.length; i++) { | ||
| // skip null buffered | ||
| if (!bufferedToCheck[i]) { | ||
| continue; | ||
| } | ||
|
|
||
| if ( | ||
| closeToBufferedContent({ | ||
| buffered, | ||
| audioBuffered: sourceUpdater.audioBuffer ? sourceUpdater.audioBuffered() : null, | ||
| videoBuffered: sourceUpdater.videoBuffer ? sourceUpdater.videoBuffered() : null, | ||
| targetDuration: this.media().targetDuration, | ||
| currentTime | ||
| }) | ||
| ) { | ||
| const nextRange = Ranges.findNextRange(buffered, currentTime); | ||
| const timeAhead = Ranges.timeAheadOf(bufferedToCheck[i], currentTime); | ||
|
|
||
| seekTo = nextRange.start(0) + Ranges.SAFE_TIME_DELTA; | ||
| this.logger_(`Buffered region starts (${nextRange.start(0)}) ` + | ||
| ` just beyond seek point (${currentTime}). Seeking to ${seekTo}.`); | ||
| // if we are less than two video/audio segment durations behind, | ||
| // we haven't appended enough to call this a bad seek. | ||
| if (timeAhead < twoSegmentDurations) { | ||
| return false; | ||
| } | ||
| } | ||
|
|
||
| this.tech_.setCurrentTime(seekTo); | ||
| return true; | ||
| const nextRange = Ranges.findNextRange(buffered, currentTime); | ||
|
|
||
| // we have appended enough content, but we don't have anything buffered | ||
| // to seek over the gap | ||
| if (nextRange.length === 0) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Any specific reason for moving all of this out of a separate function?
There was a problem hiding this comment.
After reducing the function to just the twoSegmentDurations check and the nextRange check it seemed silly to call findNextRange in the helper function and then directly afterwards since we need access to it. So I think it made more sense to move the helper function in here.
Co-authored-by: Garrett Singer <gesinger@gmail.com>
|
We have another test stream that this PR seems to fix #1202 |
|
Hi, I was having a similar issue over at #1202. I built and tested your most recent commit c6144ad, as @gkatsev mentioned it could also fix my issue. I can confirm that it does indeed fix the dramatic several second skip-back and/or infinite looping that I was experiencing, so thank you for that. However, it still does not play as cleanly as all the other players I mentioned in my post. After your fix, I now experience a stutter instead of the jump-back, basically a half second or less pause in both the video and the audio which is still quite disruptive for the user as you can see the pause and you hear a staticy audio artifact. Much better though, thanks. |
|
Hi, But issue still persist. player.currentTime(900); //Like this But if network fluctuates, it playing segments from backward(old chunks). How it should behave: Thank You |
Description
In our current code we run
fixesBadSeeks_()on tech waiting and our emulated tech waiting. This is problematic because at the time of tech waiting we won't have removed content from our segment loaders buffers. This means that any seek backwards withintargetDurationwill be skipped as a gap.Example:
Previously we check to see if an append had happened by checking the buffer, but that isn't specific enough as large target durations will have issues as seen above. Now we use seeking events.