EP10：如何量化视频质量¶

上集回顾	EP09《时延稳定性，比平均延迟更重要》
下集预告	EP11《Netflix 的无缝切换给我们的启发》

0. 本集目标¶

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

理解 VMAF/PSNR/SSIM 为什么不适合放进实时转发热路径，但仍可用于离线或旁路抽样评估。
区分码流/信令可验证属性、编码器自报配置和像素级感知质量，知道每类证据能回答什么。

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

前两集讲的是延迟稳不稳，这一集换一个维度：画质好不好。像素级比对确实需要解码，但“实时转发链路不解码”不等于“系统永远不能做画质评估”。关键是把在线热路径、旁路抽样和离线实验分开。

2. 行业标准怎么测画质，为什么不应阻塞实时转发¶

2.1 三种主流客观画质指标¶

视频行业衡量画质通常用三类客观指标：

PSNR（峰值信噪比）：逐像素比较压缩后画面和原始画面的数值差异，历史最悠久，但和人眼主观感受的相关性并不强——数值上差异很小的两张画面，人眼可能觉得差别很大，反之亦然。
SSIM（结构相似性）：不看单个像素的数值差异，看局部区域的结构、亮度、对比度是否相似，比 PSNR 更贴近人眼对"画面结构"的感知，但仍然是纯数学模型。
VMAF（Video Multi-method Assessment Fusion）：Netflix 主导开发的感知质量融合模型，把多种子指标结合机器学习训练出的权重，融合成一个和人眼主观打分高度相关的分数，是目前业界公认更接近真实观感的客观指标。

2.2 三者需要像素，但可以离线或旁路运行¶

不管是哪一种，计算方式的共同前提都是逐帧拿到原始画面和压缩后画面的像素矩阵，逐帧比对。这意味着必须要有一个环节把压缩后的码流解码还原成画面，才能算出这些指标。

Origin 到 Edge 的实时媒体热路径保持透传、不转码是合理取舍；在这条同步链路里逐帧解码并等待 VMAF，确实会增加算力、延迟和故障面。但评估任务可以异步旁路：按策略复制少量码流到分析服务，或在测试环境同时保存参考源和编码输出，离线解码、对齐后计算指标。它不会阻塞正式媒体转发。

因此准确说法是：不在实时转发热路径计算全量像素指标，但可以用离线基准、回归测试和旁路抽样做 VMAF/PSNR/SSIM。全参考 VMAF 还要求参考源、失真流正确配对并做帧级对齐；没有参考源时应选无参考/弱参考模型或主观抽检，不能把代理指标冒充 VMAF。

3. 在线观测：把可验证属性与代理指标分层¶

在线热路径不做像素比对时，可以组合三类证据判断异常，但结论应叫“配置/传输/播放健康度”，不能直接等价为感知画质分数。

3.1 可从信令或码流验证的属性¶

无需像素解码也能验证一部分属性：协商信令可见 codec、profile、payload type、RID/simulcast 声明；RTP 头和接收统计可算实际吞吐、包率与时间戳节奏；解析 H.264/HEVC 参数集和帧头可得到编码分辨率、部分色彩/层级信息并识别关键帧。能否读取某项取决于封装、加密边界和协议实现，但“服务端完全不知道”并不准确。

目标码率、编码预设、质量参数和编码器内部复杂度通常仍需发送端上报。自报值应与码流可观测值交叉校验，并明确区分“声明配置”和“实际输出”。

本项目已经把这套交叉校验落成了生产功能：ppobs 会把编码器声明的 codec、分辨率、目标码率、关键帧间隔、Simulcast 层数等摘要字段上报给 ppcenter（POST /v1/encoders/report），AI 直播健康报告再拿这份声明值和同一条流实测的 SRT 码率比对——声明码率远高于实测码率时在“上行”维度扣分，关键帧间隔超过 2 秒则只提示不扣分；编码器没上报或版本太旧时，这一维度标记为数据缺失，报告照常生成，不会因为缺一类证据就整份失败。这正是“声明配置”和“实际输出”分开记录、交叉校验的真实例子。

3.2 上行链路健康：配置和实测对不上，本身就是信号¶

编码器声明“目标码率 3Mbps”不代表实际输出恒定为 3Mbps，尤其是 VBR 和低复杂度画面。应结合实际发送码率、可用发送码率、队列、协议原生丢包/重传统计和发布层状态判断，不能仅凭“实测 1Mbps”断言已经降级。内容复杂度和码控模式也是解释变量。

生产环境里有一个真实案例能说明这件事：排查单路 H264 推流链路时，把编码器目标码率从 1500kbps 调到 3000kbps 后，实际上行从 2.87Mbps 涨到 5.35Mbps，Origin 侧 SRT 摄取丢包从 0% 跳到 3.6%~4.7%，下游节点的 RTP 分片重组随之开始报错——而同一时刻 Origin 到下游节点的内网转发却是零丢包。三类信号放在一起才能定位到真正瓶颈在“推流端到 Origin 的上行带宽”这一跳，而不是内网转发或协议本身的问题；只看编码器自报的目标码率，或者只看下游告警，都得不出这个结论。这条上行带宽的具体上限当时仍是一项尚未独立实测的开放项，不代表所有部署环境的固定值。

3.3 播放体验：画质再好，观众收不到也没意义¶

EP08、EP09 讲过的拉流成功率、首帧 P95、卡顿率、端到端时延 P95，严格来说不是"画质"本身，但它们决定了观众实际能不能收到、能不能流畅看到编码器本该提供的画质。一路配置了 1080P、上行链路也很健康的流，如果播放端卡顿率很高，观众体感照样是差的——画质判断如果只看编码端和链路，不看播放体验这一环，结论会是不完整的。

4. 一个例子：同样标着"1080P"，体验可能天差地别¶

单看"分辨率"这一个标签是不够的。两路流都配置成 1080P，一路上行链路健康、协议原生丢包/重传指标平稳、播放端零卡顿；另一路发送队列长期堆积、频繁触发发布层调整、播放端卡顿率不低——即使编码器自报的分辨率标签完全一样，观众实际看到的画质体验完全不是一个水平。这正是为什么要把三类信号组合起来看，而不是只盯着某一个孤立的数字（比如只看"标称分辨率"，或者只看"当前丢包率"）——单独一个信号都容易讲出一个片面甚至误导的故事，这和 EP09 讲的"只看平均值会撒谎"是同一类教训：单一指标的片面性，往往需要靠多个维度的信号互相印证才能补齐。

5. 框图¶

5.1 两种画质评估路径的对比¶

【离线/旁路：像素级客观指标】
参考源 + 抽样码流 ──▶ 解码与帧对齐 ──▶ PSNR / SSIM / VMAF
                         │
                         └── 异步运行，不阻塞实时转发热路径

【本项目做法：代理指标组合推断】
编码器自报配置 ──┐
                  ├──▶ 三路信号互相印证 ──▶ "这路流画质大概率正不正常" 的判断
上行链路健康   ──┤
                  │
播放体验       ──┘

（在线观测不做像素解码；离线/旁路评估补足感知质量证据）

5.2 代理指标的三块拼图¶

┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
│ 信令/码流可验证   │   │   上行链路健康    │   │    播放体验      │
│ codec/分辨率/层/  │   │ 协议原生统计/     │   │ 拉流成功率/      │
│ 关键帧间隔/       │   │ 降级恢复事件/     │   │ 首帧P95/卡顿率/  │
│ Simulcast层数     │   │ 配置码率vs实测码率│   │ 端到端时延P95    │
└────────┬─────────┘   └────────┬─────────┘   └────────┬─────────┘
         │                      │                      │
         └──────────────────────┼──────────────────────┘
                                 ▼
                    "画质有没有问题"的综合判断
                 （三块任何一块单独看都可能片面，
                   互相印证才接近真实体验）

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

这一集把在线与离线评估分开了：实时转发热路径不应被像素级分析阻塞，但离线基准和旁路抽样完全可以计算 VMAF/PSNR/SSIM。在线则要区分信令/码流可验证属性、编码器声明、链路健康和播放体验；这些信号适合发现异常，但不能冒充感知质量分数。

下一集我们聊聊 Netflix——它在无缝切换上的经验，能给这套系统什么启发。