直播的用户体验体系与质量监控方案

 

6月24日，又拍云OpenTalk |2018音视频技术沙龙·上海站顺利落幕，这是又拍云OpenTalk | 2018音视频技术沙龙系列活动的第二站。做为又拍云技术分享的看家活动，本次OpenTalk邀请了网易云、谷人云、又拍云、战旗等四家公司的讲师。四位讲师在活动中拿出了看家本领，为到场、观看直播的观众贡献了精彩的分享！

战旗直播高级流媒体研发工程师石硕，在现场分享了《视频直播的用户体验体系与质量监控方案》，重点介绍了直播质量监控方案的搭建，以及直播卡顿、延时监控、首屏秒开三个方面的优化。

• 直播质量评价体系
• 直播质量监控方案的结构和逻辑
• 卡顿优化的十条法则
• 延时监控：自定义扩展、数字水印
• 首屏秒开的三个优化方向

△ 石硕：战旗直播高级流媒体研发工程师

如下是石硕分享内容的整理：

 

你们好，我是来自战旗直播平台的高级流媒体工程师石硕。今天我主要讲两个内容：第一方面，直播、点播的总体用户体验体系。现有公开场合讲总体用户体验体系的内容偏少一点。另外一方面，“质量监控方案”，这也不多有说起的。

从本质上来说，用户体验和质量监控，作的是一件事情，即：在必定程度上保证用户观看直播的体验是最好的。

个人分享内容主要分为四个部分：

• 直播质量评价。用户体系覆盖了哪些方面，用户总体的体验由几部分组成的。
• 卡顿监控与优化。卡顿优化依赖于监控体系如何发现卡顿现象。
• 延时监控的难题。视频延时监控存在难题，由于如今业界对于“延时”的监控仍是比较欠缺，商用方案里面尚未看到比较切实有效的办法。
• 首屏优化要点。首屏优化在行业里讲得比较多，我简单罗列一下要点。

 

直播质量评价体系

直播质量评价这一块，先讲一下音视频的质量评价体系。

音视频评价起源比较早。早在1996年，ITU国际组织就已经有了主观评价流媒体音视频的传输质量，当时主要评测电话的通话质量。而后在2003年根据我的主观评价提出了一套MOS体系，2012年、2013年对MOS体系进行了不一样方面的补充，推出了vMos体系。

今天我主要讲华为的U-vMOS主观质量评价体系。一方面，对整套体系，国内中文的资料比较充实；另外一方面，U-vMOS在vMOS的基础上面作扩展的，U-vMOS的整个质量体系，也是在vMOS内容里面的。

MOS质量评价的主要目的，是根据用户的主观体验来对音频或者是视频质量进行评分。它的分值，常规意义上是分为五分，分值越高它的质量就越好。

△ MOS质量评价△ U-vMOS质量评价的建模方法

MOS质量评价体系针对音频质量。视频质量的评价能够在这个基础上作一个延伸，具体看一下U-vMOS质量评价体系。

U-vMOS将视频质量评价分为三个部分：

• 视频质量，指视频的分辨率、帧率、码率、编码级别；
• 互动体验，主要指被叫视频载入时间的长短；
• 观看体验，主要指画面的花屏和卡顿。

针对视频质量的各类相关因素，其中咱们能取到的“典型分值”的“分”，主要是播放设备的屏幕尺寸及视频的分辨率，这两个相关度是比较大。

视频质量的评分

△ 视频质量：视频分辨率与屏幕尺寸的关系

4分以上能够算是比较好的观看体验，看这张表格，4.5寸、5.5寸的手机屏幕，都至少须要有720P的视频流才能达到4分以上。那咱们作手机的视频服务时，若是用户对于视频的要求不是特别苛刻，一般状况来说720P足够了；个别提供1080P，其实对观看体验并无特别大的提高，仅从4.3分提高到4.6分，这个过程不光对码率有要求，视频帧率、解码难度都会高出不少。

通常电视端想要达到4.0分以上的观看体验的话，须要1080P的视频。这个表格对直播企业的对于视频流分辨率的选择是具备必定参考意义的。

视频体验，首屏秒开的标准

互动体验，主要是涉及到常规意义上所讲的“首屏秒开”。首屏秒开一般被认为在100毫秒之内才算完美。

这个要求是局域网环境下，公网环境下首屏秒开达到100毫秒的几乎没有，或者说特别少。常规意义上，咱们都会努力让首屏秒开作到1秒也就是1000毫秒左右的时间。

咱们能了解到的，现有像快手、斗鱼、虎牙这一类的App，一般首屏时间都会作到3秒之内。3秒是一个界限，你们通常是2秒左右。

△ 互动体验（首屏秒开）的典型分值

观看体验：花屏再也不，重在优化卡顿

观看体验包括两部分：花屏和卡顿。

如今直播平台在又拍云等CDN服务商的努力下，“花屏”已经出现得不多了，主要影响观看体验得因素是“卡顿“，主要指的是在一分钟内卡顿出现了多少次，每一次卡顿的时长有多少，最后得出来一个卡顿的时长占比。观看体验的质量评价体系是实验室环境下得出的。

 

△ 观看体验的典型分值 (卡顿统计周期1分钟)

直播质量监控方案的结构和逻辑

国外针对于这一套体系的执行方面可能会更多一些，国内企业目前来讲主要关注的多是卡顿和首屏秒开。延时的话，关注相对会少一些。

咱们重点讲一下卡顿的优化体系，包括“卡顿监控”，以及监控的结果收集完以后进行的一些优化工做。

△ 直播质量监控系统组成

卡顿主要分为四个部分：数据收集、数据分析、数据展现、预警系统。

数据收集，收集主播端和观看端的设备信息、网络环境。设备信息主要是指设备机型、用户IP，以及视频流的分辨率、码率，包括播放过程当中的CPU使用率、GDP使用率、内存使用率。网络环境，主要指链接方式。还有一些须要探测才能得知的数据，好比：优先收集手机到本地路由器的网络状况，而后收集手机到公网出口的环境，以及手机到CDN节点的网络状况。第三部分数据是正常监控须要的，包括卡顿数据、首屏数据、延时数据。

数据分析，收集完以后，放到大数据中心作一些数据过滤、综合分析；把用户ID分门别类的处理成咱们实际上运营须要的监控数据。

第三是数据展现，这一块主要是地图展现。在一张地图上面，把卡顿率及其它的一些数据展示出来，就是观看会更方便一些。这是战旗总体卡顿监控的监控图表，左下角标注了卡顿率从低到高，最低是“0”，最高是“15”。能够看到，战旗的卡顿率应该在“4”个点之内，通常是3点多。

 

△ 卡顿数据展现示意图

第四部分是预警系统。这一块主要是运维人员及CDN厂商。常规意义上，这个预警一般会直接给本身公司的运营人员。可是作直播的，基本上都会用到CDN厂商的云加速服务。若是咱们发现用户卡顿的话，其实最终会分析得出来用户卡顿缘由是CDN某个节点很差，把这个分析反馈给CDN，让CDN进行相应的调整。

△ 卡顿监控体系的运行逻辑

整个监控体系，咱们这边能够简单的分为五大部分：客户端、监控系统、运维支持、智能调度、CDN厂商。

监控系统首先是给运维支持，而后是给CDN厂商，告诉发生了某个事。而后是给智能调度系统，这一部分的报警级别相对低一点，是针对个别用户的报警。咱们能够针对用户报警，根据他的硬件设备状况及网络状况作一次智能调度。好比：探测到带宽不够，发生了卡顿；调度系统只须要给客户端发一条命令，告诉它带宽不够，让它把码率降一级，可能卡顿状况就会缓解。

卡顿优化十条法则

针对于卡顿优化，咱们这边能够分为十个部分：

• HTTP-DNS调度
• 播放端本地调度
• 服务端智能调度
• 服务端手动调度
• CDN手动调度
• 使用UDP推流
• 推流端流畅度监控
• 提供多种清晰度选择
• 播放器优化
• 用户反馈系统

HTTP-DNS调度：在国内DNS污染会比较严重，可能会把DNS解析到错误的节点上去。这个解析服务，可能会把你的域名，好比把海徐汇区的域名解析到浦东新区去。咱们尽量去避免这种错误，这个时候就须要HTTP-DNS调度。咱们每次拉一个地址以前，使用本身的服务器先作一次解析，保证每次反馈给你是最近的服务节点，这就会比较流畅。

播放端本地调度：若是发现用户播放比较卡顿，咱们本地会有一些检测机制。好比检测是硬件CPU不高，CPU使用率超高了，咱们可能就会把它的分辨率、解码率降一下，让CPU有所缓解，这个时候卡顿就会缓解。另外，也多是网络致使的本地卡顿，咱们就能够给他换一个服务节点，或者是作一些其它的处理。

服务器端智能调度、服务器端手动调度：服务器端的智能调度、手动调度，这个主要是在后端经过远程方式去作一些调整。在智能调度系统里面，咱们会根据用户的状况作统一调度。好比用户硬件不够了，咱们帮他加一点。若是用户卡顿的话，咱们先要判断是CDN节点的问题，仍是用户本身的问题。若是是CDN节点的问题，咱们帮他自动调到下一个节点去。

CDN手动调度：指手动干预的方式。好比：如今发生了用户卡顿，智能调度系统好比发现上海徐汇区的一个服务节点特别很差，咱们能够手动把这个节点拉黑掉，用户不会访问到这个质量比较差的节点。

第四点、第五点是会有必定的重合度，由于CDN的手动调度也是根据智能调度系统收集到的数据、下发的数据来进行相应的一些处理。

UDP推流：TCP的协议容灾和慢恢复机制致使它抵抗网络抖动的能力会比较差。为了解决由于网络抖动致使的卡顿问题，咱们会使用“自定义”或者是自有UDP协议处理这个问题。谷歌以前有推出相似于“类UDP”的各类SDK包，使用UDP代替TCP对抗网络抖动，能够把TCP的容灾机制、恢复机制规避掉，能够快速地恢复网络。UDP还有一个做用，在丢包的状况下“抗丢包能力”比较好，它能够本身自主决定“重发多少数据包”。

推流端流畅度监控：这一块主要是监控主播推流是否有音视频不一样步或者帧率不够的状况。若是主播端卡顿的话，全部的用户调度到任何节点都会卡顿，因此推流端监控相对会重要一些。针对于主播端的监控，咱们实时反馈给主播，让主播切换网络或者是作一些调整。

提供多种清晰度选择：提供多种清晰度选择，这个主要针对于用户手动操做的。一般状况下会提供标情、高清、超清等多种分辨率。不一样的分辨率对应的码率、编码复杂度都是不同的。清晰度越高，相应解码的难度就会越高。让用户能够手动去选择，在总体状况比较好的时间，他能够提升清晰度。当发生卡顿的状况下，能够手动降清晰度或者是降分辨率，能够解决一部分卡顿的问题。

播放器优化：播放器的优化，针对于卡顿主要是处理两个事情：一个是音视频不一样步致使的卡顿。第二部分，主要是针对于缓冲区的处理，缓冲区相对于对抗“网络抖动”是比较有用处的。

用户反馈系统：这一块是用户主动提供一些卡顿的建议或者问题，用户的反馈系统能够做为咱们总体监控系统的一个补充，能够帮咱们改善整个监控系统。

延时监控：自定义扩展、数字水印

下面讲一下“延时监控”。“延时监控”我主要讲两个部分的内容：

第一部分，开发阶段延时的计算及延时的优化；

第二部分，发布阶段的延时计算。

一般状况下，直播研发的开发阶段的延时都会以“北京时间”的方式作对比。

 

△ 左图是推流端本地的“北京时间”，右边是播放器播放的“北京时间”

开发阶段的延时，推流工具、播放工具在同一台机器上。左边的时间减去右边的时间，实际上就是直播延时。咱们能够看到上图的直播延时是2秒2毫秒。

开发阶段的延时计算到了发布阶段已经无论用了，由于正常状况下不可能实时盯着用户手机看“延时多高”，也不可能在视频流里面嵌入一个“北京时间”。

发布阶段延时计算须要借助一些另外的手段，一种方式是自定义扩展，一种方式是数字水印。

自定义扩展实现延时监控

自定义扩展利用直播协议里面的一些自定义字段作延时监控。

一个选择是FLV协议的metadata字段。FLV协议自己有字段，能够嵌入，而后在推流时发“北京时间”放到这个metadata字段里面去，接到以后把它和本地的“北京时间”作差值。

第二个能够扩展的地方，是H.26四、H.265编码的SEI字段，这个字段也能够自定义作扩展，计算延时的方法也是相同的，就是在这个字段里面嵌入“北京时间”就能够了。

自定义扩展的两种方法有好处——配置比较简单。

固然也有比较难的地方。由于CDN自己会有转码系统和分发系统，若是不和CDN厂商强调的话，全部的自定义字段从CDN系统过一遍以后所有都会删除掉。

还有一个有问题的地方，在于CDN分发视频流，默认会把全部的视频流，不管是从什么时间开始拉流的，都会“从零开始”。这个时候咱们在字段里面嵌入的“北京时间”，实际上就没有参照对象，由于咱们是根据视频流里面每一帧视频的时间，以及嵌入到自定义字段的时间，还有本地时间三者作“差”获得的延时，这一部分会有影响。

数字水印实现延时监控

基于前面两种方法的缺点，而后咱们又扩展出了根据“数字水印”来嵌入数据计算延时的方法。“数字水印”出现得比较早，原来是用于音视频版权确认，在音视频嵌入不可见、听不到的数据，这对于总体音视频质量影响比较小，可是经过某种算法能够嵌入进去、能够被提取出来，主要是应用在这个方面。

我简单讲一下“数字水印”的原理，数字水印能够嵌入的地方比较多。

先了解下经过修改YUV原始数据或PCM原始数据植入数字水印。以720P分辨率的视频流为参照，每一张画面是1280×720像素点，每一个像素点是由一个Y以及1/4U、1/4V组成的。一般状况下在Y里面，每个Y像素是有8比特数据组成的。也就是说，数据范围能够从-127到127。Y数据总共有8比特，咱们能够把它末三位抹掉，而后再嵌入咱们想要的数据。好比：咱们想要的第一个Y像素点里面，就嵌入一个数字“0”或者是“1”，咱们能够把8比特后3位抹掉，在里面嵌入后3位是“0-7”的，咱们嵌入一个“3”表明“0”，嵌入一个“6”表明“1”。嵌入以后，而后根据一样的方式把这个方式再提取出来，而后把这个数据再还原，就能够获得咱们嵌入的YUV里面的数据。这种方式嵌入的话，会有必定的影响。由于正常状况下，咱们知道Y数据是“-127”到“127”。末三位改变之后会对色彩有影响。数据准确率越高，就须要抹掉的比特位数越多，对于视频的损伤就越大。咱们想要准确度越高，又须要比较多的比特位数，这个时候就须要作一些取舍。

PCM也是一样的方式，在末位不重要、比较小的数据上面作一些修改。

再看下经过AAC量化子带或H.264块的DCT参数实现数字水印。

AAC量化子带由一系列的参数组成的，咱们能够改写参数第一位。

H.264块的DCT参数，相应这个参数的修改方法也是同样的，改第一位的不重要的这些数据。

客观地讲，刚才几种方式里面，在数据的嵌入、提取的过程当中会受到CDN转码系统的必定影响。由于正常状况下，咱们知道从YUV数据到H.264从新再解码出YUV的时候，这个YUV数据实际上是发生了一些变化，只是这个变化被控制在必定的范围内，绝大多数的状况下是看不出差异。

这个时候，在刚才讲到的这些算法之上，延伸出了一些算法，针对于这些数据的这些参数；咱们刚才讲的是直接在这些数据里面作修改，作延伸处理的方法是把这些数据放进，像压缩一般会用到的“离散预选”参数。这个算法相对来讲，对于原始数据的修改会更小，而后提取的成功率也会更高。

 

首屏秒开的三个优化方向

简单过一下首屏秒开优化的要点。首屏优化的话题可能会特别多，我这里就不一个一个去解释了；这里提供首屏秒开的三个优化方向，有优化需求的话，按照推流、转发、播放三个方向去作优化，确定能收到效果。

推流优化——主播端：

• 合理的GOP值(建议2秒)
• 减小帧间依赖，不使用P帧
• X264无延时编码
• 合理的分辨率、码率、帧率
• 使用UDP对抗网络抖动

转发优化——CDN

• 缓存GOP数据
• 提早预热资源
• TCP单边加速
• 提供多路转码流

播放优化——播放端

• 优先加载视频流数据
• 可变缓存，先小后大
• 使用HTTPDNS分配节点
• 优化FFmpeg视频流探测
• 网络请求并行加载

我今天讲的内容大致上就是这些，谢谢你们的聆听。

 

问答部分

Q1：赛事直播、游戏直播的时候，主播推流必定会延迟。昨天我碰见一个主播，延迟就已经有20秒，也就是说在编码完了以后，会有20秒才会推出来，这样的话，数字水印是不许确的。我看战旗也有不少游戏主播，这个问题怎么解决的？

石硕：这分为两方面。咱们若是要作延时计算，相应来讲直播用的工具咱们是可控的。像刚才您讲的状况，应该是这个主播用的是开源的OBS推流工具。针对于OBS的推流工具，咱们须要作一些特殊的处理。战旗为OBS开发一个插件，这个插件是嵌入视频水印的。第二这个插件要获取OBS缓冲延时，把这个数据获取以后，针对嵌入的视频水印会作一些特殊处理。若是是用本身的直播软件，相应的来讲时延就是本地的缓冲区都是本身设置的，相应作一下处理就行了。

Q2：我前两天刚上线了网页端的H.265，码率比较低；发现卡顿主要缘由来自于硬件状况，好比CPU不够或者GPU不行。我考虑在网页端加一些什么样的东西，获取到用户的硬件状况，而后发现能获取到的硬件状况很是有限，跟移动端在上H.265彻底不同的状态。国内主流的浏览器能够获取到用户的内存状况，但获取不到GPU等信息，即使有问题很难定位。战旗在这一块，目前是怎么解决的？

石硕：这是一个很好的问题。如今主流的浏览器、比较常见的浏览器，一般状况下若是用HTML5作直播，会默认更多得去选硬件。受限于浏览器，咱们是拿不到GPU信息的。这个时候，咱们会获取一些再外围的数据信息，好比去拿CPU型号，进而获取GPU信息。某几个GPU幸亏解1080P确实不行，这个时候咱们能够尝试把它的分辨率从1080降到720P，这个时候它的GPU是能吃得消的。

 

分享PPT+视频实录传送门：

视频直播的用户体验体系与质量监控方案​