从四个方面分析云游戏自动音视频测试

在日益临近的5G时代下，5G网络和新的流视频游戏服务将在未来几年内让云游戏的增长一触即发，云游戏已渐成行业热点。英特尔基于OWT（Open WebRTC Toolkit）也对云游戏使用场景所需要的高分辨率，高比特率和高帧率的视频超低延时的实时传输做了深入研究和广泛优化。云游戏中音视频延时，音画同步尤为重要。游戏中最为关注的音视频检测是怎么实现的？音视频同步检测是通过什么方式自动化实现的呢？本次讲座将围绕上述几个问题从痛点，难点和解决方案一一展开。

1. 项目背景介绍  

  大家看到这些图会想到什么？会不会想到我们最近疫情在家工作的场景。随着流量包的提升和带宽计费的下降，长短视频最近非常火爆，疫情期间，在家上班、小朋友在家学习、在家会议已经成为了一种生活的常态，它们从生活的可选项瞬间变成了生活的必需品。上图左边的云游戏作为一种新的游戏视频服务方式，在未来几年云游戏的增长一定会因为各种原因一触即发。云游戏已然成为了业界追踪的热点，我们英特尔基于OWT对于云游戏使用场景所需要的高分辨率、高帧率的视频，同时又需要满足低延时的实时传输，在这方面我们做了深入的研究和广泛的优化。其实无论是音视频会议系统还是云游戏场景中，音视频的质量，用户的体验比如说音视频的延时、音视频的卡顿、音画是否同步都极为重要。那么最为关注的音视频的检测是怎么实现的呢，比如说音画同步怎么做？音视频的检测方法和算法有哪些呢？怎么融入到我们检测体系中呢？这就是我将一一展开和大家讲解的内容。

2. 音视频传播流程分析    2.1 传统音视频传输流程和问题分析 

传输流程

上图是一个传统的音视频传输的流程，左边是发送方，我们可以想像成一个一对一的会议模式，右边是接收方。发送方首先要进行视频的采集，不管是用什么设备，用浏览器、用中间设备、用虚拟摄像头、用真正的文件传输或是用真正的Camera传输或者视频，首先都得进行采集。采集之后进行前处理降噪，加水印或美颜的功能，再进行编码，通过网络的传输，编码后的视频传输到中间服务器，服务器会进行视频的中转、处理，比如说会议模式会将多路收集到的视频进行合并、压缩、转码等等。在服务器会进行解码压缩再编码，随后视频通过网络传输送到接收方，接收方拿到这个视频后会进行后处理和渲染。  

问题分析

在整个流程中哪些地方会对音视频的质量或者说发送给接收方的音视频造成偏差呢？首先是发送方的采集，采集会有有损的损耗；其次是前处理；再然后是编码，最后是发送方到接收方网络因素的干扰，可能是网络带宽，网络丢包等等影响。服务端这边如果进行一个转码，解码，再编码，或者进行编码的转变，或者进行一个压缩都是有损的。接收方这边处理渲染也会带来一部分的损耗，可以看到视频从发送方到接受方的过程会经过各种各样的曲折。  2.2 云游戏音视频传送流程分析 

  其实云游戏和上述传统音视频传输流程很类似，它们不同的点在于在云游戏的云端会有个终端游戏服务器，终端游戏服务器会进行游戏音视频的捕捉，在捕捉之后将游戏音视频进行一个编码，编码之后传输到客户端，客户端可能是浏览器，也有可能是终端设备，再解码、后处理、渲染播放。那么整个流程中哪些会对音视频有影响呢？一是服务端音视频的捕捉和编码；二是网络传输；三是终端的解码，后处理，渲染播放等等。

3. 音视频评估标准和方法  

  在了解到了传统的音视频传输流程中一些步骤会导致音视频偏差，我们需要思考如何做音视频的评估，评估时的方法和标准及其使用。我将音视频评估标准和方法分为了以下几个部分：视频质量评估、音频质量评估、音画同步、音视频延时。  3.1 视频质量评估  视频的质量评估分为两种：主观评估和客观评估。  

  主观评估顾名思义就是用人工评估，那么人工评估并不是我们听一听就好了这么简单。人工评估目前来说在各种协会比如说IEC、EBU、ITU等等国际电信联盟都有相应的标准，以上的图是我截取它们标准文档的形式，首先是左上角的一个音频设备，如果要搭建一个音视频的实验室，需要注意广播设备的设置位置、广播设备的距离、分贝的大小。那我们对视频评估要注意音视频实验室观看距离的设定、观看视频序列的设定、对观测人员人数的限定（男女比例，老少比例，国籍比例等）。   由此可以看出搭建一个主观评估的音视频实验室所需要耗费的时间、财力、人力成本是比较高的。评估之后会得出什么样的结论呢？通常是一个1分到6分的结果：一分表示非常差、3分表示还可以接受，5分之后是非常好了。除了人力财力消耗比较高以外，主观评估问题还有：我们要对非专业人员以专业标准进行培训；随机选取的人员也会导致主观的差异、重复性低、数据无法量化，缺乏参考性、受到测试客观环境的影响，比如如果视频观看远近的切换，顺序的切换有可能会影响最终的结果。当然它也有优点，这样的结果始终是人的感官，而评估的目标就是为了知道这个音视频给人感官的最后结果。  

  视频客观评估，通常称为VQA（Video Quality Assessment），而Video通常是用一帧一帧的视频帧数来组成的，每个视频帧其实就是一张张图片，我们会将VQA转成IQA（Image Quality Assessment）。IQA的研究算法其实有很多，目前有很多学者会将IQA加入时域的特性，再转成VQA的结果，进行客观评估。客观评估分为两类：有参考评估和无参考评估。  

客观评估-有参考评估

  有参考评估是什么？从字面上非常好理解，就是将参考视频和待评估视频一一对标之后输入到评估算法和评估体系，最后得到分数。  

  面对五花八门的各种算法，什么叫做好的算法呢？在业界上有很多开源的数据库。各种学者和研究人员将他们的算法进行研究。上图左边TID 2008是大家都知道的图像的数据库，其实更新的是TID 2013。根据TID 2008的文档描述，它是由一些正常的图片和一些扭曲之后的图片组成的。比如说正常图像占一部分，接下来会增加一些高斯噪声的图片，或者是一些有选编码之后的图片，这些都有详细的描述。   右图是我们从公开的算法数据库中获取的，判断算法的好坏通常是选几个database，在database上进行评测，评测算法和数据库中评估出来的评分，数据库除了之前所说的图像，还有一些扭曲视频，另外一个很重要的因素是它会对提供的每张图片做一个主观打分的数值。算法和这个数值的相关性可以从PLCC、SROCC计算。相关关系函数的结果表示的是算法和真实的MSE值的偏差。通常绝对值越高，表示算法的性能越好。在拿到一些精简的算法后会在各个数据库中进行对比，比如PSNR、SSIM、VMAF等等。在每一个database里，这些相关关系函数得出的结果都比已有的算法好，那么就是一个很好的新算法。  

  那么在我们的体系中，我选了三个比较经典的算法PSNR、SSIM、VMAF作为有参考的评测标准。我们有了这些有参考的评算标准是否就足够了呢？我们怎么将这些评估算法加入现有的体系中呢？  

  首先我们要解决的最核心的问题是测试结果和流程的可重复性，这是客观评估和主观评估非常大的差别。因为有了重复，所以可以重复地看问题出在哪儿，重现问题所在点。通常的做法是将随机视频输入流，转成固定视频输入流。光是转成固定输入流还不够，将随机视频输入流转成固定视频输入流是恒定长度帧数的视频流，比如说一千帧这样一个视频，那么我们在播放的时候就是一千帧重复播放，接收到的也是一千帧循环播放的视频，我们需要知道我们接收到的视频是对应的发生到的哪一帧，就要帧与帧之间对标之后才能算出有参考的算法，因为那些算法都是帧与帧之间对比出来的。   我们做了视频帧的定位，在发送的时候就在视频帧的左上角进行一个视频帧的标记，标记的是发送了多少帧，第几帧。那么在接收的时候，这个帧就会原生地传输过来，然后我们在后台进行左上角帧字符的重识别。识别之后我们就知道是第几帧，他在发送的时候我们进行一个循环标记符，通过循环标记符和左上角视频帧的定位到第几轮的第几帧；通过接收到的视频帧序列，我们就可以反过来将发送的视频序列进行挑选。需要进行挑选的原因是在接收到的视频里面，通过网络之后会有一些帧的流失，比如发送的是100帧收到的只有50帧，那么根据接收到的50帧我们就找到发送对应的50帧进行一一对标的发送序列。发送序列和接收序列之间进行对比，输入到有参考的算法，最后就可以得到相应的评估算法的结果。  

客观评估-无参考评估

  在现实生活中，我们看到了有参考的评估，在评估一个编码的算法时用得很多。但真实在直播环境下，有参考是非常难做的，因为他需要摆脱干扰。那么这就涉及到了另一种客观评估方法无参考评估，无参考评估也很好理解，我只有待测视频，直接将待测视频输入到评估算法模型中，我就可以得到这样的一个结果。  

  无参考评估分为两大类：打分类和全帧扫描。   打分类就是和有参考一样，将待测视频输入到无参考的算法中就可以的得到一个分数。   打分类通常有两类。第一种是通过将VQA转成IQA的无参考算法，这些算法都比较成熟了，我们可以看到有一些图像熵评估算法（GRNN)，空域特性评估算法（BRISQUE)，除此之外很多学者都在研究DL算法，大家知道之前LiveVideoStackCon上有演讲就是基于Camera的视频的DL评估算法。整体来说，无参考的打分目前来看它的准确度与数据库中MSE的偏差还是比较大的，它是没有办法和有参考评估并列的，准确度还是比较低的。  

  全帧扫描的意思是对收到的每一帧的数据都进行扫描和判断。   全帧扫描又可以分为两大类。第一个是图片像素检测，把视频帧作为一张图片，通过图片的像素层进行模糊度检测，来判断这个视频是不是带有模糊，通过像素块内和像素块外的相关项来检测是否有马赛克的块效应，同时也可以检测是否有噪声，快衰弱的评判算法，这些技术都已经比较成熟了。可我们后来又发现我们虽然有很多算法，但是我们不能覆盖现实中的马赛克。以现实中的马赛克检测来说，很多马赛克并没有被检测出来，它可能和我们期望的像素成块的有差距，说明它的算法不够通用。目前很多公司包括我们自己也还在研究DL这一块，我们可以根据不同产品来定制，比如说我们就想检测出来，正常视频帧有多少，我的异常视频帧有多少，可以做分类的算法，如果有足够多的视频，可以进行标注正常和非正常。还可以通过的DL聚类检测，大部分时候，我们的标注图像信息不够，我们可以通过一些聚类的检测，做一些无参考的聚类、全帧扫描，所以可以根据自己的产品做一些相关的定制。  

  除了上文我们一直在讲的视频帧质量，实际上大部分产品，比如说在打游戏时候，你的视频画面是清晰的，但视频过于卡顿就会十分影响用户体验。那么在有的情况下，比如说在开会的时候，并不要求视频帧的质量很清晰，可能更加关注流畅度；看电影的时候，每个人的感官是不一样的，我可能会希望视频更清晰，流畅度稍微差一点也没有关系。那我们有没有这样一些相关的指标可以体现出用户的QoE体验呢？  

  首先介绍一下我们的卡顿时长算法，将视频按70000 fp值录下来，每一帧通过滤波器，将每一帧分为8*8的像素块，并为每一个像素块的上一帧和下一帧计算绝对差值之和（SAD)，我们就可以定义一个准则，设一个阈值，最高和最低差值，如果两个视频帧之间有足够多的8*8之间的SAD大小都低于最低值，或者说我没有一块SAD大于最大值，在这种情况下就认为这两张图片是一样的，以此认为它出现了卡顿，卡顿了多久就是卡顿的时长，卡顿了多少次就是卡顿的频率，通常来说一秒左右的卡顿是人的肉眼可以感知的。但是我们又发现，如果卡顿频率过快也会觉得画面很卡。除了卡顿时长和卡顿频率之外，还可以计算首帧时间，首帧时间就是当画面在特定的情况下首帧出现的时候，画面从不变到画面突变的情况，这种情况下我们可以按照上面的算法算出首帧出现的时间。  3.2 音频质量评估

客观评估-有参考评估

  从客观评估来讲，它的方法主要分两种，有参考评估和无参考评估。有参考评估就是参考视频和待测音频，将两个音频进行对标，传输到评估算法模型里，得到相应的分数。打分的结果也和视频一样，上图的分数是举出例子可以看出哪些是满意的哪些是不满意的。  

  在这主要介绍客观评估的算法PESQ，这是大家经常通用的算法。我们来看一下这套算法的主要流程。第一步是信号处理，我们将发送的音频和待测的音频进行信号处理，将两个音频进行一一对标，将时间对齐等等。第二步是建模，第一个模型是感知模型，这步中还包括频率的映射以及带宽信号的过密；第二个模型是认知建模，包括一些叫声相关的信息组合进来，最后将它组合到MSE计算值的统计中，计算参考信号和失帧待评估信号之间的差，正值代表有噪声，负值代表无噪声或有较小的噪声。这个模型的优点是它允许发现发送信号和接收信号有延时导致的偏差，它会将这些延时干扰去除，真正的评价参考信号和失帧待评估信号之间的偏差。但也有专家认为这样是不合理的，因为中间有延时也会影响音频感官的结果。  

  上图是从polqa网页上获取的几大有参考音频评估算法的对比，图下有网页地址，它认为宽带的算法可以作为PESQA后一代的音频算法，目前更为大众所用，但是这个算法需要购买LICENSE，所以大家用PESQ也是可以的。  

客观评估 无参考评估

  无参考评估分为两大类：专项检测和通用检测。有些时候我们想进行特征音的查找，比如说人声、噪音、歌声的检测。我们通过声音指纹，相关度来进行特征音的检测。除了这些专项检测之外，也有些通用的检测。我们可以将音频型号输入到DL序列号的模型进行打分评估，去年LiveVideoStackCon上也有介绍这样的通用检测方法，目前来说这种无参考检测，它的准确度与有参考检测的准确度对比还是相差很多。  3.3 音画同步 

  单独讲音画同步的原因是音画同步是视频和音频评估的另外一部分。是不是音频和视频发送和接收做到分秒不差才能叫做音画同步呢？那么多差才叫差也是有一定标准的。上图所列的几个组织，比如说国际电信联盟、美国数字电视国家标准ATSC、欧洲广播联盟标准EBU等等都有相应标准。目前还是以ITU的标准作为主导方向。  

主观评估

  上图是ITU标准的定义。这是一个场景定义，现在是棒球的直播现场，棒球运动员正在打球，下面有一个实时的播音员，通过两个采集设备进行采集之后，经过中间中转，包括信息塔的传输或网络的传输等等（它定义的比较早，所以是电视信号），最后终端用户接收。   那音画之间的差别多少是差呢？多少差别是可以接受的程度呢？最后他们总结了一个标准，负表示画前音后，正表示音前画后。他们认为画前音后100ms到音前画后25ms是无法感知的，所以认为这个时候视频是音画同步的。画前音后125ms到音前画后45ms是可以感知的，<-185ms到>90ms是不可以接受的。这是他们定义出来的标准。对于这个标准，我们有什么办法对他做自动化的评估呢？  

客观评估

  上图就是我们经常做的工作。大概说一下整个流程供大家参考。我们在音频和视频中分别插入一系列的特征音和特征视频帧，在插入的同时，我们在发送时对每个特征音和特征视频帧记了时间错信息，比如它标记成第一个特征视频帧和第一个特征音频帧的时间偏差，把它记录下来。那么在接收方这边，我们同样的将音频和视频每一个都做后处理，先录制存储下来，然后在视频中查找第一个特征视频帧，计算它的时间偏差，同时查找第一个它对应的特征音频帧，记录它的时间信息，两个相减，接收到的偏差和发送的偏差进行对标就可以算出音画同步的偏差数值。  3.4 音视频延迟

音视频延时测试

  在前文也有介绍过怎么处理音视频的延时，在做白盒干扰的时候，我们在每一个视频帧的左上角进行视频帧的标注信息，可以知道这是第几帧，在发送的同时会记一个时间戳给这一帧，接收到这样的视频序列之后，我们对接收到的每一个视频帧标记时间信息，通过视频帧的数据可以反推这是第几帧。如果找到对标的两个帧的时间信息，直接相减就可以得到端对端的延时，这里我还加一个bias是因为我们发送和接收要做到时间同步，发送和接收时间是两台不同的机器，有时间的偏差，只有考虑到这一点才能算出真正的端对端的延时。   音频延时我们借助于音画同步的偏差来计算，在接收到的序列中，通过特征音的查找找到对应视频的时间戳，他们的偏差就是音画同步的偏差，音画同步的偏差结合视频的偏差就能算出音频的偏差。  

鼠标点击延时测试

  除了端对端的延时，在游戏中就是鼠标响应的时长。特别是在云游戏中，在客户端开一枪，这一枪传到服务器端最终相应到客户端的时间长度就是鼠标的相应时长。通常我们会在点击鼠标时刻记一个时间，然后将事件网络传输到服务端，服务端在进行回传的时候，真正相应到客户端中计算记录时间（time2），time2减去之前鼠标点击的时间（time1）就是鼠标来回的时间。在后续，要根据不同的终端来做不同的处理，比如说浏览器可以借助Video Tag的event来做，其他终端可能要借助于视频帧的检测。

4. 系统性能评估辅助方法    

  在音视频评估体系中，考虑到音视频的质量、音视频的延时、音画同步参数之外，我们还会对系统的性能进行评估。我们整个通用中用了WebRTC，WebRTC stats其实提供了很多indicator，比如说fps、Bandwidth、帧率、帧大小、Nack cout、PacketLost等等因素。它其实也可以反馈给用户系统的实时性能评估，我们为了修整这些信号利用OpenCensus，它提供了不管是服务端C++还是用客户端js来做，用Node js的后端，最后将所有的数据不管是WebRTC stats的或是音画同步的信息还是音视频质量的时间信息统一传输到后端，通过Prometheus终端显示，这样很多数据就可以做实时监测的终端显示,优点就是不管你在哪里，通过一台浏览器就可以监控到目前的状态。