EP12：低延迟直播测评方法与当前基线¶
| 上集回顾 | EP11《Netflix 的无缝切换给我们的启发》 |
|---|---|
| 下集预告 | EP13《P2P 直连：比 CDN 更快的最后一公里》（进入 Module 3） |
0. 本集目标¶
看完这一集，观众应该能做到四件事：
- 记住当前可复述的本项目实测基线：P2P 直连约 70ms；经 Edge 分发时，WHIP 入库约 108ms、SRT 入库约 386ms。
- 认清几种具体的延迟测量手段各自的精度上限和适用范围：从画面叠加时间戳、实物时钟同框截图，到跨地点的时间校准网页，再到 PPCDN 生产实际使用的自动化方案。
- 设计一次同口径、可复现的低延迟直播测评，不把官方标称、单次观察和对等实测混为一谈。
- 理解当前证据边界：没有华为云、腾讯云在对等条件下的实测数据，因此本集不做产品优劣断言。
1. 当前能够确认的本项目基线¶
在现有测试条件下，已经真实跑通并记录的端到端延迟约为（数据来自单机、单流、限定时段的直播时延性能测试报告，2026-09-29 更新）：
| 路径 | 实测值 | 解释边界 |
|---|---|---|
| P2P 直连（不经 Origin/Edge） | 约 70ms | 特定实验条件下真实跑通；不是所有 NAT、地域和网络的承诺值 |
| Edge 分发，WHIP 入库 | 约 108ms | WHIP 基于 WebRTC，入库没有固定接收窗口；需与测试设备、网络条件一起解释 |
| Edge 分发，SRT 入库 | 约 386ms | 比 WHIP 高约 278ms，主要来自入库端 SRT 接收窗口（TSBPD）这一有意放大的固定交付延迟，弱网时还会叠加重传缓冲 |
1.1 一图看清：三条基线的量级差¶
端到端延迟实测基线（同口径 · 单机单流 · ms）
P2P 直连 |██████ 70
Edge·WHIP |█████████ 108
Edge·SRT |████████████████████████████████ 386
+------------------------------------▶
0 100 200 300 400
注：柱高按数值等比；SRT 比 WHIP 高出的约 278ms 是同一套编码下的入库协议结构差。
1.2 差值主要来自"入库协议结构"，不是编码格式¶
flowchart TB
subgraph whip["WHIP 入库 ≈ 108ms"]
W1["上行网络"] --> W2["转发 / 下行"] --> W3["jitter buffer"]
end
subgraph srt["SRT 入库 ≈ 386ms"]
S1["上行网络"] --> S2["SRT 接收窗口 TSBPD<br/>为弱网重传有意放大"] --> S3["转发 / 下行"] --> S4["buffer"]
S2 -.-> S5["主要差值来源（约 278ms）"]
end
W3 --> Z["同一套编码配置下：落差来自入库协议结构，<br/>而不是 H264 / HEVC 的编码格式差异"]
S4 --> Z这些是测量结果，不是 SLA，也不是适用于所有环境的固定常数。三者的差值主要由入库协议结构决定，而不是编码格式：同一组测试用的是同一套编码配置，WHIP 和 SRT 两条入库路径的落差来自 SRT 接收窗口这项为弱网重传特意放大的固定延迟。推流用的编码格式（H264/HEVC）目前是播放端按解码能力选路的依据——HEVC 统一走 Edge、不参与 P2P 直连，H264 可尝试 P2P 或回退 Edge——这是一个路由规则，不是已经做过控制变量实验的独立延迟变量；没有分离编码格式本身影响的实验前，不应把编码格式差异也计入这组延迟数字。
作为参考，本项目内部对 P2P 直连路径设定的 SLA 目标是 P80 ≤300ms、P99 ≤2s；当前约 70ms 的实测值明显优于这一目标，但样本量和覆盖场景仍有限，不能据此推广到全部网络环境。
端到端延迟按 EP08 的口径，应关联同一帧的采集时间与实际渲染时间，并披露时钟校准误差和无效样本率。单独的 ICE RTT、RTCP RTT、网络收包时刻或解码完成时刻都不能替代这个指标。
2. 延迟怎么测：从人工比对方法到自动化管线¶
§1 的基线数字背后，要有一套"怎么把时延量出来"的具体手段撑着，不只是协议规范这么抽象。常见的人工比对方法有三种，精度和适用范围各不相同；PPCDN 生产环境实际用的是第三种思路的自动化、工程化版本。
2.1 方法一：画面叠加 ms 时间戳，推流 / 拉流同屏同时截图¶
推流前在画面上叠加一个每帧刷新的毫秒级时钟（比如编码前用软件在画面角落绘制当前系统时间），拉流播放时，把"推流端正在编码的原始预览画面"和"经过网络拉流回来、正在播放的画面"同时呈现在同一块屏幕（或用相机同框拍下两块屏幕），对比两个时间戳的差值就是端到端延迟。
- 精度：上限由叠加时间戳本身的刷新粒度决定——如果每编码帧刷新一次，精度大致被帧间隔封顶（如 30fps 约 33ms、60fps 约 17ms）；如果再用相机拍屏对比，还要叠加一次快门 / 曝光带来的不确定度。
- 局限：必须推流端和拉流端在同一地点——"同时看到两幅画面"这件事，本质上要求有一种不经过网络的手段把两路画面摆到一起比较（同一块屏幕的分屏，或同一台相机的同一次曝光）。换个角度看，这也是它唯一的优点：两边共享同一个物理时钟源（同一台电脑的系统时钟，甚至同一台相机的曝光时刻），不需要额外解决"推流端和拉流端的时钟是否同步"这个更难的问题——跨地点方法（见 §2.3）恰恰要为这件事专门花力气。
2.2 方法二：画面里放一只实物时钟，推流 / 拉流同框截图对比¶
跟方法一思路一致，只是把"软件叠加的数字时间戳"换成了对着镜头实拍的一只实物时钟 / 秒表（标称精度到 ms）——直播的内容本身就是这只钟的画面。拉流端把"实时看到的钟面"和"经过网络延迟后、播放端正在显示的钟面"同框拍下来对比。
- 精度：通常比方法一更粗，因为多了两层误差来源——① 实物时钟自己的刷新率：不少标称"毫秒精度"的电子钟表，显示屏实际刷新只有几十 ms 甚至更低；② 用来拍摄这只钟的摄像头本身也是按自己的帧率采样画面的（比如 30fps 的采集摄像头，本身就有约 33ms 的采样不确定度），这层误差在编码前就已经引入，和叠加数字时间戳（直接写进像素，不经过光学采样）不是一回事。
- 局限：同样需要推流端和拉流端同地点（或者说，需要能同框看到"钟的当下读数"和"播放画面"）；而且是纯人工操作，没法像自动化管线那样跑出成百上千个样本，更谈不上统计 P50/P95/P99——EP09 讲过的道理在这里同样成立：单次读数容易被噪声骗。
2.3 方法三：ms 级时间校准网页，跨地点独立对照¶
把前两种方法"必须同地点"这个限制拆掉的做法，是找一个共同的时间基准，而不是靠摄像头同框。具体做法：做一个显示毫秒级时间的网页，网页上的时间来自对同一个时间服务（比如 NTP）的校准，而不是打开网页那台设备自己、没对过时的系统时钟；推流端把这个网页投屏 / 录屏作为视频内容推流出去；在任意一个不同地点的拉流端，当地同样打开这个网页，对比"拉流画面里网页显示的时间"和"拉流端本地此刻这同一个网页显示的时间"，差值就是端到端延迟——不需要推流端和拉流端共处一地，因为两边比的不是"同一次曝光里的两个读数"，而是"两边各自独立对齐到同一个时间基准后的读数"。
- 精度：上限由两端各自对时的准确度决定——如果两端设备都认真做过 NTP 校准，精度可以到个位数至几十毫秒；如果某一端网络环境 NTP 不可用、或者浏览器标签页在后台被节流导致网页刷新变慢，对时误差会直接混进测得的"延迟"里，而测试者当下很难分辨这段误差到底是真实网络延迟还是对时没做好。
- 局限：虽然摆脱了"必须同地点"这个硬限制，但读数方式仍然是人工截图比对，没法自动规模化出统计分布；而且"两端对时准到什么程度"本身也需要被测量和披露，不能假设为零。
2.4 PPCDN 的实际做法：把方法三的思路自动化、嵌入码流¶
PPCDN 生产环境用的正是方法三这条思路的工程化版本——把"人读网页上的数字"换成"代码直接从码流里解出一个精确时间戳"，解决了方法三"跨地点可行、但没法自动化、没法规模化出统计分布"的问题：
- 推流端自己做 NTP 校准：ppobs 启动时对公网 NTP 服务器（
time.cloudflare.com/time.windows.com/pool.ntp.org）取 RTT 最小的样本，之后每 30 分钟重新校准，得到一个准确的 UTC 时钟——这就是方法三里"网页时间来自统一对时服务"的那个时间基准，只是不再渲染成人眼能读的数字。 - 时间戳直接写进码流，不是画面上可见的数字：每一帧编码后，在 H.264/H.265 的 SEI NAL（或 AV1 metadata OBU）里塞进一个固定 16 字节 UUID + 8 字节大端毫秒时间戳，紧跟在这一帧的编码数据之后。媒体链路（Origin/Edge/P2P 直连）全程原样透传、不解码不转码，时间戳原封不动跟着帧走到底。
- 播放端自动解析，不是人工截图：pplayer 用 WebCodecs 的 Insertable Streams（
RTCRtpReceiver.createEncodedStreams()），在不打断正常解码的前提下，程序直接从收到的编码帧里扫描出这段 SEI，取出时间戳——不需要人眼去读一个显示出来的数字，也就没有"读错一位数"这类人为误差。 - 播放端对齐同一个时间基准：播放端是浏览器，拿不到真 NTP，于是先对 ppcenter 做一次应用层时钟 offset 校准（与 NTP 同款的四时间戳算法：
TIME_SYNC/TIME_SYNC_ACK），把本地时钟对齐到和 ppobs 同一个 UTC 基准上，再用校准后的本地时间减去 SEI 时间戳，得到这一帧的端到端时延，即 pplayer 面板上显示的"P2P Delay"。
flowchart TB
subgraph local["同地点人工比对（①②）"]
direction TB
L1["推流原始画面 / 实物时钟"] --- L2["同一次截图或曝光"] --- L3["拉流播放画面"]
end
subgraph remote["跨地点，靠统一时间基准对照（③ 及 PPCDN 做法）"]
direction TB
R1["推流端对齐统一时间基准（NTP）"] -.经网络传递.-> R3["时间戳随画面 / 码流到达拉流端"]
R2["拉流端独立对齐同一时间基准"] --> R4["与拉流端此刻的基准时间相减"]
R3 --> R4
end这套管线和方法三的差别，本质是"人工读数、偶发采样"变成"代码解析、逐帧产出"：不再需要测试者手动截图比对，可以连续、大批量地产出样本，支撑 §1 的基线数字和 EP09 讲过的 P50/P80/P95/P99 统计——这也是为什么 EP13 会把 P2P 路径这套实测时延单独讲一整集（详见 EP13《P2P 直连：比 CDN 更快的最后一公里》 §4）。它也不是没有代价：解析这一步依赖 Insertable Streams 这类较新的浏览器能力，个别浏览器版本上出现过"读取 SEI 后解码卡死"的问题，需要专门的探测器兜底回退到一个精度更粗的估算值（标注成 (est.)，绝不会和真实测量混在一起显示）——自动化不等于不需要工程投入去维护它的可靠性。
2.5 四种方法放在一起看¶
| 方法 | 比较基准 | 是否要求同地点 | 典型精度上限 | 能否规模化出统计分布 |
|---|---|---|---|---|
| ① 画面叠加时间戳，同屏截图 | 同一次截图 / 曝光 | 是 | 受限于叠加帧率（约一帧间隔） | 否，人工单次操作 |
| ② 实物时钟同框截图 | 同一次截图 / 曝光 | 是 | 更粗：时钟刷新率 + 拍摄帧率两层误差叠加 | 否，人工单次操作 |
| ③ ms 校准网页，跨地点独立对照 | 两端各自对齐的统一时间基准 | 否 | 受限于两端对时精度（NTP 到位时可到十几 ms 级） | 否，仍是人工截图比对 |
| PPCDN 实际做法（③ 的自动化版本） | 码流内嵌时间戳 + 播放端对 ppcenter 校准 | 否 | 受限于两端对时精度，同 ③；但不再有人工读数误差 | 是，逐帧产出，可统计 P50/P80/P95/P99 |
3. 为什么当前不能给出友商优劣结论¶
目前没有华为云、腾讯云与本项目在以下对等条件下采集的原始数据：相同采集源、终端、编码参数、网络路径、测试时段、播放协议、时间戳方法和统计口径。因此本集不能回答"谁更快"或"谁更稳定"。
官网能力说明和标称延迟可以用于确定待测配置，却不是本地对等实测。比如腾讯云快直播（LEB）官网把延迟描述为"毫秒级 / 1 秒内"这一类范围口径，本身就不是单点实测值——拿这种公开口径和本项目的单点实测数字直接相减或排名，口径就已经不对等，不是谁更快，而是在比较两种不同性质的数字。架构分析可以提出假设，例如 P2P 可能减少中间转发跳数，HEVC 可能在同等质量下降低码率（本项目自己的离线 VMAF 实测见 EP20：NVENC 实时档约 15%、软件编码约 39%），但这些结果只说明本项目自己的编码链路，不能替代对等测量，更不能据此断言华为云或腾讯云的优劣。
flowchart LR
A["官方能力说明 / 标称延迟"] --> C{"是不是同口径的对等实测？"}
B["本项目单点实测"] --> C
C -->|是| D["可以比较、可以排名"]
C -->|否| E["只能各自描述口径，<br/>相减 / 排名本身就失真"]4. 一次可信测评的协议¶
4.1 固定控制变量¶
- 使用同一采集源、分辨率、帧率、码率控制模式、GOP 和音频配置。
- 使用同一批播放终端、浏览器/原生播放器版本和硬件解码设置。
- 在相近时间窗口、相同接入网络和地域重复测试，并记录有线、WiFi、4G/5G 等网络类型。
- 分开比较相同 codec 和协议组合。若某产品不支持同一组合，应明确写成能力差异，不能把不同组合的延迟直接归因于厂商。本项目当前 HEVC 观众只走 Edge、不参与 P2P 直连（见 §1），这也是必须按 codec + 协议组合分别统计、不能混在一起比较的真实例子。
4.2 固定测量口径¶
- 端到端延迟使用帧级采集时间到实际渲染时间，记录时钟 offset、不确定度和无效样本率——具体用哪种手段产出这个数字，见 §2。
- 首帧使用"有效播放请求被接受"到"首个非占位帧实际渲染"的统一口径。
- 卡顿按 EP08 定义统一事件阈值、排除项和有效观看时长分母。
- ICE RTT、RTCP RTT、端到端延迟分别记录，不混成一个"网络延迟"。
4.3 看分布和失败，不挑单次最好值¶
每个测试单元至少报告样本量、成功率、P50、P80、P95、P99、最大值和置信区间，并单列建连失败、超时和无效测量样本。P99 的计算方法和最小样本量要预先固定，避免测试后挑选对自己有利的统计方式。
为什么必须看分布，而不是一个平均数——同一路流一次测试的分布（示意），只看 P50 会显得很好，长尾藏在 P99 / max：
P50 |██
P80 |████
P95 |███████
P99 |████████████
max |██████████████████
+------------------▶ 延迟（ms）
只报 P50 会掩盖长尾——EP09 的教训在这里同样成立
4.4 保证可复现¶
公开测试日期、地域、终端、版本、配置、脚本、原始匿名数据和排除规则。产品版本或关键配置变化后重新测试，不让旧结果长期代表当前产品。
5. 结果表应该怎样写¶
在对等数据产出前，结果表只记录证据状态，不填推测值：
| 对象 | 对等实测状态 | 当前可下结论 |
|---|---|---|
| 本项目 | 已有当前基线 | P2P 直连约 70ms；Edge 分发下 WHIP 入库约 108ms、SRT 入库约 386ms，适用范围限于已记录测试条件 |
| 华为云 | 尚无本轮对等实测 | 不判断延迟或稳定性优劣 |
| 腾讯云 | 尚无本轮对等实测 | 不判断延迟或稳定性优劣 |
后续补测时，应直接增加同口径分布和原始数据链接，而不是先写结论再寻找数字佐证。
6. 框图¶
6.1 从测试协议到结论¶
flowchart TD
A["同一采集源、终端、编码与网络条件"] --> B["统一帧级端到端延迟 / 首帧 / 卡顿定义"] --> C["多轮采样，记录成功、失败和无效样本"] --> D["报告 P50/P80/P95/P99、样本量与置信区间"] --> E["公开配置、脚本、原始数据和排除规则"] --> F["只有数据同口径，才形成产品对比结论"]6.2 当前证据边界¶
flowchart TD
A["本项目当前基线：<br/>P2P 直连 ≈70ms / Edge-WHIP 入库 ≈108ms / Edge-SRT 入库 ≈386ms"] --> B["可作为后续回归与对等测试的基线"]
A --> C["不能直接外推为所有环境的 SLA"]
D["华为云 / 腾讯云：暂无本轮对等实测"] --> E["不产出优劣结论，不用官方标称补位"]7. 结尾与下集预告（逐字稿要点）¶
当前事实只有三组基线：P2P 直连约 70ms，Edge 分发下 WHIP 入库约 108ms、SRT 入库约 386ms，差值主要来自入库协议结构而非编码格式。这些数字怎么量出来，有讲究：画面叠加时间戳、实物时钟同框截图这两种人工方法必须推流拉流同地点，精度被帧率和时钟刷新率封顶；一个跨地点可用的办法，是靠一个统一校准过的时间网页各自独立对照；PPCDN 生产环境用的正是这条思路的自动化版本——NTP 对时、SEI 码流内嵌时间戳、播放端自动解析相减，把人工读数变成了可以逐帧产出、能统计 P50/P95/P99 的管线。没有对等友商实测，就不做华为云、腾讯云优劣判断。真正可复用的是测评协议：控制变量、统一帧级口径、报告完整分布与失败、公开原始数据。
Module 2 到这里结束。下一集进入 Module 3，讲 P2P 直连如何通过 ICE 检查建立，以及产品怎样在直连、Edge 和 TURN 之间做取舍。