Add ABR switch interval configuration to prevent frequent quality changes #7385
Description
What do you want to do with Hls.js?
I would like to propose adding a new ABR configuration parameter similar to Shaka Player's switchInterval that would enforce a minimum time interval between quality level changes.
Problem Statement
Currently, hls.js provides excellent ABR sensitivity through abrEwmaFastLive, abrEwmaSlowLive, abrBandWidthUpFactor, and abrBandWidthFactor. However, in scenarios with
fluctuating network conditions (especially P2P streaming environments), this sensitivity can lead to frequent quality switches that negatively impact user experience.
Proposed Solution
Add a new configuration parameter: abrSwitchInterval (time in seconds) that enforces a minimum cooldown period between quality level changes.
// Proposed configuration
{
abrSwitchInterval: 30, // Minimum 30 seconds between quality changes
abrEwmaFastLive: 1, // Keep high sensitivity for bandwidth estimation
abrEwmaSlowLive: 3, // Keep responsive bandwidth estimation
// ... other existing configs
}
Benefits
- Maintain sensitivity: Keep responsive bandwidth estimation for accurate network condition detection
- Improve stability: Prevent jarring quality switches that hurt user experience
- Best of both worlds: Combine accurate network detection with stable playback quality
- Consistency with industry: Aligns with Shaka Player's proven approach
Use Cases
- P2P streaming environments with variable bandwidth
- Mobile networks with frequent fluctuations
- Live streaming scenarios requiring stable quality
Would the maintainers be open to this feature addition? I'm willing to contribute a PR if this aligns with the project's roadmap.
What have you tried so far?
I have experimented with existing ABR parameters to reduce switching frequency:
// Current workaround attempts
{
abrEwmaSlowLive: n, // Increased from default 9
abrEwmaFastLive: n, // Increased from default 3
abrBandWidthUpFactor: n, // Reduced from default 0.7
abrBandWidthFactor: n, // Increased from default 0.95
}
Limitations of Current Approach
- Trade-off dilemma: Making EWMA less sensitive reduces both switching frequency AND responsiveness to genuine network changes
- Suboptimal bandwidth detection: Higher EWMA values make the player slower to detect actual network improvements/degradations
- No direct control: Cannot separately control "detection sensitivity" vs "switching frequency"
Why Existing Parameters Aren't Sufficient
The current parameters work at the bandwidth estimation level, but what's needed is switch-level control. This would allow:
- Fast/accurate bandwidth estimation (good network awareness)
- Controlled switching behavior (stable user experience)
Similar to how Shaka Player successfully implements this pattern with their switchInterval configuration.