共计 2438 个字符，预计需要花费 7 分钟才能阅读完成。
近年来因为全球性的新冠疫情，世界各地对实时音视频的需要猛增。不同国家和地区因为经济倒退、国家政策等起因，网络环境有很大不同，如果要做好音视频体验，就须要分地区进行音视频指标测试。然而不论是外包，还是云测，都无奈满足咱们对品质的要求。
本文将介绍在以后新冠疫情下，声网是如何对海内不同地区进行音视频自动化测试，并取得牢靠的指标后果。
本文为「Dev for Dev 专栏」系列内容，作者为声网音视频实验室 Android 开发工程师 胡大化。
01 传统音视频测试方法已不实用
以测视频延时为例，以前咱们通常的做法是：首先找一个网络时钟，而后让发送端、接收端两台手机进行视频通话，并且用发送端手机拍摄这个时钟，而后接收端就看到网络时钟的画面。咱们将网络时钟的工夫，减去接收端手机显示的时钟工夫，就是这一帧视频的延时。如图 1.1 所示：
■图 1.1 以后帧延时为 315ms
这种测试方法须要测试人员到现场去安排测试设施。然而在以后疫情环境下，很难派员工去海内出差进行实地场测。
02 为何不外包给海内测试团队？
你可能会想到既然不能派员工去海内出差，可不可找当地人帮忙，或者外包给当地业余的测试团队？
这种策略咱们也思考过。但音视频测试不同于个别的软件黑盒测试，在测试过程中实测用例很多，每个用例都要调不同的参数，内部测试团队很难达到咱们平时测试时关注细节的水平，另外他们也不具备测试音视频所须要的专业知识。无奈保障测试后果精确牢靠。再者不同国家和地区因为语言时区等起因，协调的老本极高。
03 借助云测进行自动化测试
咱们尝试应用云测供应商在海内不同地区部署的手机做测试，在这些手机装置测试程序，在国内通过远程桌面或自动化脚本管制手机进行音视频通话。
大的云测厂商如 Headspin 在国外几十个国家地区都有部署云测手机，但云测手机与真机不同，有很多限度：比方摄像头被遮住，就无奈应用那些通过摄像头采集进行视频传输的测试用例了。因而咱们须要设计一套不应用摄像头测音视频指标的计划。咱们想到了通过自采集 YUV 视频的形式测试视频指标。
采纳自采集 YUV 的形式，实现了两个云测手机之间视频传输，那怎么能力失去视频传输的性能指标呢？如延时、卡顿、码率、帧率等。应用 YUV 自采集的形式，没有独立的时钟源能够参考，测延时必须要解决两个手机对时问题。咱们尝试通过 NTP 服务器或局域网对时两种计划。如果两个手机都在一个局域网下，通过局域网对时会十分精准，咱们在本地实测两个手机之间替换数据包往返延时 rtt<10ms，而且在同一个局域网内上行和上行链路速度一样，那么理论对时偏差应该 <2ms。这合乎咱们对精度的要求。
然而有的云测供应商两个手机之间无奈通过局域网通信，比方 Headspin 就不能够。这时咱们思考用 NTP 形式对时。NTP 对时误差在几十毫秒，相比局域网大很多，如果超过 50ms，就会对咱们测延时影响很大，咱们心愿对时偏差 <50ms。如何做到这一点？通过查阅 NTP 官网文档得悉，只有对时时 rtt 足够小，就能够实现。rtt 与对时偏差的关系如下图 1.2 所示（来源于 NTP 官网）:
■图 1.2 NTP 对时中 rtt 与对时偏差的关系
从下面能够看出，只有往返延时 rtt 管制 100ms 以内，对时偏差 -10ms<offset<10ms，这样两个手机的对时偏差不会超过 20ms，合乎咱们的要求。理论环境下是否做到 rtt<100ms 呢？通过实测咱们发现齐全能够做到。在上海通过阿里云的 NT P 服务器（ntp.aliyun.com）对时，rtt 在 30ms 左右，很少超过 60ms。
在海内，以印度新德里为例，应用当地的 NTP 服务器（time.nplindia.org）rtt 也容易在 30ms 以下。因而咱们只有应用当地或间隔比拟近的 NTP 服务器对时，精度都能够满足要求。在程序实现时咱们能够屡次对时，取 rtt<100ms 时的最小值。
解决了对时问题后，须要晓得视频帧的发送工夫和接管到的工夫。咱们能够在发送端把发送工夫画在视频帧上，接收端把以后工夫以浮窗模式盖在接管到的视频帧上，对接收端录屏，录像后的每一帧都有发送工夫和接管工夫，通过 AI 辨认进去后，就能够计算出这一帧的延时。如图 1.3 所示：
■图 1.3 打上工夫戳的视频传输
除了延时外，接下来要计算帧率、码率和卡顿率。
帧率的计算比较简单，对接收端录屏后的视频取每一帧，如果这一帧上的数字相比上一帧有变动，咱们就认为是不同帧，计算出帧数除以工夫就是帧率, 码率的计算咱们能够通过抓包应用 Wireshark 剖析，在音视频通话中视频数据都是以 UDP 协定传输，通过 Wireshark 能够很显著的辨别进去。
卡顿率与工夫相干, 通常咱们计算 200ms、300ms、600ms 这几种状况下的卡顿率，计算也比较简单，以 200ms 为例，只有前后不同帧的距离超过了 200ms，就认为是卡顿，卡顿数除以总帧数就是卡顿率。
04 其余测试方法
相比云测，是否有更简略的测试计划呢? 咱们想到了想到借助 SDK 本身的统计信息，RTC 计划提供商都会在给内部应用的 SDK 中集成具体且全面的统计信息，咱们能够通过回调模式拿到。例如，通过声网的 onRtcStats(IRtcEngineEventHandler.RtcStats stats) 回调能够实现获取以后通话的音视频指标信息，更详细信息，可拜访声网文档核心 (docs.agora.io/cn）搜寻理解。当然这种形式在别的计划不可用时不失为一种参考。
以上仅是一家之言，音视频测试有很多种计划，说不定你已有更加精确高效的办法。欢送在声网开发者社区 rtcdeveloper.agora.io 分享进去，咱们一起交换，共同进步！
对于 Dev for Dev
Dev for Dev 专栏全称为 Developer for Developer，该专栏是声网与 RTC 开发者社区独特发动的开发者互动翻新实际流动。
透过工程师视角的技术分享、交换碰撞、我的项目共建等多种形式，汇聚开发者的力量，开掘和传递最具价值的技术内容和我的项目，全面开释技术的创造力。
