EP20：PPCDN 为您带来 30%~50% 的带宽 & 成本 & 时延节约！¶
| 上集回顾 | EP19《压力测试方法论：从单机到全球压测》 |
|---|---|
| 下集预告 | 全系列收官（Module 5 结束） |
0. 本集目标¶
看完这一集，观众应该能做到四件事：
- 说出三笔账分别省在哪：带宽省在"HEVC 码率更低 + P2P 绕开 Edge"，成本省在"不在网络侧转码就能做 ABR"，时延省在"P2P 直连 + 选对推流协议"。
- 算出自己的数字：每一项都给了公式，把您的账单占比、终端占比、房间规模代进去，而不是照抄本集的数字。
- 看懂什么时候不成立：HEVC 观众不走 P2P、P2P 每个推流端最多 3 路、上行带宽是推流方自己的资源。
- 区分三种数字：实测的、建模的、还没验证的，本集每个数字都会标出属于哪一类。
1. 三笔账，一页看完¶
| 节约什么 | 量级 | 凭什么 | |
|---|---|---|---|
| 带宽 | Edge → 观众的下行带宽 | HEVC 比 H264 压缩率高约 30%~50%；1v1、小规模并发下 P2P 可让 Edge 下行接近 100% 归零 | HEVC 编码效率 + P2P 直连不经 Edge |
| 成本 | 云端转码费 | 这是最大的一项：采用 ABR 的场景里，转码流量可占到 50% | ppobs 同播 + 本机算力转码 + 上行推流免费，PPCDN 转码费为 0 |
| 时延 | 端到端时延（含播放缓冲） | P2P ≤ 110ms，比 WHIP（190ms）低约 42%；WHIP 比 SRT（360ms）低约 47% | 项目内实测 |
三项节约并不是同一个观众同时拿满：HEVC 观众省码率；H264 观众有机会走 P2P 省下行、省时延；转码费是所有观众共享的那一笔。
2. 带宽节约¶
2.1 HEVC：压缩率比 H264 高约 30%~50%¶
在同样的画质下，HEVC 比 H264 需要的码率更低，行业里常说的范围就是 30%~50%。这条路径省的是每个观众的下行码率，所以观众越多，省得越多。支持 HEVC 解码的终端越来越普及，能走 HEVC 的观众比例也在持续上升。
这一集不只引用行业说法，还自己测了一次。方法：对同一段参考源，按 H264 和 HEVC 各自的码率阶梯编码，用离线 VMAF 与参考源配对打分，在相同 VMAF 上比较码率（EP10 的方法）；编码设置对齐 ppobs 的实时场景：CBR、无 B 帧、关键帧间隔 60、低延迟。
| 编码器 | 内容 | 同 VMAF 下 HEVC 比 H264 省 |
|---|---|---|
| 软件 x264/x265（medium，zerolatency） | 1080P 素材 | 44.4% |
| 软件 x264/x265 | 竖屏 1080×1920 | 34.2% |
| 软件合计（8 个对比点） | 均值 39.3%，范围 13.9%~50.4% | |
| NVENC（RTX 4060，p4 低延迟） | 1080P 素材 | 24.0% |
| NVENC | 4K 缩放到 1080P | 15.8% |
| NVENC | 竖屏 1080×1920 | 2.0% |
| NVENC 合计（11 个对比点） | 均值 15.0%，范围 −4.8%~29.5% |
读这张表要注意：
- 软件编码（含更慢的 preset）的结果落在 30%~50% 区间，和行业说法一致；
- GPU 硬件实时档（NVENC）的增益明显更小，均值约 15%。ppobs 常用 NVENC，所以要把"30%~50%"理解为编码器条件下的上限区间，而不是无条件承诺；
- 随内容变化：竖屏素材在 NVENC 下几乎没有增益；
- 小样本：3 段各 10 秒素材、1 块 GPU，不是对您内容的承诺，上线前请用您自己的内容重测。
2.2 P2P：节约的是下行带宽¶
P2P 直连成功时，推流端的画面直接送到观众，这一路的 Edge 下行（出站）带宽为 0（EP13）。限制有两条：
- 只有 H264 观众能走 P2P：HEVC 观众直接走 Edge，不参与 P2P；
- 每个推流端默认最多 3 路直连（
maxP2PSessions）。
所以 P2P 的收益取决于房间规模：1v1 业务和小规模并发业务里，每一个观众都有机会直连，节约的比重可以很高；大房间里 3 路上限让可分走的比例很小。
2.3 合起来怎么算¶
设 h = HEVC 观众占比，f = HEVC 的码率节省率，q = H264 观众里 P2P 命中的比例：
Edge 下行节约 = f × h + (1 − h) × q
q ≤ min(1, 3 ÷ H264 观众数)
模型示例（建模，不是实测）：
| 场景 | h | f | q | Edge 下行节约 |
|---|---|---|---|---|
| 观众全部支持 HEVC，软件编码 | 100% | 39% | — | 39% |
| 观众全部支持 HEVC，f 取行业上限 | 100% | 50% | — | 50% |
| 观众全部支持 HEVC，NVENC | 100% | 15% | — | 15% |
| 大房间 100 人，HEVC 占 60%，软件编码 | 60% | 39% | 3÷40 = 7.5% | 约 26% |
| 小规模 3 人，全是 H264，P2P 全部命中 | 0% | — | 100% | 100% |
| 1v1，H264，P2P 命中 | 0% | — | 100% | 100% |
- 大房间：主要靠 HEVC，量级取决于编码器，15%~50%；
- 1v1 和小规模并发：P2P 命中后下行直接归零，是节约最大的场景；
- HEVC 与 P2P 不叠加在同一个观众身上：一个观众要么走 HEVC，要么走 H264 + P2P。
3. 成本节约：不在网络侧转码，也能做 ABR¶
3.1 ABR 为什么要转码¶
ABR（自适应码率）要有多档画质可选。传统云直播里，推流端只发一路，多档画质靠云端转码生成：云端先解码，再按每个输出档位重新编码，按输出档位单独计费。采用 ABR 的场景里，转码流量可以占到总流量的 50%，使用腾讯云直播这类服务，就会产生一大笔转码费用（具体比例请以您的账单为准）。
flowchart LR
subgraph before["传统云直播（ABR）"]
T1["转码费<br/>流量占比可达 50%"]
B1["下行带宽"]
end
subgraph after["PPCDN"]
T2["转码费 = 0<br/>推流端本机转码"]
B2["下行带宽<br/>再按 HEVC / P2P 下降"]
end
before --> after3.2 PPCDN 怎么做¶
ppobs 支持 WHIP / SRT / ERTMP 三种协议同播：在推流端用本机算力一次编出多档画质，还能同时发布 H264 与 HEVC 两条轨。服务端只做 RTP 透传，不解码、不转码，不必在网络侧转码，就支持 ABR 自适应码率——这是整套方案里最大的成本节约。
| 入库协议 | 怎么发多轨 | 层数上限 |
|---|---|---|
| WHIP | H264、HEVC 各一条 WebRTC 会话 | H264 ≤ 4 层、HEVC ≤ 3 层 |
| SRT | H264、HEVC 各一条 SRT 连接（MPEG-TS 多路 ES） | 同上 |
| ERTMP | H264、HEVC 各一条 Enhanced RTMP 连接，多 track | 同上 |
这笔账能成立，靠两条：
- 推流端本机算力转码：编码用的是推流机自己的 GPU/CPU，不占用云端算力；
- 上行推流免费：这是行业里的通行做法，PPCDN 也不收上行流量费，转码费为 0。
前面第 2 节的带宽/流量节约，本质上也是在节约成本：下行流量少了，按流量计费的账单就少了。
成本节约的公式（t 换成您账单里转码相关费用的真实占比）：
成本节约 ≈ t（转码费占比）+ (1 − t) × 带宽节约率
3.3 代价别藏¶
- 上行是推流方自己的资源：免费不等于无限。双轨同播的上行是两套码流之和，2026-10-24 在托管节点上的一次 WHIP 推流样例约 4.5~4.7 Mbps（H264 三层约 3.1~3.5 Mbps，HEVC 三层约 1.2 Mbps）；EP10 里单路上行从 2.87 Mbps 涨到 5.35 Mbps 就出现了 3.6%~4.7% 的丢包。上线同播前先实测上行余量。
- 编码算力也是代价：多档位 + 两个 codec 要多开几路编码器。
4. 时延节约¶
下面四个数字都是含播放缓冲的端到端时延：
| 路径 | 端到端时延 | 相对 WHIP |
|---|---|---|
| P2P 直连 | ≤ 110ms | 低约 42% |
| ERTMP 推流 | 约 150ms | 低约 21% |
| WHIP 推流 | 190ms | 基线 |
| SRT 推流 | 约 360ms | 高约 89% |
P2P 直连 |███████████ ≤110
ERTMP |███████████████ 150
WHIP |███████████████████ 190
SRT |████████████████████████████████████ 360
- P2P 比 Edge·WHIP 低 (190−110)/190 ≈ 42%，比 SRT 低约 69%；
- WHIP 比 SRT 低 (360−190)/360 ≈ 47%，差值主要来自 SRT 入库端的固定接收窗口，这是协议在"弱网鲁棒性 ↔ 时延"之间的取舍，不是编码格式的差异；
- ERTMP 约 150ms 是网络干净时的数字：它跑在 TCP 上，一旦丢包就会发生队头阻塞（EP07），所以弱网下不能指望这个值；
- 不转码让服务端路径只有 RTP 透传的转发开销；传统方案里转码会增加多长延迟取决于厂商实现，本项目没有对等实测，不给数字。
这组数字的口径是含播放缓冲，与 EP01、EP02、EP12、EP13 里引用的 70ms / 108ms / 386ms 不是同一次测量，口径也不完全相同（那组基线的测量条件见 EP12）。两组数字不要混着比较，引用时请带上测量口径。
5. 把三笔账合在一起¶
flowchart TD
P["推流端 ppobs：WHIP/SRT/ERTMP 同播<br/>本机转码，多档 × H264 + HEVC"] --> O["Origin / Edge：RTP 透传，不转码"]
O --> V1["HEVC 观众：直连 Edge<br/>码率更低"]
O --> V2["H264 观众：优先尝试 P2P"]
V2 -->|"命中"| V3["P2P 直连<br/>Edge 下行 = 0，时延 ≤ 110ms"]
V2 -->|"未命中 / 名额满"| V4["回落 Edge·H264"]
P -. "所有观众共享" .-> C["转码费 = 0，上行不计费"]| 观众类型 | 带宽 | 时延 | 成本 |
|---|---|---|---|
| HEVC 观众 | 码率更低 | 取决于入库协议（WHIP 190ms 等） | 转码费清零 |
| H264 观众，P2P 命中 | Edge 下行 0 | ≤ 110ms | 转码费清零 |
| H264 观众，回落 Edge | 基线 | 取决于入库协议 | 转码费清零 |
6. 边界与代价，别藏¶
- "HEVC 省 30%~50%"依赖编码器：软件/慢档编码落在这个区间，NVENC 实时档实测均值约 15%；换内容、换 preset，结果都会变。
- 转码占 50% 是场景假设：只对采用 ABR 且在云端转码的业务成立，请用自己的账单验证；账单里本来没有转码费，这一项就是 0。
- 上行是推流方自己的资源：双轨同播约 4.5~4.7 Mbps，先测上行余量。
- P2P 命中率和字节分流比例缺生产数据：大房间里受 3 路上限约束，收益有限；1v1 和小规模才是主场景。
- ERTMP 跑在 TCP 上：约 150ms 是网络干净时的值，弱网下会被队头阻塞拖慢。
- 时延数字有口径：含播放缓冲；样本量有限，不是 SLA；不同测量日期和网络下会有差异。
- 计费口径：PPCDN 的计费设计是不收转码费、不收上行费，按下行流量和录像存储计费；但生产环境当前实际执行的是固定日费，按流量计费开关是否已经打开，目前没有已确认的部署记录，所以"节约"目前能确认的是成本侧，客户账单侧要等计费方案真正生效。
- 不与友商比较：EP12 讲过，没有对等条件下的友商原始数据，本集不对任何厂商下优劣结论；提到的云厂商转码计费只用于说明费用结构。
7. 三种数字，别把后两种当第一种¶
① 实测的¶
- 时延：P2P ≤ 110ms、ERTMP 约 150ms、WHIP 190ms、SRT 约 360ms（含播放缓冲）。
- HEVC 同 VMAF 码率节省：软件编码均值 39.3%，NVENC 均值 15.0%（本集，小样本）。
- 双轨同播上行约 4.5~4.7 Mbps（2026-10-24 单次 WHIP 推流样例）。
② 建模的¶
- 采用 ABR 时转码流量占 50%（场景假设，需替换为您的账单）。
- 带宽公式
f × h + (1 − h) × q里的h、q（取值是示例）。 - 三项节约的量级合成（第 1 节）。
③ 还没验证的¶
- P2P 的生产命中率与字节分流比例。
- 您自己内容集上的 HEVC 节省率。
- 按流量计费生效后客户账单侧的真实变化。
8. 怎么算出您自己的数字¶
- 成本：打开云厂商账单，找出转码相关条目占总额的比例，代入第 3.2 节公式。
- 带宽（HEVC）：用您的代表性内容，按 EP10 的方法做 H264/HEVC 同 VMAF 码率对比，换成您实际使用的编码器和 preset。
- 带宽（P2P）：统计房间规模分布和 H264 观众占比，用
q ≤ 3 ÷ H264 观众数估上限；上线后用生产的 P2P 字节占比替换。 - 时延：用 EP08 的 SEI 打点在您的网络里量 P50/P95，别只看平均值（EP09），并写明是否含播放缓冲。
- 上行：实测推流端上行余量，决定发几层、发几个 codec。
9. 全系列收官¶
到这里，这门课就全部讲完了。我们从第一集的"互动视频游戏的困境"出发，走过了协议选型、弱网、可观测性、质量、P2P、节点池、扩容、突发、部署、录像、压测，最后回到钱。
如果要用一句话总结 PPCDN 的省法：用 ppobs 在推流端本机转码、三种协议同播，不在网络侧转码就做到 ABR，把云端转码费降到 0；再用 HEVC 压低下行码率，用 P2P 绕开 Edge 并把端到端时延压到 110ms 以内。 带宽、成本、时延三项节约的量级都落在 30%~50% 附近，但每一项都有成立条件，别拿一个数字当通用承诺。
这套系统的代码是开源的，欢迎自己去部署、去压测、去把那些"还没验证的"补上——那才是这门课真正的续集。