目前行业的现状
从目前整个业界来看，没有一个统一的质量评价体系标准。
虽然各大公司，在多媒体方向有众多的布局，甚至像华为这种公司不断的推出业界的标准。但是流式系统应用在各个行业领域，和普通的多媒体视频领域的评价标准还是不太一样。
基础知识点
专业术语 （Terminology)
- RTT (round-trip time) 往返时延
- QoS （Quality of Service） 服务质量
- MOS （Mean Opinion Score ）主观评价分数
- FPS （frame per second) 帧率
- FEC (Forward Error Correction) 前向纠错
- JB (jetter buffer)
- NACK (Negative Acknowledgement) 负向反馈
1 流式传输中总体技术指标及细节解释
| 技术指标 | 指标解释 | 主要目的 |
| 丢包 (Packet loss) | 所丢失数据包数量占所发送数据包的比例 | 使用丢包率判断当前网络质量，不过丢包也分为拥塞丢包，随机丢包等，随机丢包情况下，我们不能通过得到的丢包率认为当前网络质量差，发生拥塞。这也是现在很多拥塞控制算法不使用丢包率作为主要衡量指标的原因。 |
| 抖动 (Jitter) | 在网络传输中，每个包从发送端到接收端的时延都是不相同的，而jitter就是用来衡量这种不同   | 传输过程中由于拥塞，丢包，网络错误等，接收端收到的数据包间隔就会不一样，导致时延发生变化，接收端如果不做任何处理，就会影响用户体验。例如会导致帧率变化，视频播放就不平滑，有卡顿感 |
| RTT（round-trip time） | 网络请求从起点到目的地然后再回到起点所花费的时长（不包括接收端的处理时间）  | 诊断网络连接的速度，可靠性以及拥塞程度。 |
| 延迟（Latency） | 流式方案本身处理有一部分延时行为，比如即便在延迟表现很好的内网，由于各种拥塞控制算法，延时表现还是有。 | 整体处理链路的耗时。影响FPS的计算和行为。最终也影响图像表现。 |
| 带宽探测(QoS) |  | 实时探测链路的带宽情况，包括，丢包，抖动，乱序等情况。 |
| 编码器（Encoder） |  | 处理图像转视频数据的编码。解码。编码器本身处理有时间，一般在30ms左右。编码器也有延时，主要是处理缓存内容等 |
2 主要的评价维度
我们在基础知识点部分提到过，流式系统的几个重要概念，分辨率，帧率，码率。
这几个参数粗看有点接近，细看，分别作用域是不同的。在最终的评价维度侧，这几个重要的概念将发挥决定性的评估和测试检验作用。
下表针对重要的内容和计算方式，进行再一次梳理。
| 内容 | 解释 | 计算方式 | 流式方案建议 |
| 分辨率Resolution | 指图像占用屏幕上像素的多少。图像中的像素密度越 高，图像的分辨率越高 | 大小=图像宽度*图像高度* 图像通道数比如 一副图像1920*1080，4通道大小=1920*1080*4*8 | 高级应用决定 |
| 帧率 FPS | 指视频每秒播放帧（图像）的数量。播放的帧数越多，视频越流畅。 一般动画片/电影的帧率在24帧/秒以上， 高清视频的帧率在60帧/秒以上。 对于实时通信的视频来说，15帧/秒是一个分水岭， 当帧率小于15帧/秒时，大部分人会觉得视频质量不佳，卡顿严重。 | 配置为30fps | 24~30FPS |
| 码率Bitrate | 指视频压缩后，每秒数据流的大小。原则上，分辨率越 大，码率也越大。如果出现分辨率大而码率小的情况，说明在视频编码时丢弃了大量的图像信息，这将导致解码时无法将图像完整复原,从而造成失真。因此我们可以得到结论：在相同分辨率的情况下，码率越大还原度越好，图像越清晰。当然，这里的码率大小是有限制的，超过一定阈值（MOS=5）后，再大的码率也没有意义了。 | 按照流式30fps的基准，一副1920*1080图像 每一秒的数据量=1920*1080*4*8*30 (bits/s) = 1990,656,000 bits/s按照1 Mbps = 1,000,000 bits/s总数据量是1990Mbps/s | 自动适应 |
有一个重要的经验点是：
必须要针对不同的行业，使用流式系统具体的输出标准来制定一套衡量标准框架体系。
下图是我们青龙流式系统，截至第一个版本发布前的质量评价体系完成内容和各个方向的布局。
可以给其余的同学做一个抛砖引玉的作用。
视频/图像质量判断标准和感受
| 缩写 | 全称 | 解释 |
| PSNR | 峰值信噪比 | 基于对应像素点间的误差 |
| SSIM | 结构相似性 | 亮度 (luminance)、对比度 (contrast) 和结构 (structure)。 |
| VMAF | 多评估方法融合 | 衡量大规模环境中流播视频质量的观感 |
| NIQE | 自然图像质量评价器 | 从自然场景图像计算的默认模型进行比较的非参考图像质量评估模型 |
图像/视频质量和码率，分辨率的制约关系
视频服务质量的评价标准有几个，它们也都是通过vMOS（主观平均意见分数）值打分来判断质量好坏的，图中参考是以码流大小为标准评估指标。（MOS是音质标准，vMOS是视频）
从以上可以看到，在保证传输的实时性时，由于带宽是一定的，可能会牺牲一定的服务质量。
图像分辨率/帧率/码率/带宽建议【H264编码器基础上】
| 图像分辨率 | FPS | 网络带宽建议 | H264硬件编码器 建议码率 中 | 建议码率 低 | 建议码率 高 |
| 720P 1280X720 | 30 | 3~5Mbps | 2500 Kbps | 1500 Kbps | 4500 Kbps |
| 1080P 1920X1080 | 30 | 5~7Mbps | 4500 Kbps | 2500 Kbps | 8500 Kbps |
| 2K 2560*1440 | 30 | 10Mbps | 8000 Kbps | 4500 Kbps | 16000 Kbps |
| 4K 3840*2160 | 30 | 20Mbps | 16000 Kbps | 8000 Kbps | 32000 Kbps |
编码方式/帧率/分辨率 影响建议 【业界经验值】
| 方面 | 影响表现 |
| 编码影响 | 编码从H.264到H.265，H.265到H.266压缩比预计分别提升30%左右 |
| 帧率影响 | 帧率提高一倍，压缩比预计提升50%左右 |
| 分辨率影响 | 分辨率提升一倍，压缩比预计提升15%左右 |
| 带宽 | 网络带宽建议值 = 码率 * 1.6 |
实时通讯中延时对于人的感受
| 延迟时间 | 人的感受 | |
| 1 | 0 ~ 400 毫秒 | 人感觉不到视频在通信过程中的延迟 |
| 2 | 400 ~ 800 毫秒 | 人能感觉到轻微延迟，但不影响通信互动 |
| 3 | 800 毫秒以上 | 人能感觉到延迟而且影响通信互动 |
带宽差时，为保证音视频的实时性要求，各技术指标会有以下问题 及 流式传输中的控制策略
| 低带宽 | 发生情况 | 流式处理策略 | 技术指标 |
| 丢包 | 随机丢包【物理/原理原因】主动丢包【拥塞控制算法等】 | （ARQ自动重传请求） → NACK+ACK否定确认（NACK）- 丢包重传 → 默认开启前向纠错（FEC）- 冗余信息附带→ 默认开启 | <2% 优质网络 （增加发送带宽 8%） 2%~10% 正常网络 （不变化） <20% 差网络 （降低发送带宽（1-0.5*丢包率））带来的延时损耗NACK==>1.5RTT+ kDefaultSendNackDelayMs （源码默认10ms）FEC ==> 以带宽换延时技术实现建议在延时容许的前提下尽可能使用 ARQ，可根据当前 RTT 和最大延时限制计算最大重传次数如果最大重传次数可以将丢包率降低到一定程度以下（<%1)，则不必开启 FEC 保护随着 RTT 的上涨，FEC 的保护占比增加，最终由 FEC 单独负责丢包修复。（如下图）源码中重传次数最大是10次针对于NACK的自己延时，源码中控制对象为kDefaultSendNackDelayMs，默认为10ms 如果需要调整，可以通过field_trial接口传递设置 |
| 抖动 | 画面不平缓 | JitterBuffer – 默认开启有了丢包率就可以算出需要多少次重传才可以将这个包重传回来，根据重传次数和RTT，大致能估算出需要多少JitterBuffer来应对该次网络抖动，实时感知和调整 | <7 ms 一般<4 ms 优质 |
| RTT | 每秒变化 | 同时可在Sender Report（SR）和Receiver Report（RR）RTCP Extended ReportsRTCP（XR）中探测到实时RTT数据。超过默认RTT后，认为超时需要重传 （默认100ms）如果发现系统莫名的在流畅的网络中也有100ms的RTT表现，则需要检查RRTR是否开启。 RRTR默认没有开启，碰到这种问题需要通过SDP手动开启当超过RTT的阈值后，流式启动重发策略，会导致真实图像数据传输大幅下降 | < 20 ms 一般< 15 ms 优质源码中默认100ms. |
| 带宽探测QoS | 每秒都在探测 | 基于延时的评估体系后端 REMB → 默认开启前端 TCC→ 默认开启 （更准确些） | |
| 整体链路用时（延时） | 网络原因随时发生 | 内部拥塞控制会有一些自带延时。业务逻辑是主要延时部分 | 考虑到< 30ms的要求，网络层的30ms在目前的整体链路中的延时貌似都可以接受。总延时=业务处理时间+webrtc内置延时 +网络延时webrtc内置延时=抖动延时(0~100ms)+RTT延时(10~100ms) +FEC (10~20ms) + 硬件编码器延时(~50ms)要注意：即便取消数据加密，这块的延时也是可以忽略不计的 |
RTT不同阶段对于流式系统的表现和对策
| RTT情况 | 流式内置算法策略 | 流式逻辑层可以控制的内容 |
| <100ms | 平滑表现 | 基本不需要做什么调整 |
| <250 ms 且 >100ms | 启动抖动控制算法和丢包重发策略 | 降低码率，取消FEC，调整编码器GOP设置 |
| >250 ms | 表现不可接受 | 调整已无力 |
RA/SD 衍生者AI训练营。发布者：chris，转载请注明出处：https://www.shxcj.com/archives/5786
