共计 5087 个字符，预计需要花费 13 分钟才能阅读完成。
本文依据网易云信资深引擎工程师戚继跃在《MCtalk Live#4：视频 QoE 的均衡之道》线上直播分享整顿，文末有直播视频回顾以及 QA 整顿。
导读
互联网倒退迅猛，实时通信（Real Time Communication，简称 RTC）需要一劳永逸。如何在各种简单网络服务质量（Quality of Serverice，简称 QoS）下，以及参差不齐的硬件终端上获得最佳的视频体验品质 (Quality of Experience，简称 QoE)，是 RTC 技术的重要一环。
本文从视频品质控制系统（Video Quality Controller，简称 VQC）模块登程，介绍网易云信 NERTC 在晋升视频 QoE 方面做的一些工作。
VQC 在视频 QoE 中的作用
视频的 QoE 次要蕴含视频的清晰度、视频晦涩度、视频延时三个方面的指标，整体上由网络 QoS、视频解决算法、VQC 独特决定：
- 网络 QoS：提供尽可能充沛的可应用带宽
- 视频解决算法：在肯定的码率下，输入尽可能好的视频品质
VQC：
- 对 QoS 负责，管制码率，保障晦涩度和延时
- 对视频算法负责，保障性能，均衡清晰度和晦涩度
VQC 通过对视频 QoS 状态、视频算法状态的监控，输入管制信号，达到场景化的最佳 QoE 体现，包含均衡清晰度、晦涩度、延时这几个指标。明天，咱们次要分享网易云信 NERTC 上的 VQC 实现以及 QoE 调优的相干工作。
网易云信 VQC 实现
网易云信的 VQC 模块局部参考了 WebRTC 的模块设计，整体构造如图中所示，次要蕴含四个监控模块和一个策略模块。输出的参数通过监控模块后失去以后的各种状态后果，而后由 VQC 策略模块决定最终输入的管制信号，管制视频 pipeline 的工作。上面，咱们具体介绍每个模块。
QualityScaller
QualityScaller 模块的作用是监测以后的编码品质，次要对清晰度和编码器稳定性负责。
该模块输出依据编码器类型和编码算法类型而确定的 QP 阈值、以后输入编码帧的 QP 值、以后丢帧的统计数据，输入视频品质好坏的后果。
其中 QpSmoother 模块应用指数加权累加的形式来确定 QP 的统计值，如下：
咱们具体看一下这个公式的组成，公式中：
- sample 为以后帧的 QP
- 输入 y 为 QP 统计值
- alpha 是依据编码器 QP 变动个性总结的一组系数值，依据下限和上限应用不同的系数值。比方咱们测试下来针对 OpenH264 编码器，QP 下限系数值能够应用 0.9995，QP 上限系数值能够应用 0.9999。通过这种差异性的上上限系数，达到视频品质变差时（QP 减少）反馈迅速，视频品质变好时（QP 减小）反馈略微机灵的成果。
最终统计的上上限 QP 统计值，与输出的 QP 阈值比拟判断，决定以后画质的好坏。输出的 QP 阈值也是依据编码器不同而不同的，比方在 OpenH264 上咱们测试下来应用阈值上限为 24，下限为 37；硬件 iOS 设施上硬件编码则应用其余值，Android 上硬件编码则又不同，这都须要依据设施的大量验证来获取。
MovingAverage 为一个滑动窗口函数，取这个窗口内的丢帧比例，超过肯定阈值认为是品质变差。
最终外部周期性查问模块会收集 QpSmoother 和 MovingAverage 的统计后果，输入两个后果（不输入不计入后果）：
视频品质好
- QpSmoother 的 QP 统计值上限小于等于 QP 上限阈值
- MovingAverage 统计的丢包率超过阈值
视频品质差
- QpSmoother 的 QP 统计值下限大于 QP 下限阈值
OveruseFrameDetector
OveruseFrameDetector 模块次要作用是监测以后的性能是否撑持当下帧率的运行，对视频的晦涩度负责。
该模块输出以后的指标帧率、分辨率、CPU Usage 阈值，采集和发送视频帧工夫，输入以后性能好或者坏的后果。
ProcessingUsage 模块通过输出的视频帧采集和发送的工夫，统计整个视频发送链路即视频采集到发送的时长，用这个时长做一些平滑运算后失去一个统计值，用这个统计值和以后帧率下帧距离的实践时长做比拟，统计时长是否超过理论值，并记录次数。而后周期性的收集次数，超过肯定次数则输入性能差 CPU bad 的后果，低于肯定次数则输入性能好 CPU good 的后果。
在该模块中，须要避免一些假的 CPU good 或者 bad 后果，比方：
- 样本数量少时（比方帧率低），周期性收集数据的工夫没有变，这就容易导致后果误差
- 新的帧率分辨率刚开始工作时，各个环节的解决工夫还没有问题，也须要非凡解决
RateAllocator
RateAllocator 模块负责决定以后码率的应用，在大小流场景下充当大小流应用的策略模块。
该模块有几个关键性作用：
- 远端有多个用户，其中有用户订阅了小流也有用户订阅了大流，该模块会决定无限的码率依照什么比例调配比拟适合
- 同样的场景，在码率非常有余的状况下，该模块会决策大小流合并成一条流应用，晋升画质
- 在上行的带宽受限状况下，该模块会决策发送端有没有必要升高带宽发送
MediaOptimization
MediaOptimization 模块次要负责监测和修改实时的码率和帧率，避免码率超发导致网络拥挤，因为拥挤后网络会进一步好转，导致画质、晦涩度、延时全面的升高。
该模块管制实时码率次要通过外部的 FrameDropper 模块，其应用漏斗算法决策以后是否码率超发，是否须要丢帧来稳固码率。
在每一帧编码之前，将该帧的指标码率作为输出放入漏斗中，编码之后将以后帧的理论码率作为漏斗的输入，而后去查看漏斗是否满了，如果满了就抛弃下一个编码帧来管制码率。漏斗的容量大小和能够容忍的延时相干，须要进行场景化定义。
丢帧与否的后果也会输入给 QpScaller 模块，作为评估编码品质的根据的一方面。
VQC 决策模块
VQC 决策模块依据 VQC 外部前述所有模块的后果，联合用户的场景设置，决策当下的视频策略。
其外部蕴含两个状态机以及一个决策模块。
两个状态机互相独立，互不影响：
- 视频品质状态机
- 性能状况状态机
一个决策模块，咱们具体阐明其中的一些重要性能：
- 依据用户设置的场景以及冀望视频参数，设置各种外部调整的阈值
- 依据状态机的后果，决策进步或者升高视频的参数（分辨率、帧率），以及进步或者升高的策略
- 依据其余信息，决策以后帧编码的其余参数，比方 simulcast 双流场景下大流或者小流是否编码
- 依据其余信息，决定算法是否须要调整，比方编码算法，后处理算法等
通过 VQC 进行视频 QoE 调优
VQC 通过对视频品质的全链路监控和调节来保障良好的视频 QoE，上面介绍下云信 RTC 这边在通过 VQC 调优 QoE 方面的一些工作。
正确判断编码品质
表征编码品质的参数有很多：PSNR、SSIM、QP、VMAF 等，因为硬件编码器的特殊性以及参数获取计算成本的思考，选用了 QP 作为评判规范。
如果抉择应用 QP 作为正确反馈编码品质的指标，须要思考如下几点：
- 惯例的 Slice QP 在 H264/265 编码中，个别编码器中只能反馈后面几个编码宏块的品质。在软件编码上能够应用更优的 average QP 来作为视频帧的 QP，这样判断软件编码品质成果更优。
- 不同编码算法的 QP 阈值是不同的，比方咱们在 OpenH264 上能够应用（24，37）作为 QP 好坏判断的上上限，然而在不同的编码器和不同的编码算法上就须要调整，比方咱们的 NE264、NE265、NEVC 编码算法都须要做对应的适配调整。
- 不同硬件加速平台上编码器的 QP 的阈值是不同的，比方 iOS 零碎、Android 零碎，甚至 Android 不同的芯片平台也须要做对应的适配。
- 不同编码算法，不同硬件平台，QP 品质变动的曲线不同，为了提取特色，须要调节统计办法的统计系数。
正确判断性能问题
为了避免性能问题导致的视频 QoE 升高，咱们须要能精确的甄别出性能问题并作出正确无效的调整。以后咱们的 VQC 中，应用视频帧解决工夫来表征性能状态，想要正确甄别性能状态，须要思考以下几个方面：
- 能判断编码和前解决的整个流程的性能
- 一些硬件有 pipeline 延时须要思考
- 如果帧距离不平均，会导致误断定性能问题，须要辨认出这种特色
为了进行无效的调整，咱们次要须要思考以下几个方面内容：
- 依据测试中性能耗费的优先级来调整，比方咱们测试下来局部模块的优先级是：前解决 > 编码算法 > 帧率调整 > 分辨率调整
- 如果做了相应的调整，统计的性能状态还是没有变动，咱们须要有相应的解决伎俩，反馈调整内容和后果给状态机，让状态机报告给决策模块进行下一步决策
- 如果性能状态变动过大，须要拉大调整步长
最优化调整
无效的调整就是是调整后视频 QoE 晋升显著，咱们次要能够通过以下几个方面进行调整：
- 分辨率调整
- 帧率调整
- Simulcast 流的调整
- 前解决的一些算法开关
- Codec 调整
VQC 是如何进行最优化调整的呢，如下：
反对用户可配置多种场景和策略
- 通信模式，直播模式
- 用户高可定制化：非凡场景模式，分辨率不变模式，帧率不变模式，最小帧率最小码率等设置
- 外部自适应调整，依据大量测试试验确定某个具体场景下的参数组合，调整步长以及最佳门路，比方如下视频分辨率和帧率调整步长和门路
结语
本文次要介绍了网易云信 RTC 中视频品质控制系统 VQC 的设计，以及在 QoE 调优方面的一些工作。没有一种策略是白璧无瑕的，鱼和熊掌不可兼得。咱们在 QoE 调优中做的工作就是在肯定的条件下，通过一些列伎俩均衡清晰度、晦涩度、延时这些指标，趋利避害。通过互相配合的策略以及大量的数据测试验证，寻找出最优的策略。
QA 整顿
以下内容，依据线上直播群内 QA 记录整顿：
- @一苇以航 发问：
Q：请问 ratecontroller 的时候，个别都是 SFU 转发模式，这个时候的 simulcast 是从服务端思考所有订阅端反馈给发送者去调整大小流的码率吗？
A：咱们服务端做了各种场景下的策略，默认是走可配置的 TopN 策略，局部头部观众尽量应用高清高晦涩的大流，大量网络品质不好的用户应用小流，服务端会依据上行所有观众的网络状况，算出一个适合的反馈码率
Q：恩，我的问题不是问服务端的 SFU 转发策略，而是发送端在大小流的码率调整策略，你们谈 ratecontrol 这个模块的时候说到了一点，发送端收到一个 cc 的带宽反馈，同时发送端提供了 simulcast，你们如同还可能思考到不同的接收端的网络状态，进行大小流的码率调整，是有这个能力吗？
A：咱们有上行的 cc，服务器会依据上行 cc 输入的预计带宽，而后综合出一个适合的带宽反馈给发送端。Simulcast 是端上依据总的码率，在咱们模块外面做决策，是发大流还是小流，还是双流。服务端也会依据每个端的状况，决定给上行发送大流还是小流。
Q：美颜跟超分会带来多大的提早？
A：对于美颜跟超分会带来多大的提早的问题：小于帧距离，不会 delay 咱们 pipeline，咱们做了动静适配，如果大于帧距离，会动静敞开掉，对整个流水线的延时小于一个帧距离，如果 30 fps 就是小于 33ms。
Q：个别做这一块的都是基于 WebRTC 去做的，如同中途要切换 codec 的话，要么就从新创立 peerconnection 从新协商，你们反对是因为自研增加的吗，还是 WebRTC 自身反对呀？
A：咱们有局部参考了 WebRTC，codec 切换这块不须要从新协商，咱们做了频道内的能力协商，是公有协定，不须要像 WebRTC 那样做 sdp 替换，咱们有本人的能力协商协定，而后音视频引擎外部做切换。
Q：还有一个问题，你们在 RTC 会议房间里如何解决关键帧申请，每一个新退出的用户如果都发关键帧申请，会导致房间的流量很大，然而不发的话等到下一个 GOP 会很久，你们采纳了什么样的策略去平衡？
A：1. 个别逻辑是每个新退出的用户都会有 intra request 收回来，而后接收端有一个 key frame 发送距离的管制。这样不会有太多 key frame，也不会导致出图很慢。
- 当然咱们为疾速出图做了些优化，提前服务器 intrarequest, 保留近期的 key frame 等操作。
这些都是咱们理论调整的一些细节，须要依据本人的场景去适配，咱们也是分场景的。直播和通信策略就不一样。 @galen 发问：
Q：求教下怎么检测卡顿呢，个别检测卡顿帧间隔时间有考究吗？
A：卡顿咱们会统计 200ms 卡顿和 500ms 卡顿，检测理论渲染的帧率距离，超过 200ms 或者 500ms，统计小卡顿或者大卡顿。作者介绍
戚继跃，网易云信资深引擎工程师，长期从事音视频相干开发工作，对 WebRTC 引擎，音视频会议零碎，视频编解码等有深入研究。目前次要负责网易云信 NERTC 引擎的视频体验。
视频回顾地址：https://mctalk.yunxin.163.com…
