导读：RTC 场景视频的体验指标主要包括视频延迟、视频流畅度、视频清晰度。在一定条件下视频的最佳体验主要指延迟、流畅度、清晰度达到均衡，达到条件下的最佳主观体验。本文主要介绍，为了能够调节出一个最佳的体验效果，网易云信在工程架构和策略方面做的一些工作。
文｜戚继跃
网易云信资深引擎工程师
RTC 的视频体验质量对外受用户网络环境、用户使用姿势、用户硬件平台影响；对内依赖我们的网络 QoS 模块、视频编解码模块、视频质量控制 VQC 模块、视频前后处理模块的密切配合。
单独调整或调优某一个模块，可以得到一定的收益，但是如果几个模块能够联动调节，那么可以极大的提升使用效果，得到 1 + 1 > 2 的效果。为此我们设计了自适应调节系统（Auto Adjust System, AAS），可以根据外部因素和内部各模块的工作状态，自适应调节各个模块工作参数，达到视频的最佳体验。
网易云信自适应调节系统
网易云信的自适应系统 AAS 分为配置自适应和工作中的动态自适应两部分，两者相互配合。配置自适应是指根据当前的用户配置、设备、网络供应商等信息，综合决策实际的视频配置；动态自适应是指在运行过程中，根据各个模块的反馈，决定视频参数的调整。配置自适应和动态自适应没有固定优先级关系，由具体的配置和参数自行决定。
配置自适应
配置自适应是指能够根据当前的用户配置、设备名称、网络服务商、所属地区等客观现实条件，自适应地选择一套最适合当前条件的视频参数。为了达到配置自适应的目的，我们设计了一套多维度层次化配置系统，包括初始默认生效参数、静态白名单、频道前配置下发、用户设置、频道内配置下发、能力协商，这些配置从前到后优先级逐步升高，即后面的配置可以强制修改前面配置的结果。
初始默认值：是指我们内部配置的默认值，如果不做任何其他设置这个配置就会使用这个值。
静态白名单：代码里面维护的一套设备相关以设备 device id 为索引的表，表里面存储需要使用的配置值。
频道前配置下发：在加入频道前，会从服务器获取一次配置信息，配置的信息在服务端维护，下发可以根据机型、地区、网络类型等进行下发。
用户设置：用户通过接口指定一些配置。
频道内配置下发：和频道前配置下发类似，不同点是发生在加入频道之后。
能力协商：比如 codec 格式这种配置，需要根据整个房间内所有人支持的解码格式来确定，所以需要每个人在加入频道内时候上报自己的解码能力，然后对所有解码能力进行综合，得出的结果下发给所有人。
动态自适应
动态自适应是指在工作过程中，能够根据当前网络、设备性能、视频 profile 等变化的监测，动态调整相关模块的参数。为达到动态自适应的目的，我们设计了动态自适应模块，目前该模块监测的变量包括当前视频使用的 profile（宽高帧率）、当前 codec 类型、当前软硬件编解码选择、当前 QoS 反馈的码率、当前编码流程的性能这些参数。动态自适应的内容包括是否切换 codec 类型、前后处理算法开关、视频大小流策略等。后续的开发的 feature 可以根据需要增加监测的指标，然后输出动态自适应结果。
应用举例
我们通过一个例子来展现云信的自适应调节系统的使用情况。在编码发送端，云信的编码器有软件的 ne264、ne265、vp8，同时有我们也做了硬件 264， 硬件 265 的适配。发送时选用哪个编码器，以及几个编码器之间如何相互切换，是个棘手的问题。
编码器能力分析
在使用自适应调节系统解决编码器选择问题之前，我们先来分析一下各个编码器的优劣：
ne264 输出标准的 264 码流，兼容性最好，码率最稳定，但是在高分辨率下性能是个问题，而且压缩率也不如 265。
ne265 输出标准的 265 码流，性能消耗最大，码率也不够稳定，很多设备性能不能支撑编码 265 码流，但是在高分辨率下压缩率有明显优势。
vp8 是 WebRTC 支持最好的格式，一些移动端的浏览器上只支持 vp8 解码，兼容性超过 264。
硬件 264 支持设备很广，性能有优势，但是编码的码率波动可能会比 ne264 要大。
硬件 265 在高分辨率下压缩率很有优势，支持设备一般，需要 case by case 的适配，码率波动很大，265 的解码性能也存在问题。
可以通过以下图片比较我们的几种编码器：
根据编码器的不同特性，可以设计编码器选择自适应如下：
配置自适应
根据我们对硬件设备适配的结果，在静态白名单上写上对应的硬件设备型号，是否支持硬件 264 编码，是否支持硬件 265 编码，是否支持 265 软件编码，是否支持 265 解码。
根据白名单的结果，按照硬件 265，ne265，硬件 264，ne264， vp8 从前到后的顺序选取当前设备支持的编码类型列表。比如某款 android 手机，通过查找白名单表我们得到 [硬件 265，硬件 264，ne264，vp8] 这样的支持列表，使用编码器时，按照优先级从前到后选择编码器，排在前面的优先使用。
在我们后续的测试中，我们发现这款 android 手机的硬件 264 不太稳定。于是我们更新白名单，去掉这款手机的硬件 264，并且在已经上线的 sdk 中，我们通过频道前配置下发中关闭硬件 264，得到新的支持列表 [硬件 265，ne264，vp8] ，用户设置打开了 265 优先，所以我保持 265 在列表内。
加入频道时，我们根据白名单中解码能力，上报了自己的解码能力集 [265，264，vp8]，同时在频道内的另一端某个设备不足以解码 265，上报的解码能力集是 [264，vp8]，服务端综合结果后给每个端下发的编码能力集是 [264，vp8]，于是我们支持列表变成了 [ne264, vp8]。最终这个用户在这次通话中使用了 ne264 编码器。
这个用户在长时间使用后，我们后台数据分析发现，经常会有 android 设备的硬件 264 码率不够稳定，这些设备使用 ne264 性能也是没有问题的，于是我们在频道内配置下发中，将这些 android 设备的硬件 264 关闭了，只保留 ne264。
动态自适应
某次通话，某个设备的支持列表是 [硬件265，硬件 264，ne264，vp8]，当前正使用硬件 265 编码发送。
动态自适应模块监测到由于性能问题，vqc 将视频 profile 由原来的 720p，30fps 调整为 360p，20fps。这个时候由于硬件 265 在这一档视频 profile 上收益已经不大了，所以我们切换硬件 265 到硬件264。
动态自适应模块监测到 QoS 的目标码率波动很厉害，超过了我们设定的阈值，这个时候我们判断是由于硬件 264 的码率不稳定，有可能在这种波动下造成超发从而引起延迟拉大，所以我们切换硬件 264 到软件 264，动态自适应模块监测到 QoS 目标码率变平稳后，再从软件 264 切回硬件 264。动态自适应模块监测到性能问题已经缓解，vqc 恢复了 720p，30fps 的视频 profile，这时候我们再由硬件 264 切换为硬件 265。
结语
本文主要介绍了网易云信 RTC 的重要组成部分——自适应调节系统。通过配置自适应和动态自适应，可以应对各种由于使用姿势、用户网络环境、用户设备等引入的不确定性，在一定条件下达到最佳视频体验。
作者介绍
戚继跃，网易云信资深引擎工程师，长期从事音视频相关开发工作，对 WebRTC 引擎、音视频会议系统、视频编解码等有深入研究。目前主要负责网易云信 NERTC 引擎架构和视频体验。
相关阅读推荐
6182
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
