Quality switching problems

[gpoole]

I'm having a little trouble with figuring out how to get automatic quality switching to work as I'd like, and I was wondering if anyone can please point me to anything I might be doing wrong or settings I might need?

I have an app using VOD streams with 4 quality levels, which I'm using to power a 360 video app where users navigate between virtual locations. My assumption about how hls.js would handle switching between these quality levels by default is something like this:

• if bandwidth drops, quality is aggressively stepped down to keep playback going
• if bandwidth improves, quality comes back up after a short delay to make sure the connection speed is high enough

Simulating a drop in network speed with throttling Chrome dev tools, I find the quality drops to the lowest quality stream fairly quickly, as expected. But, when I un-throttle the connection, it seems to take a very long time to come back up and I see even new fragments continuing to be loaded from the lowest quality stream for some time. It does seem to eventually come back up, but after longer than I'd like, and to the user if feels like the player is getting "stuck" in low quality.

I dug around a bit in the ABR controller in the Chrome debugger and from what I'm seeing during this "stuck" condition findBestLevel is returning level 0, but fragments from the lowest quality (level 3) stream are still being loaded. I tried messing around with setting abrBandWidthUpFactor to a higher number but it didn't seem to affect much. I thought maybe it was an issue with having already buffered and not flushing low quality fragments after conditions improve, but I found even with a small buffer size, new fragments will be loaded from the low quality stream for what seems to me like a long time.

I'm not passing any configuration currently, so here's how I'm initialising:

const hls = new Hls({
  enableWorker: true,
});

And here's an example of one of the m3u8 playlists I'm generating, which comes from ffmpeg:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=17811200,RESOLUTION=1920x960,CODECS="avc1.640033,mp4a.40.2",CLOSED-CAPTIONS=NONE
stream_0/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=13411200,RESOLUTION=1920x960,CODECS="avc1.640032,mp4a.40.2",CLOSED-CAPTIONS=NONE
stream_1/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=8940800,RESOLUTION=1920x960,CODECS="avc1.640032,mp4a.40.2",CLOSED-CAPTIONS=NONE
stream_2/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4505600,RESOLUTION=1920x960,CODECS="avc1.64001f,mp4a.40.2",CLOSED-CAPTIONS=NONE
stream_3/index.m3u8

Note the resolution is not accurate, each stream is a different resolution, but it's a workaround for Safari refusing to select >1080p streams on mobile regardless of conditions (for a 360 video player 4k does look meaningfully different from 1080p, even on small screens).

Is there anything I should be doing differently or could I perhaps have some issues with how I'm encoding the video that I should check for? Any advice would be much appreciated!

[robwalch]

Hi @gpoole,

The "Real-time metrics" and "Buffer & Statistics" tabs in the demo page are your friends when it comes to observing how HLS.js's BWE changes over time.

The configuration options you are looking for are abrEwmaFastVoD and abrEwmaSlowVoD. These can be changed to make the player adapt faster, but this also makes the estimate and possibly the experience less stable:
https://github.com/video-dev/hls.js/blob/v1.4.12/docs/API.md#abrewmafastvod

[gpoole]

Thanks @robwalch! I had not been using the demo page to debug my stream, so that will be a better approach. Changing abrEwmaFastVoD and abrEwmaSlowVoD makes sense, I'll give that a go.