Do Custom ABR Controllers really need get/set `autoLevelCapping`?

[lpommers]

What do you want to do with Hls.js?

I'm working with a Custom ABR Controller.

The documentation for a Custom ABR Controller states that it should have a:

• get/set autoLevelCapping: capping/max level value that could be used by ABR Controller

However, I've noticed that the Default ABR Controller (https://github.com/video-dev/hls.js/blob/master/src/controller/abr-controller.ts) has no property for autoLevelCapping and no code throughout hls.js references abrController.autoLevelCapping. It also appears that all autoLevelCapping management happens through the CapLevelController (https://github.com/video-dev/hls.js/blob/master/src/controller/cap-level-controller.ts).

Should Custom ABR Controllers really have a get/set for autoLevelCapping? Or should it rather be done through a custom CapLevelContoller?

I can submit a PR to clean up the docs for Custom ABR Controllers once I'm certain of the correct behavior.

What have you tried so far?

My own Custom ABR Controller never has its autoLevelCapping values read or set.

[robwalch]

If you could define an interface for abr controller classes to implement in src/types and link to it in the docs, that would be most helpful. The requirements I see are:

• nextAutoLevel getter/setter (internal abr-controller only leverages the setter prior to start. While it might afterwards I think it is more likely to overwrite it first)
• destroy
• clearTimer (called from player instance currentLevel setter. Intention is to stop abandon rules check polling until another fragment is loaded)

We could probably remove the public clearTimer call if the internal abr-controller responded properly to the actions of aborting the current fragment in immediateLevelSwitch. We are looking out for stats.aborted but maybe a bug (part stats issue addressed in #4825) prevented it from working or the warning log ('frag loader destroy or aborted, disarm abandonRules') was annoying and this was added to suppress it.