feat: preserveManualLevelOnError option #7280
Conversation
|
Hi @robwalch , My concern is that once the player switches to autoLevel due to a fragment error, HLS.js not loading the level that fragment error occurs. For example, if the manifest includes levels for 1080p, 720p, 480p, and 180p, and a 1080p fragment returns a 404 error, the player switches to 720p with autoLevel enabled. However, it never switches back to 1080p even when network conditions improve. The same happens if a 720p fragment fails it switches to 480p and stays there. Eventually, if a 480p fragment also fails, the player falls back to 180p and continues to load only that lower quality stream. If any one of the fragments returns a 404 error in 1080p level, why HLS.js doesn't switch back to a 1080p level after some time when auto level is enabled? Upon checking, I noticed that the getEstimate() method consistently returns a bitrate lower than the bitrate of the level where the last fragment error occurred. As a result, the player never level up, even if the network is good. I believe the new config |
These comments should be included in #7074 if they have not already.
If the connection is not delivering media at a high bitrate, that is not good enough to switch back up. If the connection really is good, and fragment errors stop, then the average will go back up.
Then this PR will not resolve #7074. The feature this PR adds is only for maintaining a manual selection even when it faults playback. Clearing Level.fragmentError counts after some period of stable playback, and easing any penalties on error, may be the best path forward for #7074. |
|
Yes, as robwalch said, this PR is not meant to resolve issue 7074, but is intended to address issue 7221 by maintaining the manual selection even when a playback error occurs. |
|
@robwalch could you please let me know which version this PR is expected to be included in? Also, could you provide an estimated release schedule? |
This PR will...
This PR introduces a new configuration option,
preserveManualLevelOnError. When this option is set totrue, hls.js will maintain the manually selected quality level even if network errors (such asFRAG_LOAD_ERROR,FRAG_LOAD_TIMEOUT,KEY_LOAD_ERROR, orKEY_LOAD_TIMEOUT) occur. If set tofalse(the default behavior), hls.js will switch back to auto level selection mode (loadLevel = -1) upon encountering such errors, attempting to find a rendition that can be loaded successfully.Why is this Pull Request needed?
Currently, when a user manually selects a specific quality level, hls.js defaults to switching back to automatic level selection if it encounters fragment loading or key loading errors. This behavior can be undesirable for users on unstable internet connections who prefer to remain on their chosen quality level, even if it means experiencing more retries or buffering, rather than having the player automatically switch to a different (often lower) quality. Furthermore, some users may wish to maintain their current quality setting even when facing playback errors, considering it the player developer's responsibility to resolve such issues rather than defaulting to a quality switch.
Services using hls.js may not always offer or want to provide automatic quality selection depending on the situation. Furthermore, they might prefer to implement different fallback mechanisms, making the current forced switch to auto quality in the player less ideal.
As discussed in issue #7221, developers previously had to implement workarounds by manually resetting
autoLevelCappingandminAutoBitrateon error events to achieve the desired behavior. This newpreserveManualLevelOnErrorflag provides a simpler and more direct way to control this behavior.Are there any points in the code the reviewer needs to double check?
getLevelSwitchActionmethod insrc/controller/error-controller.tsshould be reviewed to ensure it correctly respects thepreserveManualLevelOnErrorflag whenhls.autoLevelEnabledisfalse.preserveManualLevelOnErrorinsrc/config.tsis set tofalseto maintain existing default behavior.api-extractor/report/hls.js.api.mdcorrectly reflects the new configuration option.Resolves issues:
Checklist