Description

This change requires videojs/video.js#5024, which takes care of the UI and API aspects of buffering.

SourceHandlers that use MSE have a problem: if they push a segment into a SourceBuffer and then seek close to the end, playback will stall and/or there will be a massive downswitch in quality. The general approach to fixing this that was discussed on slack was by setting the playback rate of the player to zero, buffering all that was required, and then restoring the previous playback rate. In my implementation, I've done this in the source handler.

Additionally, there is a new seekDeadline option for the source handler which controls how long a seek should take to resume. When seeking, the master playlist controller calculates the maximum bandwidth playlist for all requests needed to complete a full seek. The calculations are done using maxBandwidthForDeadlineSelector, which is essentially just minRebufferMaxBandwidthSelector renamed.

Taken together, this makes the seeking behavior vastly improved:

• playback is on highest rate
• seek is requested by client to right before the end of a segment
• currentTime of video is updated, playback pauses, spinner appears, player.seeking() is now true
• buffer is sufficiently filled at new time in reasonable timeframe, downswitching if necessary
• two segments at lower rate are now in buffer
• playback resumes, spinner disappears, player fires playback events, player.seeking() is now false
• next segment download is at seeking rate (i.e. the rate calculated when making the seek)
• pre-seek quality is resumed bufferLowWaterLine seconds after resuming playback

Specific Changes proposed

• Added seekDeadline option for controlling how long a seek should take to resume
• seeking() is deferred from the tech to the SourceHandler
• setCurrentTime stores the current playback rate and sets the tech's playback rate to zero
• Inside SegmentLoader#handleUpdateEnd_, if we have enough buffer that we can make another request in that time, fire buffered on this
• The MasterPlaylistController receives the buffered event and restores the previous playback rate
• minRebufferMaxBandwidthSelector has been renamed to maxBandwidthForDeadlineSelector, and made more generic
  • it now accepts a needsExtraRequest callback which is used to determine whether another request must be made
  • instead of returning rebufferingImpact, it now just returns requestTimeEstimate
• For the deadline passed to maxBandwidthForDeadlineSelector, abortRequestEarly_ uses either the current calculation (when not seeking) or the time elapsed since seeking started
• Math inside abortRequestEarly_ is now a bit simpler because it's now using the requestTimeEstimate instead of rebufferingImpact
• The quality used when seeking is determined by how long it will take to get the number of segments needed to fill the buffer after the seek
• The MPC's fastQualityChange_ and smoothQualityChange_ now accept a nextPlaylist option which will be used instead of this.selectPlaylist() when given
• The playback watcher has been modified to not bork when the playback rate is zero and nothing is happening

Requirements Checklist

• Feature implemented / Bug fixed
• If necessary, more likely in a feature request than a bug fix
  • Unit Tests updated or fixed
  • Docs/guides updated
  • Example created (starter template on JSBin)
• Reviewed by Two Core Contributors

Notes

• This is implemented assuming that the video segment loader will always finish after the other segment loaders. I also made an implementation that guarantees all segment loaders have enough data, if you want to compare what that would be like. I found this to be much more concise which is why it gets the PR.
• Unfortunately, as it turns out, Make goalBufferLength and bufferLowWaterLine use time since last seek for calculation videojs-contrib-hls#1239 can't be added to this PR. The goal of that PR was to upswitch immediately post-seek, so that quality would dip only for those segments needed to fill the buffer post-seek. However, since the same segment # can be downloaded twice while upswitching (once at the old rate, once at the new rate), the buffer will sometimes run out post-seek. So, for now, it will take bufferLowWaterLine seconds post-seek before an upswitch is made to the pre-seek quality. Eventually I'd like to fix this, but I think for now it's not super important.
• Because of the way things are being done with the playbackRate, after the first segment is downloaded, the video frame changes to be the frame at currentTime while the second segment is downloaded. This is kinda weird from a UI point of view, but I think it's acceptable.