9.1.5 延迟预算：glass-to-glass 的定量拆解（Latency Budgeting）
9.1.2 给出了端到端延迟的定义与四级体验表，回答了"延迟是什么"。但定义只解决度量问题，工程上更棘手的是另一个：一场直播的 30 秒延迟，到底是哪一环吃掉的？定性地说"分片太长"人人都会，定量地拆开每一环，才知道刀该往哪里下。
延迟预算（Latency Budget） 是指把 glass-to-glass 总延迟按链路环节逐项拆解得到的账目表。它的原理朴素得像小学算术：
可一旦把真实数字填进去，这张表就成了流媒体架构里最有说服力的那张纸。学界对低延迟演进做定量梳理时，用的也是同样的拆解方法 [2]。
三条管线的账本
同一场 1080p 赛事直播，分别走传统 HLS、LL-HLS 与 WebRTC 三条管线，各环节的典型量级如下 [2]：
| 环节 | 传统 HLS | LL-HLS | WebRTC |
|---|---|---|---|
| 采集与相机管线 | 30~60 ms | 30~60 ms | 20~40 ms |
| 编码 | 300~600 ms | 150~400 ms | 20~50 ms |
| 推流回传 | 150~400 ms | 150~400 ms | n/a（SFU 直连） |
| 封装打包 | 6~10 s | 200~400 ms | 0 |
| 源站到边缘 | 40~120 ms | 20~120 ms | 20~80 ms |
| 播放器缓冲 | 12~18 s | 0.6~3 s | 60~200 ms |
| 解码渲染 | 50~100 ms | 50~100 ms | 30~60 ms |
| 合计 | 约 19~29 s | 约 1.2~5 s | 约 0.15~0.5 s |
数字是量级参考，具体实现各有浮动，但表里的结构信息是稳定的，逐行读过去，每一处都连着前面章节讲过的原理。
采集与编码是毫秒级的世界。采集端绕不开帧周期，30 fps 下一帧就是 33 ms；编码的账来自 6.1.3 的老朋友，x264 的 lookahead 与 B 帧重排用延迟换压缩率，低延迟配置把它们关掉，编码耗时就从数百毫秒缩到几十毫秒。推流回传若是 SRT，7.5.3 的 ARQ 重传缓冲通常按两倍 RTT 设，这是为可靠性预付的过路费。
封装与缓冲才是秒级的战场，也是三条管线真正拉开差距的地方。传统 HLS 的封装器要攒够一个完整分片才能发布，6 秒分片先欠下 6 秒；播放器再按惯例握三片在手（8.2.3 的水位逻辑），又是十几秒。LL-HLS 用 200 ms 量级的 part 分片破解了封装等待（7.4.5 的机制），缓冲水位随之削到秒级以内。WebRTC 则干脆没有"分片"这个概念，帧从编码器出来就被推上 UDP，播放器只留一层抗抖动的薄缓冲。
一个反直觉的注脚：链路换到 LL-HLS，播放端不调优也白搭。源站给出 200 ms 的 part，客户端若仍按保守水位起播，端到端延迟依然会停在五六秒。预算表的每一环都是独立科目，协议只负责其中两行。
账本的用法
延迟预算的价值不在数字本身，而在它指出的优化次序：先找表里最大的那一项。传统 HLS 想降延迟，去抠编码的几十毫秒毫无意义，分片时长与缓冲片数才是秒级的债主；反过来，WebRTC 管线已经把缓冲压到百毫秒，继续压编码参数就得不偿失。每一代低延迟技术的名字，其实都对应着预算表上被削掉的那一行：LL-HLS 削封装与缓冲，SRT 优化回传，WebRTC 抹去整列。
延迟账算清了，链路上还剩最后一类可靠性问题：分发环节的 CDN 若整个趴窝，预算表再漂亮也没用。9.1.6，多 CDN 调度与容灾。