直播质量指标

一、延迟

延迟这一指标存在于整场直播的每一个环节中，一个完整的直播包括但不限于以下环节：采集、处理、编码、封装、推流、（传输、转码、分发）、拉流、解码、播放。这些每一个环节都会导致延迟的增减，排除中间一公里必须经过的地方不提（内部优化），简单介绍两端可供优化的方面。

（1） 协议层面

RTMP协议从测试数据看，时延在CDN 端可控制在600-800ms。

（2） 推流端

推流器的主要工作流程分为采集，编码，推流三个步骤。采集，主要是指摄像头和麦克风捕获画面和声音，该过程时延由硬件设备及不同终端系统决定，性能越优耗时越短。压缩编码，为了便于视频内容的存储和传输，通常需要减少视频内容的体积，也就是需要将原始的内容元素（图像和音频）经过压缩编码，而这过程中影响到压缩编码耗时将取决于视频的各项参数，比如帧率，分辨率，H264或是H265等，通常而言帧率越大，分辨率越高则对应的编码耗时则越长。推流，这个环节主要是推流buffer 的影响，正常情况为了缓解网络波动会设置大小不等的推流buffer。业内推流端四个步骤产生的耗时会在150-200ms之间。

（3） 播放端

不管是那种播放器，播放器加载完成后，即向服务器发起视频请求，以TCP 链接建立请求，此处至少有一个RTT耗时，此过程不可避免。获取到视频数据后，首先需要填充播放器buffer，而播放器buffer的大小则直接影响到了时延的大小，目前很多客户都采用动态buffer的策略来尽可能减少对时延的影响。Buffer 填充完成后，就对接收到的数据进行解析，每种视频数据的头部信息都是不同的，根据不同的头部信息提供不同的数据包解析器进行解析，将接收到的数据解析成对应的容器类型，比如.flv，数据解析完成后再进行容器解析，也即提取图像，音频，字幕等轨道信息的过程，不同的容器类型对应不同的容器解析器，根据解析获取的图像，声音，字幕，对视频流进行解码操作。图像会有大小，声音也会有大小，如果不对图像和声音进行编码处理，对视频的传输会带来非常大的阻碍，所以传输前必须经过编码处理，因此解析完成后则是对数据进行解码。数据解码这一步，做的就是将经过编码后传输的图像轨道和声音轨道进行解码（目前市面最常见的编码格式为H264），整个解码消耗时间会根据视频的分辨率，帧率，关键帧间隔（GOP）的不同而不同，总体来说分辨率，帧率，GOP 越大，解码所需耗时越长，此外移动端解码还受手机机型影响，手机性能好则可以采用硬件解码提高效率，减少耗时。

 

二、卡顿

普遍定义buffer 为空时即为卡顿，但实际上各家定义卡顿都有细小差别，主要有些客户认为buffer为空时还不会真正被用户感知到卡顿，而是在buffer为空后200ms、500ms、1s后才被用户感知，因此若buffer为空后200ms、500ms、1s 后若依然没有数据则记为卡顿。而卡顿产生的原因一般有可归纳为以下几种：

第一、主播端或观众端本身网络问题，主播上行带宽网络问题，网络状况本身不好却非要推高码率流，或是使用小运营商带来的不稳定状况，主播端的网络问题将会导致所有观众出现卡顿。观众端的网络问题，观众端下行带宽有限，却非要观看高清甚至超清码率频，这也将必然导致卡顿率上升。

第二、资源问题，我们会为客户尽可能的提供本地资源进行覆盖，若没有本地资源则采用大区覆盖的形式提供，从测试数据上来，本地资源和非本地资源覆盖的效果相差不大，而资源层面影响卡顿的主要因素在于资源是否充足，在资源充足的情况下，非本地覆盖也同样可以达到满意的效果，也即需要确保资源充足，而不是一味的追求本地覆盖。此外，除了卡顿定义有所差别，卡顿的原因多样，卡顿率的计算方式各家也有自己的一套算法，以下介绍常见两种卡顿率计算：

（1）卡顿率=卡顿人数/在线总人数。

每分钟都上报数据，但每五分钟统计一次并且同一个设备五分钟内多次卡顿算一次，所以首先需要先对终端类型进行去重，并且去掉首次缓冲和缓冲时间小于1 秒的两种情况，记录五分钟所有的卡顿人数/当下在线总人数，每五分钟一个数据进行打点。

（2）卡顿时长占比

百秒卡顿时长=sum(buffer)*100/sum(duration)

百秒卡顿次数=sum(block)*100/sum(duration)

Buffer 为空时开始记录卡顿，开始计时直到再次接收到数据为止记录为卡顿时长，每100 秒统计一次，累加卡顿时长，在直播结束后生成一条日志并计算总卡顿时长/直播时长的占比数据。卡顿次数同理。

转载于:https://my.oschina.net/elvisjun/blog/893559