EP12：低延迟直播测评方法与当前基线¶

上集回顾	EP11《Netflix 的无缝切换给我们的启发》
下集预告	EP13《P2P 直连：比 CDN 更快的最后一公里》（进入 Module 3）

0. 本集目标¶

看完这一集，观众应该能做到三件事：

记住当前可复述的本项目实测基线：P2P 直连约 70ms；经 Edge 分发时，WHIP 入库约 108ms、SRT 入库约 386ms。
设计一次同口径、可复现的低延迟直播测评，不把官方标称、单次观察和对等实测混为一谈。
理解当前证据边界：没有华为云、腾讯云在对等条件下的实测数据，因此本集不做产品优劣断言。

1. 开场钩子（逐字稿要点）¶

对比表很容易做，可信的对比却很难。只要终端、编码器、网络、时间戳口径或样本窗口不同，数字就不能直接比较。本集先固定本项目已测得的基线，再给出对等测评协议；在友商数据补齐之前，不把推测包装成结论。

2. 当前能够确认的本项目基线¶

在现有测试条件下，已经真实跑通并记录的端到端延迟约为（数据来自单机、单流、限定时段的直播时延性能测试报告，2026-09-29 更新）：

路径	实测值	解释边界
P2P 直连（不经 Origin/Edge）	约 70ms	特定实验条件下真实跑通；不是所有 NAT、地域和网络的承诺值
Edge 分发，WHIP 入库	约 108ms	WHIP 基于 WebRTC，入库没有固定接收窗口；需与测试设备、网络条件一起解释
Edge 分发，SRT 入库	约 386ms	比 WHIP 高约 278ms，主要来自入库端 SRT 接收窗口（TSBPD）这一有意放大的固定交付延迟，弱网时还会叠加重传缓冲

这些是测量结果，不是 SLA，也不是适用于所有环境的固定常数。三者的差值主要由入库协议结构决定，而不是编码格式：同一组测试用的是同一套编码配置，WHIP 和 SRT 两条入库路径的落差来自 SRT 接收窗口这项为弱网重传特意放大的固定延迟。推流用的编码格式（H264/HEVC）目前是播放端按解码能力选路的依据——HEVC 统一走 Edge、不参与 P2P 直连，H264 可尝试 P2P 或回退 Edge——这是一个路由规则，不是已经做过控制变量实验的独立延迟变量；没有分离编码格式本身影响的实验前，不应把编码格式差异也计入这组延迟数字。

作为参考，本项目内部对 P2P 直连路径设定的 SLA 目标是 P80 ≤300ms、P99 ≤2s；当前约 70ms 的实测值明显优于这一目标，但样本量和覆盖场景仍有限，不能据此推广到全部网络环境。

端到端延迟按 EP08 的口径，应关联同一帧的采集时间与实际渲染时间，并披露时钟校准误差和无效样本率。单独的 ICE RTT、RTCP RTT、网络收包时刻或解码完成时刻都不能替代这个指标。

3. 为什么当前不能给出友商优劣结论¶

目前没有华为云、腾讯云与本项目在以下对等条件下采集的原始数据：相同采集源、终端、编码参数、网络路径、测试时段、播放协议、时间戳方法和统计口径。因此本集不能回答“谁更快”或“谁更稳定”。

官网能力说明和标称延迟可以用于确定待测配置，却不是本地对等实测。比如腾讯云快直播（LEB）官网把延迟描述为“毫秒级 / 1 秒内”这一类范围口径，本身就不是单点实测值——拿这种公开口径和本项目的单点实测数字直接相减或排名，口径就已经不对等，不是谁更快，而是在比较两种不同性质的数字。架构分析可以提出假设，例如 P2P 可能减少中间转发跳数，HEVC 可能在同等主观质量下降低带宽需求，但这些假设不能替代测量，更不能据此断言华为云或腾讯云的优劣。

4. 一次可信测评的协议¶

4.1 固定控制变量¶

使用同一采集源、分辨率、帧率、码率控制模式、GOP 和音频配置。
使用同一批播放终端、浏览器/原生播放器版本和硬件解码设置。
在相近时间窗口、相同接入网络和地域重复测试，并记录有线、WiFi、4G/5G 等网络类型。
分开比较相同 codec 和协议组合。若某产品不支持同一组合，应明确写成能力差异，不能把不同组合的延迟直接归因于厂商。本项目当前 HEVC 推流只走 Edge、不参与 P2P 直连（见 §2），这也是必须按 codec + 协议组合分别统计、不能混在一起比较的真实例子。

4.2 固定测量口径¶

端到端延迟使用帧级采集时间到实际渲染时间，记录时钟 offset、不确定度和无效样本率。
首帧使用“有效播放请求被接受”到“首个非占位帧实际渲染”的统一口径。
卡顿按 EP08 定义统一事件阈值、排除项和有效观看时长分母。
ICE RTT、RTCP RTT、端到端延迟分别记录，不混成一个“网络延迟”。

4.3 看分布和失败，不挑单次最好值¶

每个测试单元至少报告样本量、成功率、P50、P80、P95、P99、最大值和置信区间，并单列建连失败、超时和无效测量样本。P99 的计算方法和最小样本量要预先固定，避免测试后挑选对自己有利的统计方式。

4.4 保证可复现¶

公开测试日期、地域、终端、版本、配置、脚本、原始匿名数据和排除规则。产品版本或关键配置变化后重新测试，不让旧结果长期代表当前产品。

5. 结果表应该怎样写¶

在对等数据产出前，结果表只记录证据状态，不填推测值：

对象	对等实测状态	当前可下结论
本项目	已有当前基线	P2P 直连约 70ms；Edge 分发下 WHIP 入库约 108ms、SRT 入库约 386ms，适用范围限于已记录测试条件
华为云	尚无本轮对等实测	不判断延迟或稳定性优劣
腾讯云	尚无本轮对等实测	不判断延迟或稳定性优劣

后续补测时，应直接增加同口径分布和原始数据链接，而不是先写结论再寻找数字佐证。

6. 框图¶

6.1 从测试协议到结论¶

同一采集源、终端、编码与网络条件
              │
              ▼
统一帧级端到端延迟 / 首帧 / 卡顿定义
              │
              ▼
多轮采样，记录成功、失败和无效样本
              │
              ▼
报告 P50/P80/P95/P99、样本量与置信区间
              │
              ▼
公开配置、脚本、原始数据和排除规则
              │
              ▼
只有数据同口径，才形成产品对比结论

6.2 当前证据边界¶

本项目当前基线：P2P 直连≈70ms / Edge-WHIP 入库≈108ms / Edge-SRT 入库≈386ms
                         │
                         ├── 可以作为后续回归与对等测试的基线
                         │
                         └── 不能直接外推为所有环境的 SLA

华为云 / 腾讯云：暂无本轮对等实测
                         │
                         └── 不产出优劣结论，不用官方标称补位

7. 结尾与下集预告（逐字稿要点）¶

当前事实只有三组基线：P2P 直连约 70ms，Edge 分发下 WHIP 入库约 108ms、SRT 入库约 386ms，差值主要来自入库协议结构而非编码格式。没有对等友商实测，就不做华为云、腾讯云优劣判断。真正可复用的是测评协议：控制变量、统一帧级口径、报告完整分布与失败、公开原始数据。

Module 2 到这里结束。下一集进入 Module 3，讲 P2P 直连如何通过 ICE 检查建立，以及产品怎样在直连、Edge 和 TURN 之间做取舍。