Backward-seeking frame in video get stuck

[salesh]

What version of Hls.js are you using?

v1.4.3

What browser (including version) are you using?

Chrome Version 113.0.5672.92 (Official Build) (64-bit)

What OS (including version) are you using?

Ubuntu 20

Test stream

https://5be196f4-a905-4a83-a0d4-e04cf2e9fe9f.s3.eu-central-1.amazonaws.com/test-two/channel-a_adaptive.m3u8

Configuration

{
  "debug": true,
  "enableWorker": true,
  "lowLatencyMode": true,
  "backBufferLength": 90,
  "maxBufferHole": 0,
  "maxFragLookUpTolerance": 0
}

Additional player setup steps

No response

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

As suggested in #4956 (comment)
I am opening a separate issue.

Currently, we are using in PROD your previous suggestion

I did rebase https://github.com/video-dev/hls.js/compare/bugfix/nudging-over-buffer-hole-when-paused on v1.3.1 and it works.
ref. #5093 (comment)

We are using hls.js in combination with ngx-videogular for live-streaming and playing videos.
We are using Ant Media for producing streams.

The easiest thing for us was to stream test Bunny stream through Ant Media (to avoid copyrights)
https://5be196f4-a905-4a83-a0d4-e04cf2e9fe9f.s3.eu-central-1.amazonaws.com/test-two/channel-a_adaptive.m3u8

[1] Go to https://hls-js.netlify.app/demo
[2] Use

{
  "debug": true,
  "enableWorker": true,
  "lowLatencyMode": true,
  "backBufferLength": 90,
  "maxBufferHole": 0,
  "maxFragLookUpTolerance": 0
}

as suggested by #4956
[3] seek somewhere in the middle and pause the video
[4] add function in the console

const seekFrame = () => {
	const video = document.getElementById('video');
	const newCurrentTime = video.currentTime - 0.04; // 25 FRAME seek
	video.currentTime = newCurrentTime;
	console.log(newCurrentTime);
} 

[5] keep calling till you reach to
[warn] > skipping hole, adjusting currentTime from 459.988593 to 460.088593

Observations:

This issue only happens when we are producing adaptive bitrate

Let me know if I can help with more details.
Thank you, Rob!

Expected behaviour

We should be able to do back frame seeking and not hit the wall.

What actually happened?

It hits the wall and can't seek anymore

Console output

It's easily reproducible with a test stream on https://hlsjs.video-dev.org/demo

Chrome media internals output

No response

[robwalch]

Confirmed. When seeking to the start of a buffered segment where video has been buffered, but audio starts after the playhead, the gap-controller detects "start gap" conditions because the combined buffer is empty at the playhead, so it seeks forward.

[robwalch]

Hi @salesh,

Let me know if #5502 resolves the issue for you.

[salesh]

Hey @robwalch thank you very much for this!

There was an issue with our environment, so it took a little longer...
Fix works!
Thank you very much!

I tried to look for some buy me a coffee or if there is a way to buy you some beer :)