共计 4761 个字符，预计需要花费 12 分钟才能阅读完成。
（图 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 寰球链路监控看板）
这样，咱们能够对服务质量和性能进行实时监控，剖析影响客户应用体验的起因，为开发者提供更加具体的地位信息、精确的参数信息、理论的场景状况等，最终不便研发人员疾速定位基本问题、精确制订优化计划。
