make frameRate check configurable on level up/down transitions

[sojeong-hwang]

This PR will...

This PR will make frameRate check configurable during ABR up/down transitions.

Why is this Pull Request needed?

Currently, the frameRate-based level switching is hardcoded and cannot be disabled.
This PR allows developers to control it via config for more flexible ABR tuning.

Are there any points in the code the reviewer needs to double check?

No special points.

Resolves issues:

N/A

[krseager]

Is there a reason we wouldn't want to just have a config value that sets a framerate cap? i.e. 60fps / 30fps?

[robwalch]

I don't think unblocking selection behavior via config is a good solution to working around content that does not follow best practices when providing frame rates at various bitrates (an example with 360-720p@30, 1080p@60, and [email protected] was given offline).

First, we could loosen the checks to allow switching between almost identical frame rates. That could allow switching straight to a higher bitrate at 29.997 from 30 fps. There would still be a chance to switch up to 60fps and then not switch up any higher. The user should be presented with the resolution and frame-rates to allow manual override in these cases. Allowing the client to automatically bounce back and forth between rates should be avoided.

Adding a frameRate (preferred) and maxFrameRate options to the videoPreference: VideoSelectionOption config options interface for initial selection and capping would be preferred. You might also consider making capping part of the fps-controller, (see capLevelOnFPSDrop) but that would entail more of a refactor as that controller is meant to limit selection based on performance, not the variant frame-rate. It could do both, or either, if a simple flat capLevelByFrameRate option is preferred.

[robwalch]

Suggested-Workaround: If you really want to force hls.js to ignore level frameRate than change the parsed values after playback has started on hls.levels to all be the same. It may seem like a hack, but it's a valid workaround after level.supportedPromise is resolved.

[robwalch]

First, we could loosen the checks to allow switching between almost identical frame rates

Suggested change

	(upSwitch &&
	currentFrameRate > levelInfo.frameRate &&
	!isUpSwitchToLowerFrameRate) ||
	(!upSwitch &&
	currentFrameRate > 0 &&
	currentFrameRate < levelInfo.frameRate) ||
	currentFrameRate < levelInfo.frameRate &&
	!isDownSwitchToHigherFrameRate) ||
	(upSwitch && currentFrameRate > Math.ceil(levelInfo.frameRate)) ||
	(!upSwitch &&
	currentFrameRate > 0 &&
	Math.ceil(currentFrameRate) < levelInfo.frameRate) ||

[sojeong-hwang]

Thanks for the suggestion.

I’ll apply the suggested workaround (overwrite hls.levels frameRate values after level.supportedPromise resolves) to unblock testing, and close this PR.
I appreciate the review and the guidance if the workaround introduces anything unexpected I’ll open a follow-up PR with a proper implementation or revert as needed.