LL-HLS 是什么,以及为什么它默认关着

LL-HLS(Low-Latency HLS)是 Apple 2019 年推出的 HLS 扩展, 把直播延迟从 10-30 秒压到 2-5 秒。

它解决的问题

普通 HLS 的延迟卡在一个死结上:服务器必须攒够一个完整分片才能发出去。

分片 6 秒 → 最新内容平均要等 3 秒才被打包
播放器缓冲 3 个分片 → 再加 18 秒

想降延迟就得缩短分片,但分片越短请求越密集,HTTP 开销和 CDN 压力急剧上升。

LL-HLS 引入 Partial Segment(部分分片):一个 6 秒的分片, 在它还没录完时就先把已有的 200ms 片段发出去。

普通 HLS:  [====== 6s 分片 ======] 录完才发
LL-HLS:    [200ms][200ms][200ms]... 边录边发,分片仍是 6s 的结构

播放列表里用 EXT-X-PART-INF 标签声明这个能力。

配合 HTTP/2 的 chunked transfer,播放器可以在分片还没完成时就开始拿数据—— 延迟因此降到 2-5 秒,同时保留了 HLS 的兼容性和 ABR。

因为 LL-HLS 有硬前置条件,不满足时开了会更糟:

不满足条件却开了 LL-HLS,典型表现是频繁卡顿 + 反复重连——比老老实实用普通 HLS 还差。

所以契约把它设计成显式 opt-in:

{
  url: 'https://cdn.example.com/live.m3u8',
  type: 'hls',
  live: true,
  hls: { lowLatencyMode: true }   // ← 你确认后端和 CDN 都达标了,才开
}

你可能以为"不传 = 不开",实际上不是这样的:

xgplayer-hls.js 打包的 hls.js,lowLatencyMode 默认值是 true。

也就是说,如果 SDK 什么都不做、只把 hls 配置原样透传,那所有人默认都开着 LL-HLS—— 而绝大多数后端并不满足前置条件。

所以 create-player 里是显式计算并强制传入的:

const lowLatencyMode = normalized.hls?.lowLatencyMode === true
// ...
{ HlsJsPlugin: { hlsOpts: { lowLatencyMode } } }

=== true 而不是 ?? false:只有消费方明确写了 true 才开,其余一律关。

这是「默认值不等于安全值」的典型

上游库的默认值是按它自己的假设定的,不一定符合你的场景。遇到"影响面大 + 有前置条件"的开关,显式写死比依赖默认值可靠。

这一节被 ADR-056 反掉了

本页从前写着「Safari / iOS 自动,不用配」—— 前提是它们走原生 HLS、由系统自己识别 EXT-X-PART-INF。ADR-056 把内核判据从平台改成能力之后, Safari 和 iOS ≥ 17.1 都走 hls.js 了,没有谁再替你自动开。

升级到含 ADR-056 的版本后,原本靠 Safari 自动低延迟的直播会静默退回普通 HLS 延迟 —— 不报错,只是慢。迁移动作:直播源统一显式传 lowLatencyMode: true。

结论:

环境	怎么开
Chrome / Firefox / Edge / Android	必须显式 `hls.lowLatencyMode: true`
Safari(桌面)/ iOS ≥ 17.1	同样必须显式 —— 它们现在也走 hls.js
iOS < 17.1(回落原生)	系统自动检测;传了也无害

所以跨平台唯一正确的写法是无脑统一传,不要按平台分支。

这就是坑 #33,也是 ADR-024 把字段放在 source.hls 而不是顶层的原因—— 和其他 hls 专属配置聚在一起,提醒你这是内核相关的选项。

要用,如果:直播延迟是核心体验指标(互动直播、带货、竞拍), 而且你能确认后端和 CDN 都达标。

不要用,如果:后端说不清是否支持部分分片。这种情况下老老实实用普通 HLS,或者直播加一路 FLV 拿 1-3 秒延迟, 比赌 LL-HLS 靠谱。