直播时延性能测试报告¶
| 属性 | 值 |
|---|---|
| 文档类型 | 测试报告（含测量方法与结果分析） |
| 测试对象 | PPCDN 直播全链路：ppobs 推流 → Origin/Edge 分发 → pplayer 播放 |
| 核心指标 | 端到端时延 |
| 被测路径 | Edge 分发路径 |
| 结论摘要 | 5 类终端 / 网络场景端到端时延稳定在 450–480ms；瓶颈为固定缓冲地板（主要在入库端 SRT 接收窗口），与接入网络方式基本无关 |
| 更新时间 | 2026-09-29 |
0. 摘要¶
- 测试对象：PPCDN 低延迟直播链路，覆盖 WHIP / SRT 推流与 WHEP/WebRTC 播放。
- 测量口径：ppobs 采集时刻（码流内时间戳）→ ppplayer 渲染的单程时延。
- 结果：5 个场景（电脑/Android/iPhone × LAN/WiFi/4G）实测 450ms ~ 480ms，不同接入网络差异 仅一个 RTT 量级（10–30ms）。
- 关键结论：该水平由固定缓冲地板决定——入库端 SRT 接收窗口（主项）+ 播放器 jitter buffer
- 编解码/渲染，网络快慢压不下去；要降低时延，杠杆在服务端与播放器配置，而非接入方式。
1. 测试目标与范围¶
目标
- 量化不同播放终端与网络接入方式下的端到端时延。
- 验证链路在不同网络条件下都能给出稳定、可复现的低时延表现。
- 定位时延的主要构成项，给出可落地的优化方向。
本次不测：吞吐上限、并发规模、计费正确性、录像链路、移动端原生 App（仅测浏览器 WebRTC 播放）。
2. 指标口径与测量原理¶
2.1 端到端时延定义¶
从 ppobs 采集时刻（码流内打点）到 pplayer 渲染的单程时延，覆盖采集、编码、分发、抖动缓冲 与解码的完整链路。
2.2 测量链路¶
- ppobs 在码流内打入绝对 UTC 时间戳（SEI/OBU），Origin/Edge 逐跳透传，不解码、不转码。
- ppplayer 解析时间戳，并通过 ppcenter 的时钟同步接口做时钟偏移校准（NTP 四时间戳算法，取 最小 RTT 样本），再计算单程时延：
corrected_now = local_clock + offset
one_way_delay = corrected_now - embedded_timestamp
- 计算完成后按路径（
edge/p2p）上报 ppcenter 聚合展示。
2.3 边界与限制¶
- 端到端时间戳通路以 Edge 分发路径为主；P2P 直连路径另以 WebRTC RTCP RTT 作辅助参考，两者 口径不同，不直接合并比较。
- 本报告的读数来自 ppplayer 面板的实测值；全量百分位（P50/P80/P95/P99）由 ppcenter 按分钟/日 窗口聚合，可在控制台查看，本报告不追求单帧精度。
- 极小真实时延叠加残余抖动时可能出现接近 0 的读数，属正常噪声。
3. 测试环境与设备¶
3.1 推流端（全场景固定）¶
| 项 | 取值 |
|---|---|
| 客户端 | ppobs |
| 入库协议 | SRT |
| 编码 | H.264 |
| 分辨率 / 帧率 | 1080p / 30fps |
| 码率 | 固定，避免 ABR 抖动 |
| GOP / 缓冲 | 固定低延迟配置 |
3.2 播放端场景¶
| 编号 | 场景 | 接入方式 |
|---|---|---|
| S1 | 电脑 + LAN | 有线以太网 |
| S2 | 电脑 + WiFi | WiFi（同一 AP） |
| S3 | Android + WiFi | WiFi（同一 AP） |
| S4 | Android + 4G | 4G/5G 蜂窝数据 |
| S5 | iPhone + WiFi | WiFi（同一 AP） |
3.3 账号与流¶
全场景使用同一个 App、同一条流、同一套推流参数，以保证可比性。播放器为 ppplayer。
4. 测试矩阵与步骤¶
4.1 通用步骤¶
- 起推流：启动 ppobs，确认推流稳定（无丢帧 / 断流告警），保持参数不变。
- 起播放：在对应终端打开 ppplayer，确认已完成一次时钟校准。
- 稳定播放：保持播放 ≥ 3 分钟，期间不做切网、切后台等操作。
- 记录：记录连接路径、ppplayer 面板时延读数、首帧时间、有无卡顿 / 黑屏 / 重连。
- 重复：同一场景重复多次，取稳定区间。
4.2 测试中立性¶
- 同一时间、同一地理位置执行，减少公网路径与调度差异。
- 失败运行如实记录（连接路径、失败原因），不得只保留成功样本。
5. 实测结果¶
测试时段各场景的端到端时延实测值（单位 ms）：
| 场景 | 终端 / 网络 | 主要路径 | 实测时延 |
|---|---|---|---|
| S1 | 电脑 + LAN | Edge | 450 |
| S2 | 电脑 + WiFi | Edge | 460 |
| S3 | Android + WiFi | Edge | 450 |
| S4 | Android + 4G | Edge | 480 |
| S5 | iPhone + WiFi | Edge | 470 |
汇总
| 指标 | 值 |
|---|---|
| 区间 | 450 – 480ms |
| 中位 | 460ms |
| 场景间差异 | ≤ 30ms（约一个 RTT 量级） |
| 主要路径 | 全部为 Edge 分发 |
6. 结果分析：为什么各场景几乎一样¶
5 个场景的时延高度一致，说明瓶颈不在接入网络，而是链路中的固定缓冲地板：
- 固定缓冲地板决定总量级。LAN/WiFi/4G 的差别只有一段 RTT（10–30ms），表现为地板上的小幅 浮动（4G 480ms 比 LAN 450ms 高约一个 RTT 量级）。
- 只要推流走 SRT，入库端就有一个几百毫秒的固定交付窗口（TSBPD），它先于网络路径成为瓶颈， 网络再快也压不下去。
- 播放器的 jitter buffer 与解码/渲染补偿再叠加一层固定开销。
时延预算拆解（量级）：
| 环节 | 量级 | 说明 |
|---|---|---|
| ppobs 采集 + 编码 | ~30–60ms | 低延迟 / 无 B 帧 / 短 GOP |
| 入库端 SRT 接收窗口（TSBPD） | 300–500ms（主项） | 为弱网重传特意放大的交付窗口 |
| Origin → Edge 转发 | ≈RTT，很小 | 重排缓冲，非固定延迟 |
| Edge → 播放器 WebRTC | ≈RTT | 浏览器抖动缓冲由播放器控制 |
| 播放器 jitter buffer | 100ms（pplayer 默认） | 可配置 |
| 解码 + 渲染补偿 | ~50ms | 已计入读数 |
300（SRT 下限）+ 100（播放器 buffer）+ 50（补偿）≈ 450ms，正好是实测地板值。
SRT 接收窗口是为弱网重传特意放大的（RTT 较小时，窗口过小会导致抖动后重传赶不上而被判丢包）。 因此它是一个有意的「丢包鲁棒性 ↔ 时延」取舍，而不是实现缺陷。
7. 能否继续降低，以及如何降¶
按收益排序：
- 调小入库端 SRT 接收窗口（最大杠杆，可省 150–350ms）
- 把接收窗口下限从当前值进一步下调到 150–200ms。
- 权衡：RTT ~30ms 时 200ms ≈ 6.7×RTT，重传余量变小，弱网上行丢包 / 卡顿概率上升。建议先在 弱网场景实测后再定。
- 播放器 jitter buffer（≤100ms）
- ppplayer 默认已是 100ms 量级；可用
?bufferMs=100统一口径。再往下调卡顿风险上升。 - 编码低延迟（数十 ms）
- 使用低延迟 / 超低延迟预设，关闭 B 帧，缩短 GOP / 关键帧间隔。
- Edge 转发重排缓冲（收益有限）
- 调小重排缓冲可减少乱序等待，主要抗乱序而非固定延迟。
- 更换入库协议（结构性取舍）
- WHIP 入库没有 TSBPD 接收延迟概念，理论时延更低，但弱网上行鲁棒性不如 SRT。是否切换取决于 业务对弱网的容忍度。
8. SLA 说明¶
| 指标 | 目标 | 上限 | 适用路径 |
|---|---|---|---|
| P80 | ≤ 300ms | ≤ 600ms | P2P 直连 |
| P99 | ≤ 2s | — | P2P 直连 |
SLA 阈值与官网功能页「P2P 延迟 SLA」一致，用于展示 / 告警，不含赔偿。
本轮说明：本次测试走 Edge 分发路径，未产生 P2P 直连路径的独立样本。P2P 路径的时延分布以 直连真正建立后的统计为准。
9. 结论与限制¶
结论
- 网络接入方式（LAN/WiFi/4G）改不动这 ~450ms，因为瓶颈是固定缓冲地板，主要在入库端 SRT 接收窗口，其次是播放器 jitter buffer。
- 要降时延，动作应落在服务端与播放器配置，并明确接受弱网鲁棒性下降的代价。
已知限制
- 本报告的端到端时延以 Edge 分发路径为主，P2P 直连路径另以 RTCP RTT 作辅助参考。
- 测试为单机、单流、限定时段，不代表全网全量 SLA；生产环境的实时 SLA 以控制台按日聚合为准。
- 移动终端表现受运营商网络、信号强度影响较大，S4（4G）结果波动属预期。
10. 修订记录¶
| 日期 | 修订 | 说明 |
|---|---|---|
| 2026-09-26 | 初稿 | 测试方案定稿 |
| 2026-09-29 | 实测结果 | 合并「端到端时延稳定在 450–480ms 的成因分析」；补充 5 场景实测值与缓冲地板拆解 |