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 全球链路监控看板，详细信息在【融云全球互联网通信云】公众号)
这样，我们可以对服务质量和性能进行实时监控，分析影响客户使用体验的原因，为开发者提供更加详细的位置信息、准确的参数信息、实际的场景情况等，最终方便研发人员快速定位根本问题、准确制定优化方案。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
