Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix some issues that may arise on BUFFER_FULL situations
I'm working on heuristics to determine adaptively how much the current device can hold in its audio and video buffers. To quickly iterate on this, I'm setting a very high (or even `Infinity`) `wantedBufferAhead` to quickly fill-up memory until the device has to perform a strategy to free it. While doing this, I saw a collection of issues: 1. When calling the MSE `SourceBuffer.prototype.remove` API to remove buffer (which we already do in some clean-up strategies), putting an end timestamp equal to the start timestamp leads to an Error (as defined by MSE). A long-term fix would be to just avoid doing the MSE `remove` call as close as possible to our MSE abstraction, but for now I also added a check at the initial call (which also makes sense). I'm thinking of also adding the long-term fix, but not in this PR as I want it to have the less risks possible. 2. When a `QuotaExceededError` is received after a push, we trigger a `BUFFER_FULL_ERROR` error, which is then handled by, waiting a little, then reducing the `wantedBufferAhead` value progressively through a ratio and retrying. If after either the `wantedBufferAhead` is too low (less than 2 seconds) or the ratio is too low (less or equal to 0.05), we trigger the error through the API. Turns out that last part was broken. We never triggered the error, leading to possibilities such as infinite rebuffering (in extreme cases hopefully never really encountered). 3. The logic in (2) never considered that `wantedBufferAhead` could be set to `Infinity`, and dividing `Infinity` is not a very bright idea here. To make it work I decided that when there's a ratio set to less than `1`, a `wantedBufferAhead` set to `Infinity` would be equal to 5 minutes.
- Loading branch information