hls.js: drop segment load cap 30s -> 10s
Dribbling CDN segments (logged at 17.8s/59.7s) made the player stare at 'Buffering…' for half a minute per attempt. Cap total load at 10s so a retry kicks in sooner (timeoutRetry still 6x, backoff 1-20s); fast segments (0.1-0.2s) are unaffected.
This commit is contained in:
1 parent
07554e4aa8
commit
2576546b43
2 files changed
+7
-5
No files matched your search
+5
-3
@@ -831,15 +831,17 @@ async function play(ep_id, ep_no) {
|
||||
// hls.js 1.5.x reads the retry budget from the errorRetry / timeoutRetry
|
||||
// sub-objects (a top-level maxNumRetry is ignored — that was the old bug).
|
||||
// maxTimeToFirstByteMs first byte within 15s
|
||||
// maxLoadTimeMs total load within 30s — MUST be finite, else a CDN
|
||||
// that starts sending then stalls hangs us forever
|
||||
// maxLoadTimeMs total load within 10s — finite cap, and LOWER than
|
||||
// the first-byte cap, so a dribbling CDN segment is
|
||||
// aborted at 10s and retried (timeoutRetry 6x) instead
|
||||
// of the player staring at "Buffering…" for 30s
|
||||
// timeoutRetry retries for a load *timeout* (was default 1!)
|
||||
// errorRetry retries for HTTP errors like our proxy's 502
|
||||
// Together: a slow/stalled CDN gets retried with backoff instead of one
|
||||
// shot -> fatal fragLoadTimeOut.
|
||||
hls = new Hls({ fragLoadPolicy: { default: {
|
||||
maxTimeToFirstByteMs: 15000,
|
||||
maxLoadTimeMs: 30000,
|
||||
maxLoadTimeMs: 10000,
|
||||
timeoutRetry: { maxNumRetry: 6, retryDelayMs: 1000, maxRetryDelayMs: 20000, backoff: "linear" },
|
||||
errorRetry: { maxNumRetry: 8, retryDelayMs: 1000, maxRetryDelayMs: 20000, backoff: "linear" },
|
||||
} } });
|
||||
|
||||
Reference in new issue
Block a user