Timeout Occurs and Playback Reverts to an Earlier Position When Manipulating Network Bandwidth

[kakao-wise-kim]

What version of Hls.js are you using?

v1.5.15, v1.5.16, v1.5.17

What browser (including version) are you using?

Chrome 131.0.6778.140 (arm64)

What OS (including version) are you using?

mac os 14.6.1(23G93)

Test stream

live stream

Configuration

{
  "debug": true,
  "enableWorker": true,
  "liveDurationInfinity": true,
  "lowLatencyMode": false,
  "backBufferLength": 90,
  "liveSyncDuration": 4,
  "maxMaxBufferLength": 4,
  "maxBufferLength": 4,
  "liveSyncOnStallIncrease": 1,
  "maxLiveSyncPlaybackRate": 1.1,
  "autoStartLoad": true,
  "levelLoadingTimeOut": 3000,
  "levelLoadingRetryDelay": 100,
  "maxTimeToFirstByteMs": 1000,
  "levelLoadingMaxRetry": 5
}

Additional player setup steps

using demo page.

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

[Preparation]
• Prepare a live stream that supports adaptive bitrate. Set up the test environment to include a quality level below 1 Mbps.
• On macOS, prepare the Network Link Conditioner. (For Windows, prepare NetLimiter.)
• Create a profile in Network Link Conditioner that limits up/down speed to 1 Mbps.

[Reproduction Steps]
1. Play the live stream without limiting the network speed.
2. Set the network speed slightly above the bitrate of the lowest quality level of the prepared live stream to trigger the abandon rule.
3. When the abandon rule is triggered, an HTTP request timeout occurs during the switching process.
4. Playback returns to the beginning of the buffer and resumes playing.

Expected behaviour

A timeout occurs. Even after configuring retry and timeout settings, the timeout issue persists.
Additionally, the playback position moves backward.
Upon searching the actual CDN logs, there is no evidence of the request being received.
It is suspected that the player is failing to properly http abort and request.

What actually happened?

The playback position moves backward.
Logs indicating HTTP timeouts are continuously being generated.

Console output

main.js:24929 Error event: {type: 'networkError', details: 'audioTrackLoadTimeOut', fatal: false, url: 'https://~~~~/main/a0_a2/a2.m3u8', loader: XhrLoader, …}context: {id: 0, groupId: 'a2', level: null, responseType: 'text', type: 'audioTrack', …}details: "audioTrackLoadTimeOut"error: Error: A network timeout occurred while loading audioTrack id: 0 group-id: "a2"
    at PlaylistLoader.handleNetworkError (http://localhost:5174/node_modules/.vite/deps/hls__js.js?v=0f0cd432:3580:19)
    at Object.onTimeout (http://localhost:5174/node_modules/.vite/deps/hls__js.js?v=0f0cd432:3460:14)
    at XhrLoader.loadtimeout (http://localhost:5174/node_modules/.vite/deps/hls__js.js?v=0f0cd432:22108:19)errorAction: {action: 2, flags: 1, nextAutoLevel: 3, retryConfig: {…}, retryCount: 0, …}fatal: falselevelRetry: trueloader: XhrLoader {xhrSetup: null, requestTimeout: 303, retryTimeout: undefined, retryDelay: 0, config: {…}, …}networkDetails: XMLHttpRequest {onreadystatechange: null, readyState: 0, timeout: 0, withCredentials: false, upload: XMLHttpRequestUpload, …}stats: LoadStats {aborted: true, loaded: 0, retry: 0, total: 0, chunkCount: 0, …}type: "networkError"url: "https://~~~~/main/a0_a2/a2.m3u8"[[Prototype]]: Object

main.js:24929 Error event: {type: 'networkError', details: 'levelLoadTimeOut', fatal: false, url: 'https://~~~/main/v0_v7/v7.m3u8', loader: XhrLoader, …}context: {id: 0, level: 0, pathwayId: undefined, responseType: 'text', type: 'level', …}details: "levelLoadTimeOut"error: Error: A network timeout occurred while loading level: 0 id: 0
    at PlaylistLoader.handleNetworkError (http://localhost:5174/node_modules/.vite/deps/hls__js.js?v=0f0cd432:3580:19)
    at Object.onTimeout (http://localhost:5174/node_modules/.vite/deps/hls__js.js?v=0f0cd432:3460:14)
    at XhrLoader.loadtimeout (http://localhost:5174/node_modules/.vite/deps/hls__js.js?v=0f0cd432:22108:19)errorAction: {action: 5, flags: 0, retryConfig: {…}, retryCount: 0, resolved: true}fatal: falselevelRetry: trueloader: XhrLoader {xhrSetup: null, requestTimeout: 304, retryTimeout: undefined, retryDelay: 0, config: {…}, …}networkDetails: XMLHttpRequest {onreadystatechange: null, readyState: 0, timeout: 0, withCredentials: false, upload: XMLHttpRequestUpload, …}stats: LoadStats {aborted: true, loaded: 0, retry: 0, total: 0, chunkCount: 0, …}type: "networkError"url: "https://~~~~/main/v0_v7/v7.m3u8"[[Prototype]]: Objectconstructor: ƒ Object()hasOwnProperty: ƒ hasOwnProperty()isPrototypeOf: ƒ isPrototypeOf()propertyIsEnumerable: ƒ propertyIsEnumerable()toLocaleString: ƒ toLocaleString()toString: ƒ toString()valueOf: ƒ valueOf()__defineGetter__: ƒ __defineGetter__()__defineSetter__: ƒ __defineSetter__()__lookupGetter__: ƒ __lookupGetter__()__lookupSetter__: ƒ __lookupSetter__()__proto__: (...)get __proto__: ƒ __proto__()set __proto__: ƒ __proto__()

Chrome media internals output

[robwalch]

Are you able to reduce this issue in v1.6.0-beta.2?

This issue has been reported before and has been addressed. The work is spread across several PRs. You can find out more by starting at #6872.

[robwalch]

Duplicates #6689. Fixed with #6763.

[kakao-wise-kim]

Hi. robwalch.
I tested using version 1.6.0-beta-2.
The bug where the playback position would revert to an earlier point has been resolved.
However, the video seeks to a more recent position, while the audio fails to synchronize with the video’s position.
This issue can occur more frequently when the timeout is set to a shorter duration.
As a result, playback still does not function properly.

[robwalch]

However, the video seeks to a more recent position, while the audio fails to synchronize with the video’s position.

I'm surprised #6857 doesn't address this issue. But I'm not sure this is an issue with alignment. I think your audio playlist requests are being blocked by the network throttler.

Can you provide a sample stream to reproduce the issue?
Are the media timestamps in your audio playlist segments aligned with the video segment timestamps?
Why are playlist updates and/or segments timing out? Are you over throttling the network or otherwise blocking critical requests?

[robwalch]

Does the above work better with v1.6.0-beta.2 with default config? These setting are problematic and should not be used under bad network conditions:

{

  "maxMaxBufferLength": 4,
  "maxBufferLength": 4,
  "levelLoadingTimeOut": 3000,
  "levelLoadingRetryDelay": 100,
  "maxTimeToFirstByteMs": 1000,
  "levelLoadingMaxRetry": 5
}

[robwalch]

I'm unable to reproduce with the MUX LL-HLS test stream (https://stream.mux.com/v69RSHhFelSm4701snP22dYz2jICy4E4FUyk02rW4gxRM.m3u8) with lowLatencyMode: false throttled to 3G (780 kbps down) using Network Link Conditioner. ON v1.6.0-beta2, playback switches to the 700700bps (max with video/audio: 443/198 kb/s) variant and is maintained (barely).

[kakao-wise-kim]

@robwalch

I am currently testing in a standard HLS environment, not Low Latency HLS.
The issue occurs while testing with a live stream, with the LiveDelay set to 4 seconds.

Preparing a test URL with non-copyrighted content requires creating a new stream, and additional procedures are needed to expose the test URL externally. This may take some more time.

If you already have a URL available, please proceed with that first.

For reference, I am creating live stream segments with a duration of 2 seconds.
and, I am using a 1 Mbps limit profile added to the Network Link Conditioner.
Additionally, the lower quality level among the adaptive streams is encoded at approximately 400 kbps.

[robwalch]

@kakao-wise-kim Please include debug logs from a v1.6.0-beta-2 session with the timeout/sync issue displayed above. That should tell us things we need to know like: Does the HLS have program date time? What is the target duration and playlist request frequency? The request event order, error handling actions, and abandon rules details...

[robwalch]

My other recommendation would be to test with Chrome's Network Condition's tab, or using a real network/mobile device with limited throughput. The blocking behavior of NLC and Firefox's conditioner do not reflect real world conditions.

[kakao-wise-kim]

@robwalch
hi. robwalch.
Are you able to access the URL below?
This URL will be accessible until December 26th, 5:00 PM KST.
It is valid until 8:00 AM UTC on December 26, 2024.

https://sbox-ak-orisa.play.kakao.com/s-kamp-up/live/slarke3yjajh4dyiga9xpzmpg/main/max_8000_f2jcputpqa.m3u8\?__token__\=exp\=1734739699\~acl\=/s-kamp-up/live/slarke3yjajh4dyiga9xpzmpg/\*\~hmac\=6a9bb719974dc71d845646a90af7ba2bc7d0b596f2d620f3f74d25fd9ce8e9b2

The requested data and logs will be organized and sent to you.

[robwalch]

Are you able to access the URL below?

I can curl it, but it gives me a 403 from the demo page on local host and the branch build (https://bugfix-live-av-desync-init-p.hls-js-4zn.pages.dev/demo/) for #6922.

I was able to reproduce the issue here with another live stream with similar attributes. The misalignment was cause by resetting of initPTS which is only for malformed streams.

• Do not adjust initPTS without accurate playlist time offset #6922

[kakao-wise-kim]

@robwalch

I tested based on the newly submitted PR (#6922) and confirmed that the issue has been resolved.
I understand that the order of audio segment indices may vary. Thank you for kindly explaining.
I hope it can be quickly applied to the next beta and released soon.
Thank you