融云实时通信全链路质量追踪与指标体系构建

10 月 21 日，在上海举办的 QCon 全球软件开发者大会上，融云联合创始人兼 CTO 杨攀作为出品人发起的技术专场「实时通信技术」，受到开发者的欢迎与关注。

融云首席架构师李淼、视频算法专家黄震坤、流 媒体 架构师许杰，分别带来了《全球低延迟通信网络的设计与优化》、《AI 算法在视频可分级编码中的应用》、《实时通信全链路质量追踪与指标体系构建》的主题分享。

（图1 从左至右依次为：黄震坤、杨攀、李淼、许杰）

今天分享许杰老师的演讲议题 —— 实时通信全链路质量追踪与指标体系构建。内容主要包括五大部分：实时音视频平台面临的质量挑战、融云实时音视频质量控制总体架构、客户端实时音视频质量检测、SDN 大网的组建与质量跟踪、链路问题的跟踪与查询。

获取讲师完整 PPT，请在【融云全球 互联网 通信云】公众号后台回复“许杰”。

（图2 许杰在 QCon 现场做主题演讲）

一、实时音视频平台面临的质量挑战

实时音视频平台面临的挑战，可以概括为三个“多样化”：

终端多样化。包括 OS 版本特性、硬编码差异、APP SDK 版本多等问题。

众所周知，iOS 和 Android 是比较新生的系统，处于快速迭代期。在迭代过程中，不论新老特性，包括厂商兼容性等问题都比较突出，这也给我们 ToB 平台带来很大挑战。不同于 PC 端升级有后台驻留引擎的帮助，移动端情况非常困难，很多 APP 还是几年前的版本。

而所谓“硬编码”—— 在移动互联网时代，硬件编解码得到了广泛应用。很多网红直播是在户外，如果用纯软件编解码，很快电量就会耗光。这也是为什么尽管其他编码器也陆续发布，但最普及的却仍是 H.264，与硬件有很大的关系。

全球网络多样化。涉及到网络种类差异、跨国出口、国外基础设施差异、专线建设限制等。其中前两项大家会感触很深，而在融云赋能大量企业出海的过程中，也非常深刻地体会到，海外基础设施建设与中国差异之大。

用户场景多样化，比如 1V1、教育、 金融 、会议、低延时直播、语聊房等。举一个简单的例子，假如某 APP 直播时平均观看时长为 10 分钟，但在某一时段突然跌至 5 分钟，我们就可以排查 —— 这种数值波动是不是由质量引起的，比如画面质量下降，或者是卡顿严重导致用户无法耐心观看、不得不频繁切换直播间？由此通过 QoE 监测，侧面反推质量。

二、 融云实时音视频质量控制总体架构

上面提及的种种需求侧的“挑战”，切换到解决问题的角度，还是要转化成技术思维。质量架构需要解决哪些问题？

首先是算法优化，包括编解码优化、弱网网络优化等。从实验室环境切入，看我们的研发质量究竟符不符合生产环境要求，生产环境泛化能力如何，先小规模地推到生产环境的网络上，如果发生问题，再进行召回。

其次是 SDN。SDN 建设就是如何评估服务器选点以后的覆盖能力，尤其在海外很多国家，像东南亚地区，其人员分布较广，基站、机房的覆盖能力同样需要严格审核。再有，如何评估当前的专线质量、全球链路质量，以及容灾恢复情况等，都需要及时进行监控。

再次是客户体验 —— 客户把信任交给我们，如何为客户提供可靠的实时全局状态监控？数据报表汇总一旦发现问题，又是如何查询链路细节信息、快速定位到问题所在？这些都是需要着力解决的问题。

带着上述问题，来看一下融云实时音视频质量控制系统的总体架构图（图3）。

（图3 融云 RTC 质量体系总体架构）

最底层是研发管理，包括用例管理、自动验证、链路跟踪、数据大屏、预警等。

中间层是融云全球“大网”SDN 的建设过程，其中比如日志系统 —— 从全球十几个大的节点把日志拉回来进行实时分析；路由管理，实际上就是整个系统的“大脑”，包括路径如何规划、容灾怎么做等等。

最上方是客户平台，我们有报表、数据大屏和链路信息自查系统。

三、客户端实时音视频质量检测

客户端 RTC 质量检测是本次分享的重点。

（图4 RTC 音视频处理流程&质量因素）

如图 4 所示，数据从发送端经过采集、前处理、编码、发送，接收上来数据以后进行解码、后处理、渲染，这就是 RTC 典型的一个数据处理过程。

显而易见，这个过程呈线性排布，由此带来的麻烦是，一旦某一环节出现差错，后续所有环节质量都会受到影响，就像一根“水管”，任何一个地方堵了，都会导致水流不畅通。

逐一来看：

采集端可能有硬件问题、焦点问题、噪点问题等隐患。硬件问题比如设备本身的解析度；焦点问题大家时常忽略，实际软件的自动对焦也会有失灵的情况，了解单反相机的人都知道，使用长焦镜头时焦平面非常短，稍微有一点问题都会导致画面不清楚；噪点问题是指，电子元器件在低感光度时都会有噪点，而这种“随机的小白点”对于整体质量的影响非常大。

有了噪点以后就需要前处理，即编码前的处理过程，包括美颜、下采样、去噪等。目前主要采用“单帧去噪”，效果尚可，缺点是在视频连续帧里面不会参考前后帧，导致帧与帧平均值不同，最后残差较大。

到编码阶段，转换、变换、量化也是画面降低最大的因素，因为它受制于网络的传输。众所周知，RTC 重点就是优化网络，尽量增大可用带宽，增强丢包、抖动的适应力，给编码创造比较好的条件。

解码是编码的反向过程，依然会遇到转换、变换的问题。而所谓“滤波”，指的是，我们现在使用的编码器基本是混合编码器，使用“块”进行运算，带来的问题是，一张图像中块与块之间的“平均值”误差也很明显，所以会使用滤波滤掉这种“块效应”。

后处理，除了前面讲到的视频采样，音频方面的主要问题是数据丢包，为了弥补丢包后的听觉效果，会增加变速不变调的特性，甚至是舒适噪声。

渲染主要是硬件方面，比如显示速度不够，导致解码等都没有问题、最后帧率却不太均匀的情况。

针对以上问题，业内有一些常用的评估指标，以两大类为主：主观指标和客观指标。

（图5 常用评估指标）

主观指标中最具代表性的是 MOS。其优点是以人为本；缺点是成本太高了，并且不能精确复现，评判会随着测试人员的情绪而变化。

所以研发人员希望有一些用机器代替人工的操作，比较典型的就是两类：全参考和无参考。

无参考比如模糊度、块效应等，其优点是只需要接收方一方的数据；缺点是判断力会偏弱，不能够定位到系统内外问题，比如最后结果图效果不好，无法判断是源本身不好，还是在处理过程中引进了问题。

而全参考比如 PSNR、VMAF 等，具有技术上好操作的优点，可以频繁重复，并且能够精准复现，便于快速定位问题；缺点则是需要双方数据，必须严格比对原图和目标图。在这一点上，我们 RTC 模型的好处是，能够容忍网络丢包的问题。

比如发送端发了十张图片，接收端只收到八张，无法满足全参考的一一对应，也不知道丢的是哪两张，如何解决？

（图6 视频对齐方案）

如图 6，我们参考英特尔的方案，在拿到一张原始图时，会在图片左上角加一个视频编号，将这个编号处理完的图作为原始图传至 RTC，接收端经过解码，通过深度学习的文字识别，将编号提取出来，这样两边就能对应起来。

以上是视频的对齐方式，音频又是如何？音频对齐主要是利用一个“物理现象”：人类在语音聊天时主要集中在 4K 频率以下，于是可以以 4K 作为标准线。

（图7 音频对齐方案）

如图 7 为我们的音频对齐方案：拿到音频信号以后，先经过时域转频域，进行频域的低通，只保留 4K 以下的人声，4K 以上的则作为打入特征码，把原始信息留存，以备后续与目标对比。编完码以后再转成时域给 RTC ，RTC 进行时域转频域，进而经过提取就能取得音频编号，最后通过低通滤波，再转成原始的声音。

除了视频及音频对齐方案，另外一个比较重要的方案是时钟对齐。

1V1 通话中，500 毫秒延时就会影响交互体验。我们在使用实时通信产品时都遇到过这样的情况：一个人想在对方两句话之间的气口接话，结果因为延迟过大（超过 500毫秒），对方并没有接收到信号，因而没有停下来，最终两个人就会互相进退推让，造成整个交互过程的零乱。这也是我们需要测量延迟性能的主要原因。

另外，在进行自动化验证时，往往使用多端设备，不同设备的时钟之间其实差异较大，多达几秒之高，这与我们所希望的毫秒误差有很大差距，所以必须先将多端同步，把误差控制在 100 毫秒之内。实际上，我们的实验室环境误差甚至能控制在几十毫秒。

（图8 时钟对齐方案）

如图 8 为时钟对齐方案。每个客户端在进行测试之前，都需要先将自己的时间戳发到统一的时间服务器，由时间服务器把客户端 A 的时间戳带上服务器的时间戳返回来，客户端收到返回包时会取到一个自己的时间戳 B。

修正时间=服务器时间戳+ (客户端时间戳 B - 客户端时间戳 A)/2。也就是说，我们所有的客户端都和时间服务器对齐，即便时间服务器有误差也没关系。

综上我们拿到了视频、音频、时钟三方面的对齐，尔后便可以完成全参考模型的对比工作。

（图9 分析方式）

如图 9 左侧为发送端，需要记录帧号、时间戳、图像二进制信息。接收端也类似。这里我们模拟一个丢包情况（3、4 号丢包），有了这两张表以后通过质量分析，就能够发现丢帧、帧率&流畅度变化、全参考图像质量、延迟、抖动等各种异常情况。

对前面讲的全参考模型做一个总结。

（图 10 音视频端侧特征处理）

如图 10，虚线上下方分别是视频和音频处理过程。在送入 WebRTC 之前，要进行原始视频和时间戳日志的记录，接收端编码识别之后，也需要将目标视频和时间戳日志记录下来。音频也类似。另外，还会记录 WebRTC 本身的一些状态，便于比对最终结果进行快速定位，初步判断问题所在。

如图 11 是我们自动化测试的总框架。

（图11 自动化总框架）

最左侧为验证管理服务器作为“总控”，拿到一个测试时，先是模拟网络环境，自动化配置弱网仪、服务器和端，然后进行真正的实测，产生我们前面提到的所有文件，最后完成汇总分析，进入数据库。

如图 12，自动化验证的流程为：研发人员更改编码、网络等特性后进行新版本提交，先是在验证环境中部署版本，获取用例信息、配置弱网仪、执行测试过程、分析结果。如果发现其他用例，会不断循环执行，最后生成报告。

（图12 自动化验证流程）

从触发条件来说，无论是优化弱网算法、音视频算法，还是流程优化和 OS 特性跟进，不管修改了什么，原则上都要进行所有东西的验证，包括网络环境、向后兼容性、特殊机型覆盖、历史覆盖、精准测量等。

四、 SDN 大网的组建与质量跟踪

SDN 大网建设的主要目标有两个：

一个是实时组建，从功能拆分来主要就是节点状态的收集、路径规划和线路优化，具体指标有：节点间多线路 QoS、节点度数 & 介数、节点负载压力、可达路径数等。

另一个是快速自愈。网络建立起来后，在日常运营中可能会出现节点损坏、专线临时跑不通等情况，需要进行容灾处理。容灾处理首先要有错误收集反馈机制，以及路径的重规划、关键线路的均衡，有问题还需要不断优化。

节点间主要链接方式有公网、云内专线、专线、SD-WAN 四种。

（图13 节点间链接方式与质量特点）

公网成本低，但是稳定性比较差；云内专线成本比其他专线低一些，部署非常方便，但是无法在云服务商中打通，跟 SD-WAN 比起来修复时间会长一些；专线就比如上海到新加坡之间跨国链路质量不好，直接拉一条专线，缺点是有些点运营商覆盖不到；SD-WAN 也就是软件定义的网络，链接能力强，成本稍贵，可以自动修复。

在实际应用中，几种链接方式会同时使用。一旦有某条路径出现问题，就能做到及时切换。

在级联链路选取上，我们主要平衡三个因素：质量+场景+成本。比如 1v1 通话要求延时低一些，而直播对延迟放宽、但对带宽的总量要求更高，最后会结合成本综合考虑。

（图14 实时质量信息收集）

如图 14，在对节点进行实时质量信息收集时，我们会把一个节点里所有服务数据汇总到节点的一个 Agent，进行初步分析后再到实时状态管理服务器，由它进行多节点之间的同步。这样，全球网络所有节点的负载情况、当前带宽质量等情况都可以知道。

五、 链路问题的跟踪与查询

针对布局全球的链路，融云自建了一套监控系统。通过这个平台，我们可以查询用户接入点、接入设备以及使用的融云 SDK 版本号等信息，也可以得到用户在业务过程中订阅流的相关信息，以及通过各种监测点，来对整体音视频服务状态进行监控。

（图15 全球链路监控看板，详细信息在【融云全球互联网通信云】公众号）

这样，我们可以对服务质量和性能进行实时监控，分析影响客户使用体验的原因，为开发者提供更加详细的位置信息、准确的参数信息、实际的场景情况等，最终方便研发人员快速定位根本问题、准确制定优化方案。