站长之家- 传媒 2021-10-27T14:47:40 +08:00

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

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

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

(图1 从左至右依次为:黄震坤、杨攀、李淼、许杰)

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

(图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 全球链路监控看板)

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

推荐关键词

24小时热搜

查看更多内容

大家正在看