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:
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.
When a QuotaExceededError is received after a push, we internally trigger a BUFFER_FULL_ERROR error, which is then handled by waiting a little, then reducing the wantedBufferAhead value progressively through a ratio system 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 and stop the content.
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).
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.
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)wantedBufferAheadto quickly fill-up memory until the device has to perform a strategy to free it.While doing this, I saw a collection of issues:
When calling the MSE
SourceBuffer.prototype.removeAPI 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
removecall 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.
When a
QuotaExceededErroris received after a push, we internally trigger aBUFFER_FULL_ERRORerror, which is then handled by waiting a little, then reducing thewantedBufferAheadvalue progressively through a ratio system and retrying.If after either the
wantedBufferAheadis 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 and stop the content.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).
The logic in (2) never considered that
wantedBufferAheadcould be set toInfinity, and dividingInfinityis not a very bright idea here. To make it work I decided that when there's a ratio set to less than1, awantedBufferAheadset toInfinitywould be equal to 5 minutes.