Buffer hole on level switch
What version of Hls.js are you using?
1.4.7
What browser (including version) are you using?
Chrome v114.0.5735.198 (Official Build) (arm64)
What OS (including version) are you using?
MacOS
Test stream
https://hlsjs.video-dev.org/demo/?src=https%3A%2F%2Fvz-ced6ec5f-c54.b-cdn.net%2F55d2cc15-6524-48f7-aa7f-677d41d17eb2%2Fplaylist.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==
Configuration
{
"debug": true,
"enableWorker": true,
"lowLatencyMode": true,
"backBufferLength": 90,
"maxStarvationDelay": 4
}
Additional player setup steps
No response
Checklist
- [X] The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
- [X] The issue occurs in the stable client (latest release) on https://hlsjs.video-dev.org/demo and not just on my page
- [X] The issue occurs in the latest client (main branch) on https://hlsjs-dev.video-dev.org/demo and not just on my page
- [X] The stream has correct Access-Control-Allow-Origin headers (CORS)
- [X] There are no network errors such as 404s in the browser console when trying to play the stream
Steps to reproduce
- Play the stream
- Video freezes for few seconds when level is switched
Expected behaviour
Video doesn't switch on resolution change
What actually happened?
Problem occured only on Chrome. Safari and Firefox are not experiencing this issue.
There is a buffer hole for some reason that starts on 3.921333 second of the video and ends on 3.988 Buffer state: Duration: 9.215999 Buffered: [0.021333, 3.921333] [3.988, 9.215999] Seekable: [0, 9.215999] Played: [0, 9.215999] Buffer for audio contains:[0, 9.215999] Buffer for video contains:[0.021333, 3.921333] [3.988, 9.187999] Dropped frames: 0 Corrupted frames: 0 TTFB Estimate: 5.000 Bandwidth Estimate: 32859297.994
Console output
7.655 | Buffer stalled error
Chrome media internals output
No response
Also having this exact issue: https://hlsjs.video-dev.org/demo/?src=https%3A%2F%2Fvz-dda919cc-4fa.b-cdn.net%2Fae4b9e63-5710-47fc-8b28-1c4123d7144a%2Fplaylist.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==
Any fix available? Current workaround right now is setting a startLevel at 2 for me in the config, but that isn't ideal for slower connections.
~~Actually, looks to be resolved or atleast minimized in the hlsjs-dev demo.~~ EDIT: Nevermind, upon testing on desktop the issue still persists in hls-dev
I tried with #5806. It addresses the gap in @M-Joyce's sample, but for your example @tvinko, the decode timestamps align perfectly, however the subsequent append still produces a gap.
Current workaround right now is setting a startLevel at 2 for me in the config, but that isn't ideal for slower connections.
That's an excellent work-around.
Can you each confirm whether or not the gap is only present in Chrome? If that's the case we might want to add come comments with additional reproduction steps to https://bugs.chromium.org/p/chromium/issues/detail?id=1478681
Since this is fairly common in Chrome and the stall behavior in Chrome is bad when crossing gaps, I may consider adding logic to preempt the stall after crossing video TimeRanges with a nudge-seek.
Can you each confirm whether or not the gap is only present in Chrome? If that's the case we might want to add come comments with additional reproduction steps to https://bugs.chromium.org/p/chromium/issues/detail?id=1478681
Just did some testing.
Edge: Still freezes Chrome: Still freezes Chrome android: still freezes Samsung Internet Browser (galaxy s22+): Still freezes Edge with Internet Explorer mode on: Does not freeze
As for https://github.com/video-dev/hls.js/pull/5806, is this something I can pull down locally and test myself? Is it part of the dev hls releases? The issue still happens in chrome on hlsjs-dev.
As for https://github.com/video-dev/hls.js/pull/5806, is this something I can pull down locally and test myself? Is it part of the dev hls releases? The issue still happens in chrome on hlsjs-dev.
See the Cloudflare Pages build check Details link https://github.com/video-dev/hls.js/pull/5806/checks?check_run_id=16603150891 > https://bugfix-chrome-avc-gaps-m2ts.hls-js-4zn.pages.dev/
Tested my issue on https://bugfix-chrome-avc-gaps-m2ts.hls-js-4zn.pages.dev/ and it resolves the freeze. Video continues playing normally, with no or unnoticeable buffer.
Since this is fairly common in Chrome and the stall behavior in Chrome is bad when crossing gaps, I may consider adding logic to preempt the stall after crossing video TimeRanges with a nudge-seek.
@tvinko, I'll revisit more proactive nudging over video buffer gaps in v1.6. I've done what I could to repair remuxed mp4 fragments before append (#5805, #5806) and prevent overlapping segment selection on switch (#5804) for this next release.
Since the symptom involves no rendering of video past the gap / new TimeRange, followed by a stall, we should also look at how dropped frames are measured and consider a combined solution with late append reporting in https://github.com/video-dev/hls.js/compare/master...feature/video-buffer-starved
Related issue and novel workaround https://github.com/w3c/media-source/issues/160#issuecomment-1776215889
Related issue and novel workaround w3c/media-source#160 (comment)
I like "novel workaround" instead of the name I had been using :) Regardless, I've recalled further complications (mostly around audio buffered gaps) that might impair effective use of that workaround.