Faster switching by replacing segments close to the playhead

[wilaw]

Currently the time it takes to switch bitrates is equivalent to the length of the forward buffer, since we append the new bitrate segments at the leading edge of the buffer.

We could have much faster switches if we instead started loading the new bitrate at the current playhead position . MSE sourceBuffers are resilient over this replace-in-place mode and we should take advantage of it. A practical use case is having adaption sets which represent different views on to the same sporting event and being able to switch between them quickly. Another use case for switching within representaitons would be to limit the player to a lower bitrate when it is in page but then allow the top bitrate if the user goes to fullscreen. Today, with a regular steady state buffer, the user would see 30s of lower quality in fullscreen mode before the higher qulaity became visible.

Complications that might arise from doing this:

1. Our current logic for when to load a segment is based on looking at the available buffer. If we had a 30s buffer and we switched bitrates, we would want to load the new bitrate at the playhead position (buffer length of 0). However, we would have 30s of buffer ahead of that and therefore the load would never happen. We could prune the forward buffer, but that would put us at risk of rebuffering. So we'd need to track the replacement edge separately from the buffer edge and that added complexity can lead to robustness problems.
2. We'd want an API on Mediaplayer to control this behavior.

We do have an API and feature that somewhat addresses this issue already - setTrackSwitchModeFor(type, mode) . However it has two weaknesses - 1) It only works on track switches and not bitrate switches and 2) it implements the very brute force approach of deleting the entire forward buffer when switching which puts the player at strong risk of rebuffering. If we kept the forward buffer for safety, but tracked our replacement position separately, I think we could have the best of both worlds - buffer resilience and fast switching.

Cheers

Will

[richardbushell]

Great call! We currently allow higher bitrates upon entering Fullscreen and this functionality seems logical to Switch Up asap if possible, but obviously never Switch Down (whether pruning or overwriting currently buffered segments).

[dsparacio]

Linking duplicate issue #794

[dsparacio]

Added with PR #1434