capLevelToPlayerSize won't support multiple levels with identical resolutions

[MickCoelho]

What version of Hls.js are you using?

1.4.3

What browser (including version) are you using?

Version 114.0.5735.198 (Official Build) (arm64)

What OS (including version) are you using?

MacOS 13.3.1

Test stream

https://hlsjs.video-dev.org/demo/?src=https%3A%2F%2Fdrg2yeq22ha9g.cloudfront.net%2Fhlsjs-test%2FBig_Buck_Bunny_1080_10s_1MB.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==

Configuration

{
  "debug": true,
  "ignoreDevicePixelRatio": true,
  "capLevelToPlayerSize": true,
  "testBandwidth": true
}

Additional player setup steps

Main playlist:

#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=2880000,RESOLUTION=1440x813,SCORE=2.0,CODECS="avc1.64001e"
Big_Buck_Bunny_1080_10s_1MB_1440.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=864000,RESOLUTION=1440x813,SCORE=1.0,CODECS="avc1.64001e"
Big_Buck_Bunny_1080_10s_1MB_1440_low-bw.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2160000,RESOLUTION=1080x610,SCORE=2.0,CODECS="avc1.64001e"
Big_Buck_Bunny_1080_10s_1MB_1080.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=648000,RESOLUTION=1080x610,SCORE=1.0,CODECS="avc1.64001e"
Big_Buck_Bunny_1080_10s_1MB_1080_low-bw.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=1440000,RESOLUTION=720x406,SCORE=2.0,CODECS="avc1.64001e"
Big_Buck_Bunny_1080_10s_1MB_720.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=432000,RESOLUTION=720x406,SCORE=1.0,CODECS="avc1.64001e"
Big_Buck_Bunny_1080_10s_1MB_720_low-bw.m3u8

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• The issue occurs in the stable client (latest release) on https://hlsjs.video-dev.org/demo and not just on my page
• The issue occurs in the latest client (main branch) on https://hlsjs-dev.video-dev.org/demo and not just on my page
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

1. Open the demo
2. open inspect panel and go to network requests (filtering then by .ts)
3. set capLevelToPlayerSize and ignoreDevicePixelRatio to true in the config
4. resize the video player smaller than 1300px wide
5. click "Apply"
6. see the ..._1080_low-bw... segments are loaded

Expected behaviour

When the network isn't throttled, the level-controller should ignore the low-bw segments and instead play the segments with higher quality while still capping the resolution.

What actually happened?

When setting both capLevelToPlayerSize and ignoreDevicePixelRatio to true it seems like the level-controller will choose the first matching resolution in the main playlist. My basic understanding is that, HLS.js sorts the levels only based on the bandwidth/bitrate and when capping the levels (based on the resolution) will get the first matching level that isn't above the client's resolution.
In the example, it'll load the 1080_low-bw.m3u8 sub-playlist and relative segments instead of going for the 1080.m3u8 playlist

Console output

N/A

Chrome media internals output

No response

[robwalch]

Hi @MickCoelho,

Isn't that what this check is for?

hls.js/src/controller/cap-level-controller.ts

Lines 267 to 276 in 186b1e5

	// Levels can have the same dimensions but differing bandwidths - since levels are ordered, we can look to the next
	// to determine whether we've chosen the greatest bandwidth for the media's dimensions
	const atGreatestBandwidth = (curLevel, nextLevel) => {
	if (!nextLevel) {
	return true;
	}
	return (
	curLevel.width !== nextLevel.width ||
	curLevel.height !== nextLevel.height

The issue is that when sorted by bitrate, your variants are no longer in order by resolution. This will be addressed in v1.5.0.

[MickCoelho]

@robwalch that should work indeed, but I think levels are ordered by bitrates and not by resolution, so this script just gets the lowest quality level for a set resolution.