延迟的来源
从主播推流到观众观看，延迟由以下环节累积：采集编码（50-200ms）+ 推流传输（100-500ms）+ 服务端转码（200-1000ms）+ CDN分发（200-2000ms）+ 客户端缓冲（1000-5000ms）。传统HLS直播总延迟可达10-30秒。
低延迟方案对比
LLHLS（Low-Latency HLS）
Apple在2020年推出的低延迟HLS标准。通过部分分片（Partial Segments）和预加载提示（Preload Hints）将延迟降至2-4秒。兼容性好，CDN支持广泛。适合不需要极致低延迟的场景。
LLDASH（Low-Latency DASH）
DASH的低延迟扩展，原理类似LLHLS。优势在于开放标准、不绑定苹果生态。延迟可控制在2-3秒。目前在YouTube等平台广泛应用。
WebRTC
端到端延迟低于500ms，但需要SFU服务器支持大规模分发。方案：推流端→SFU→多个边缘SFU→观众。工程复杂度高但延迟最低。
QUIC Streaming
基于HTTP/3的直播方案，利用QUIC协议0-RTT建连和多路复用特性。延迟1-2秒，兼具WebRTC的低延迟和HLS的可扩展性。2026年正在快速普及。
实施关键点
- 编码器配置：关键帧间隔设为1秒（而非默认的2秒）
- 分片策略：LLHLS部分分片设为200ms
- 缓冲策略：播放器缓冲区从3秒降至0.5-1秒
- 追帧机制：检测到延迟累积时自动加速播放追赶直播进度
延迟与画质的权衡
降低延迟不可避免地影响画质和稳定性。缓冲区越小，网络抖动越容易导致卡顿。建议根据场景选择合适的延迟目标：电商直播2-3秒、游戏直播3-5秒、互动直播小于1秒。