文 / 张武峰

整理 / LiveVideoStack

大家好我是来自VIPKID的张武峰，今天我与大家分享的是在线教育音视频质量评价与感知系统。

我有二十余年的音视频开发经验，最早从事传统视频会议方向的探索，后来转向至3G、4G网络下的视频电话。 传统视频会议多由专网传输，目标是如何尽可能地实现出色的音画质量； 而消费级互联网基于公共网络的环境与专网有很大的不同，遇到的挑战相对于专网来说完全不一样，这就使得我在进入消费级互联网行业时发现，自己之前在开发基于专网的商业级音视频业务当中积累的知识与经验无法有效应对新的业务场景和开发痛点，知识体系的更新重组对我而言是非常有必要的。

 

2017年我加入了VIPKID，带领音视频团队探索如何更好地将实时RTC技术用于在线教育领域。 我之前一直从事技术方面的优化与创新，而这次选题我特意选取了QoE方向，就是因为探索了这么多年的技术，我发现技术最重要的是为实际应用场景带来具有建设性的优化改进，而质量评价与感知系统是其中最为关键的一环。 我们希望完整构建一套严谨专业客观的音视频质量评价与感知系统，从而为用户体验的优化与提升解决方案提供强有力的数据支撑。

 

我将基于以下四个方面开展本次分享

1. 用户痛点

管理大师德鲁克曾说： 没有度量就没有优化，这句话用于音视频开发也非常恰当。 我们在之前的开发过程中就积累了许多教训，如在优化系统时我们就曾遇见这样的问题： 设计一项优化算法，设计初期我们预期该算法能将用户体验提升至新的高度，且我们也通过多种自证方式验证了其逻辑自洽，于是我们在预期成立的前提下为该算法投入资源进行开发，但在算法上线之后我们却发现其实际效果和预期存在很大的差异，该算法对于用户的主观体验没有带来改观甚至造成负面影响。 这一经验令我们思考： 音视频系统究竟需要一套怎样的标准才能准确客观评价算法的优劣？ 在设计任何音视频系统或者针对系统当中某一点进行优化时，开发者一定需要先仔细思考如何借助数据准确合理度量正在开发的算法，不仅是从实验室角度度量更应当从用户角度度量。 这样无论是灰度测试还是频繁地版本迭代，甚至多个团队基于同一方向进行的优化竞争，确立好的度量标准就如一把尺子，可以准确客观衡量出算法可为用户体验带来多少提升与优化。

上图右侧饼状图展示了VIPKID用户所反映的针对产品所提出的五大关键问题（占比从高到低依次为： 网络问题、设备问题、行为问题、软件问题与课件问题）对于所有RTC开发者来说，网络问题永远是一项最艰巨的挑战； 而当用户数量达到一定规模时，不同软硬件平台设备、不同版本的软件适配问题也将成为一项亟待解决的重要命题。

 

而上图左侧展示了如果用户为我们的一项服务给出差评，其给出差评所选出的主要理由： （画面/声音卡顿、声音延时/画面不同步、声音不清晰与回声严重）。 需要注意的是由于用户并非专业的开发者，这里没有一个统一的标准去衡量这些问题。 例如什么是“画面卡顿”，有些用户可能会将摄像头故障等其他问题归类为”画面卡顿“，这就需要我们基于大量的用户数据进行筛选清洗与分析从而尽可能找出用户最关注的几项痛点。 在线教育属于一个重度依赖音视频技术的应用场景，故其暴露出来的音视频技术问题也会很多。

 

2. 评价体系

 

既然存在如此多而复杂的用户痛点，那么确立一套专业客观精准高效的音视频用户体验评价体系就变得尤为重要。

上图表格展示了音视频评价的多个维度，用以评价一节完整在线教育课程的用户体验优劣。 首先在视频方面，用户对卡顿的感知最为敏感，而其统计方法主要是将帧与帧之间超过200ms的间隔视为一次卡顿，（卡顿时间/上课市场）=卡顿率，我们将5%作为引起用户卡顿感的阈值，数据主要来自客户端采集。

 

视频画面的清晰度则主要使用MOS分作为评价标准，也就是从原始录像中按照每分钟1帧的方式抽取I帧图像并为其清晰度赋予MOS分值，所得到的系统分值再与用户的主观感知评价进行匹配，最终得到的分值如果低于3分那么我们就视该视频画面清晰度不佳。 需要注意的是，这里的MOS分并非单纯基于肉眼感知的画面质量，而是基于综合视频编码与网络传输的参数，通过AI训练而成的一套算法为其赋分，数据主要通过录制上课视频得到。

 

音频方面，除了“清晰度”这样一项常见的指标之外，“声音大小”是我们根据用户反馈评价新增加的一项评价维度，这主要是因为许多用户反馈上课时感觉声音过大或者过小以至于听不清楚，发生这种情况多由于老师直播或录制课程时离话筒距离不当或录制设备不佳，也有可能是用户端的设置出现失误。 我们选取老师讲话的部分并计算其音量是否合适，低于30分我们就认为该片段声音大小不符合用户体验要求； 而“清晰度”则依旧使用常见的MOS赋分的形式，利用程序给目标录像片段的音频打分，低于3分我们认为该片段的音频清晰度不佳。 以上是我们确立的针对在线教育所设计的一套完整评价维度，作为技术团队的KPI来使用。 针对每一项，我们会有专门的团队负责优化与改进目标维度对应的算法与技术指标，以实现最优效果。

 

2.1. 视频卡顿率：

 

卡顿率的定义如下： 如果是1对1的视频应用场景，那么用户卡顿率为用户观看时间内帧与帧之间超过200ms的总时长除以用户观看总时长（课中用户在线时长）； 而对于一对多的视频场景，我们会统计卡顿用户数占比也就是统计卡顿率大于等于5%的用户数并将该数字除以总上课人数（也就是进过教室10s以上的用户数）。 这里的200ms阈值其实算是一个比较严苛的标准，有一些互联网公司会将该数值确定在600ms左右，我们这样做是为了统计更多的卡顿案例并获得更多的数据以便于我们进行卡顿分析与研究，促使技术团队更出色地优化卡顿。 每一项指标在确立的时候都与应用场景强相关，这些指标虽然都与技术相关但其和用户主观感知一一对应。

 

我们为统计到的卡顿情况作出了如下级别细分，其中遇到1、2级别卡顿情况的用户占比约为5%，遇到3、4、5级别卡顿的用户平均占比约为18%。 这一数字在业内属于比较好的情况。

2.2. 视频打分算法流程

 

我们大概花费了两到三个月探索视频打分算法，在初期我们阅读了许多论文著作，发现业界还没有很出色的无参考视频打分算法。 当时也试验过其他厂商的比较成熟的算法也没有达到理想的效果，直接用一张图片训练无法实现收敛。 于是我们尝试换了一个方向，也就是从视频编码数据流当中抽取一些参数例如GOP帧宏块的大小，宏块的个数、丢包个数等以形成训练数据集，随后再使用该数据集训练打分算法模型。 我们将得到的模型与人工标记做对比，最终的效果符合我们的需求，和用户主观感知结果的匹配度大概在80%，该算法模型就固定下来并被我们用于后续的关键开发活动当中。

2.3. 特征提取

 

特征提取的第一步是需要对文件进行解析，我们的线上课程视频文件基于不同的系统与格式，如mp4、flv、ts等等。 再将原文件统一成H.264/H.265码流之后，码流解码程序会解析得到解码后的图像序列，该图像序列会被导入场景检测程序以生成特征提取单元； 特征提取单元会在接下来的流程中被筛选，系统判断其是否超过最大序列长度，如果未超过，那么该特征提取单元会被直接输入特征提取程序以提取出有效特征； 如果超过，那么该特征提取单元会被依据最大序列长度做切分以生成符合序列长度要求的多条特征提取单元，这些特征单元会被输入特征提取程序以生成我们想要的特征数据。

2.4. 视频训练的关键参数

 

下图展示了训练该算法模型所需要的几项关键参数，其中包括宏块个数、帧的类型、宏块是否会丢包等。 这一部分训练所消耗的算力资源是比较多的，如果想获得比较出色的训练效果，服务端强大且可靠的硬件支持必不可少。

2.5. 声音质量P.563

从事音频质量评价的朋友应该不会对该声音质量评价模型感到陌生，该算法模型于2004年被提出。 无论是音频还是视频，所有全参考的打分算法在线上系统都是不可用的。 我们无法直接调取发端和收端的数据套用全参考算法，故面对线上音视频场景所使用的打分算法一定是单边的无参考算法。 P.563就是这样一套可靠的单边算法，其不依赖发端数据，仅需收端数据即可直接运算得到评估分数。 大致流程如下图中显示的那样：

首先，提取的原始数据会经由预处理后进行话音参数特征的提取与计算，所得到的参数会被归类为多种失真类型，按照不同的失真类型选取对应的话音质量模型从而得到准确客观的MOS分数。 之前我们提到了评价维度里面有一项是音量大小，而P.563在预处理的过程中就会计算得到Active speech level adjustment这样一个参数，我们将4ms帧长下的Speech Level作为声音大小，取值范围是1～100，连续3帧以上超过阈值为不合格，反之则会被当成背景噪声过滤，从而我们得到了评估声音质量所需的所有关键评分。

 

2.6. 质量分析系统

 

之前我们介绍了如何获取算法，而在获取到准确算法之后，如何部署大批量的质量分析与数据运算便成了接下来的另一项关键命题，为解决该命题我们设计了一套支持全局任务调度的分布式质量分析系统： 接口层的HTTP接口与公司的BI系统对接，BI系统会下发质量分析任务，由HTTP接口传输至任务生成层； 任务生成层会根据上层所下发的任务清单合理进行任务分配，以充分高效利用计算资源； 分配结果传递至Job Server Node，Job Server Node会将任务真正下发至任务消费层CmqaWorker系统，而每个Worker下层的Audio-quality-evaluation或Video-quality-evaluation等会实际执行计算任务。 在-quality-evaluation进行评估计算时，CmqaCollector会收集相关数据并存储到DBI，每一次任务分发时，Cmqa Master会从DBI当中调取数据以获知哪些计算资源是空闲的或者任务负载较低，以合理科学高效分配下发任务。 该任务系统主要会在每天结束所有课程后的夜间22:00～次日08:00运行以避免影响实时上课，当然有些特殊数据需要在白天上课时同步进行，所以整个系统一直处于24小时不间断运行状态。

3. 质量感知

3.1 海豚系统

我们将基于以上评价体系构建的质量感知系统成为“海豚系统”，该系统全天运转，用以感知整个基于在全球四十多个节点部署的超过一千五百多台服务器的上课系统。 通过该系统我们可以及时获知那些节点出现异常，甚至精确到哪个用户出现问题。 像VIPKID多为付费产品，用户对于产品体验的要求很高，我们必须提高所有技术标准并尽可能精确快速处理危机故障。 整个质量感知系统的架构如下： 首先底层的数据来源于SDK上报日志（音视频的SDK，包括音频视频帧率、卡顿率、用户所使用平台版本、摄像头数据等，其贡献数据最多）、客户端打点（用户行为）、服务端日志（自建流媒体加速系统的流媒体服务、信令服务、工作状态等）、BI数据与QOS数据（来自音视频之外的其他数据），数据拉取与采集之后会进行数据清洗，这些清洗好的结构化数据会被赋予一定标签，继而便于接下来的多维分析预处理数据，最后通过统一的数据接口将数据传输至分析与查询服务系统。 该系统由以下三大职责： 标签系统和多维分析： 便于精细化课程分析与快速响应数据分析需求； 实时预警： 可以对动态问题与节点故障进行预警； 问题挖掘： 用于传输算法模型、产出智能覆盖模型，同时挖掘问题设备。

上图展示的就是我们基于该质量感知系统制作的实时监控大盘。

 

3.2 核心指标

 

下图展示的核心指标，用于实时课程质量追踪、问题统计以及客户端发版前后对比。 所有课程的分析结果会产生标签，例如采集卡顿率数据，我们知道卡顿率和帧率是正相关的，正常的帧率为15FPS，但有些用户的帧率为5FPS，这些就属于遭遇卡顿问题的用户。 每一节课都会被打上许多标签，而真正的问题分析是通过分析某些标签突然异常变多或者这一节课出现多个异常标签，我们在定位问题时也是通过标签来确定。

3.3 实时指标趋势跟踪

 

下图展示了实时指标趋势跟踪，可以看到不同地区网络覆盖情况差异很大，这也是我们优化调参的重要依据。

3.4 单节质量追踪

 

下图展示的是以时间作为纬度统计一节课的质量变动情况。 对一节课关键性事件、上课过程中的质量变化跟踪、整节课的质量评价，主要面向SDK研发、后端研发等业务人员。

 

3.5 排查问题

房间的时间打点主要用于问题追踪与排查，并与用户反馈相对应

4. 总结

我们的整套系统还存在许多可以进一步改进的地方，例如基于录制文件的评价标准不能完全体现下行质量，课程量大了之后服务端计算资源消耗比较高，基于参数的视频质量评价算法和Codec类型相关，不同的码流需要重新训练等等。 这也是我们未来努力探索的方向。

————————————————

版权声明：本文为CSDN博主「LiveVideoStack_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/102908244

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。