视频直播业务性能研究分析与感知评估方法

程 乔，王映华，韦 亮

（中国联通广西分公司，广西南宁530028）

0 引言

随着智能手机的普及，云计算的应用推广，技术壁垒的打破，直播业务得到了迅速发展。随着众多影视明星、体育明星、大佬为直播的推广，还有电商、社交平台、新闻等的加入，直播参与人群迅速扩大，对网络性能速率和时延敏感，对感知要求提高。并且直播业务的用户ARPU值贡献较高，具有较强的消费能力和较高的流量贡献。

视频直播采用RTMP协议，实时传输性较强，与传统视频点播业务存在差异，采用普通的点播视频的评估方式，无法对直播业务进行有效的性能评估。迫切需要针对直播业务进行相应的研究分析，分析直播业务特性和DPI深度识别，研究直播速率和直播过程中的卡顿评估方法，为直播业务热点场景进行保障。

1 网络直播业务现状

1.1 网络直播概述

直播这种社交泛娱乐方式早在2005年左右就已经出现，但真正将直播带入大众视线的还是在移动互联网时代下的移动直播。

a）技术壁垒打破。云计算技术应用使很多技术可以通过云端和第三方来实现。

b）智能手机摄像发展。高清智能手机摄像技术被大量应用。

c）智能手机普及。高性能智能手机的普及。

这3个方面的发展使2016年直播真正成为了“全民直播”，有统计数据显示存在200个左右的直播平台，因此2016被称为直播元年。

按照直播设备的不同，直播分为PC端的秀场直播以及移动直播；而按照内容来分，直播可以分为泛娱乐类直播、游戏类直播、体育赛事直播、泛生活类等直播，基本可以涵盖个人生活的大部分内容（见图1）。

1.2 直播与视频点播的差异分析

图1 直播分类内容及特点

直播业务和点播业务有很大差异，包括行为方式、性能侧重点要求和采用网络协议等几个方面。

a）行为方式不同。直播业务为包含主播和观看2个方面，视频主播是指利用PC或者移动终端实时上传体育、游戏和各种生活节目的行为，这种行为称之为“Publish”，这些实时画面经过视频和音频设备采集、编码等处理后，上传到各个OTT平台服务器，再经过转码、内容分发，供粉丝们实时观看。因此主播主要为上行方向流量，对网络带宽、速率和时延等网络性能要求较高。观看直播，称之为“Play”，观看行为很简单，用户在众多直播频道中找到感兴趣的频道，点击播放即可，在播放过程中可以与主播进行互动。观看主要为下行方向流量，对下行网络带宽、速率和时延等网络性能要求较高。点播业务只有下行流量，对网络带宽、速率和时延等网络性能要求也较高。

b）性能侧重点要求不同。直播业务对延时、卡顿、清晰度、美颜、推拉流、高分辨率等都有更高要求。对实时性要求很高的同时，首屏时延和画面追赶等，都非常影响用户体验感知。视频点播主要侧重于高质量（高码率）、流畅（低卡顿）和初始缓冲时长（即加载时间）。

c）使用协议的不同。直播业务中主播主要使用RTMP协议和私有协议，观看主要使用HLS协议和RTMP协议，其中HLS协议比RTMP协议时延长约2 s。点播业务主要使用HTTP渐近下载HPD（HTTP Progressive Download）、HTTP流 媒 体 直 播Apple HLS（HTTP Live Streaming）和HTTP动态自适应流媒体MPEG DASH（Dynamic Adaptive Streaming over HTTP），其中HLS和DASH均支持自适应码流技术。

直播业务中的观看和点播业务都使用HLS协议，但是直播业务和点播业务的HLS存在较大差异。

点播中使用HLS（多次请求多次下载）方式下，媒体组织格式为MPEG2-TS，媒体流和metadata信息合并保存。每一个视频分段作为独立单位进行请求，视频分段时长2～10 s，每一个分段对应一个URL，在第1个视频分段请求前需先请求分段索引文件m3u8。

在直播中使用HLS是以点播的技术方式来实现直播。但是直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断地下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停地按顺序播放从服务器获取到的文件，就实现了直播。

表1给出了直播平台推流、拉流列表。

2 直播业务信令原理分析

2.1 直播业务原理

表1 各直播平台推流、拉流列表

一个完整的视频直播系统，大致可以分为采集、前处理、编码、传输、解码、渲染6个环节（见图2）。

图2 视频直播流程图

在主播侧，通过手机或者电脑的摄像头对图像进行采集；在前处理阶段对采集到画面进行美颜、模糊效果、水印等视频处理；经过前处理阶段处理后，进行分辨率、帧率、码率等编码。终端转码后通过互联网到服务器集群中的推流服务器、转码服务器、存储服务器、分析服务器等等，最后通过分发CDN到观看节点。在观众侧，终端通过解码，对画面进行渲染后进行观看（见图3）。

图3 直播业务架构

2.2 直播业务使用协议

直播业务主要使用实时消息传送协议（RTMP），此协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。也有部分平台采用私有协议，如YY直播和虎牙直播等。

RTMP协议是应用层协议，要靠底层可靠的传输层协议（TCP）来保证信息传输的可靠性，默认使用端口1935。在基于传输层协议的链接建立完成后，RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMPConnection链接，在Connection链接上会传输一些控制信息。其中CreateStream命令会创建一个Stream链接，用于传输具体的音视频数据和控制这些信息传输的命令信息。

握手过程如图4所示。客户端发送的消息块被指定为C0、C1、C2，被服务器端发送的消息被指定为S0、S1、S2。

图4 握手过程

客户端发送C0和C1消息块位开始，客户端必须等到S1到达再发送C2，等到S2接收到才可以发送其他的数据；服务端必须等到C0到达才发送S0和S1，在C1之后也会等待，等到C1到达才发送S2，等到C2到达后才发送其他数据。

2.3 直播业务信令流程

以斗鱼直播为例，分析信令流程。建立斗鱼直播房间，开始视频直播时，主播流程如下。

a）DNS查询，返回服务器地址。

b）TCP三步握手。

c）RTMP的握手。

d）建立成功，传输视频和音频数据。

3 直播业务性能评估方法

3.1 直播业务类型及参数识别

3.1.1 直播业务类型识别

视频直播业务主要采用RTMP协议，和部分私有协议，在信令交互过程中，现有的DPI无法进行解析，需要编辑新的视频规则进行识别。

通过RTMP协议的推流服务器地址，识别推流的“Property”关键字中的“tcurl”值，并进行判断解析，可知道视频直播业务类型。如图5所示，Property‘tcurl’String‘RTMP：//send3.douyu.com：1935/Live’，通过识别tcurl的值，可知其为斗鱼直播业务。

图5 直播业务类型识别示意图

3.1.2 直播业务参数识别

在主播流程建立完成后，开始进行直播时，在RTMP协议的message消息中，可以看到直播终端视频中的画面分辨率、码率和视频协议等，音频中的码率和采样率等，直播软件的名称和版本号，直播终端的型号和系统版本号等信息。

3.2 直播业务视频卡顿分析

直播业务采用RTMP协议应用在TCP协议层上，结合直播业务的特性，在全端采集到主播的画面和语音，迅速上传到服务器集群，分发给不同地方的观众观看。因此主播上传视频依赖于上行带宽，当主播网络环境差或者上行带宽不足，会出现数据上传问题，此时客户端APP并无提示，主播无感知。由于主播方数据上传出现问题时，观看方视频会出现停滞和卡顿等情况，观众体验较差。

以斗鱼直播为例，使用2台测试手机，其中一台作为主播，另外一台作为观众，标清模式下测试。通过测试得出的结论为：主播上行速率的最小速率门限值为1 Mbit/s。当速率低于1 Mbit/s时，重传率急剧增加到10%以上，导致大量重传，观众观看主播画面卡顿严重。因此，主播业务的理想速率在1.5 Mbit/s，主播上行速率门限值在1 Mbit/s，重传率在10%以下（见图6）。

图6 实测主播业务卡顿门限制对比

3.3 基于时间流分片积累算法的直播业务视频卡顿

通过现场测试，总结影响直播的主要因素为上行速率和上行重传率。但是由于直播采用RTMP协议，属于长连接，在整个直播过程中，仅有从直播开始到直播结束建立的一个链接，在某一个时刻或者几个时刻存在重传率过高导致速率下降，观众视频画面出现卡顿问题，但整个长时间的TCP流中，指标上并不能表现出来，需要一种新的方法方式能在重传率突发时及时发现，并发出预警。

因此设计了TCP流时间分片算法，按照一定时长把TCP流进行分段，把一次直播过程按照一定时间（如5 s，可以根据业务的不同，可以按需求调整），分成n个段，从t0到tn，这样可以分析每一段的速率和重传率是否满足直播要求。如果在tx段满足重传率超过10%或者上行速率低于1 Mbit/s条件，那么可以判断tx出现视频卡顿现象，卡顿次数置1，那么整个直播过程中如果有a个段出现了卡顿现象，那么整个直播过程的卡顿率=a/n。如图7所示，直播时间为120 s，按照5 s一个段，那么可以分为n=24段，其中有t6和t21出现重传率高速率低问题，有卡顿现象，因此卡顿数a=2，那么这段直播的卡顿率=a/n=2/24=8.33%。

图7 时间分片累计算法分片原理

3.4 结合时间流分片积累算法的直播业务KPI指标

按照视频直播业务信令流程中的各个节点和各个功能对直播业务的信令流程性能的影响，建立评估直播业务的用户感知的KPI指标（见表2）。

表2 各指标计算方式表

3.5 直播业务感知评估方法实例验证

基于斗鱼直播进行测试，使用2台测试手机，其中一台作为主播，另外一台作为观众，标清模式下测试。当观看主播出现画面卡顿时并进行记录，通过测试一共记录了9次卡顿现象。对本次测试的主播关键指标进行统计，其整体指标良好，上行平均速率为1 201.17 kbit/s，上行重传率为6.62%，整体指标未达到卡顿门限值，但实际上观众观看时出现了卡顿现象（见表3）。

表3 主播测试各指标KPI值

通过对主播测试用户信令回放，发现其中部分时段出现了大量的重传包，由于重传包较为集中，短时间内突发大量的重传包，导致观众画面停滞，画面模糊等现象。把主播测试用户观看直播的过程，按照时间分片积累算法，由于此业务为直播业务中的主播，对实时性要求较高，因此把时间按照秒为单位分段，计算每一个时间分段的速率和重传率，是否满足直播对速率和重传的要求。

本次主播测试用户直播时长为903.71 s，按照5 s一个分段，共分成了180个段，其中上行速率小于1 000 kbit/s的有8个（见表4），速率无法满足要求，观众出现视频卡顿的现象，所以卡顿率=8/180=4.44%。

截取重传率导致视频卡顿的58、59段分析，看到有连续的上行RTMP重传，导致流量急剧下降至0，出现直播视频画面停滞现象，持续了约8 s后才恢复正常。

表4 速率低分段情况

对比统计卡顿次数与实际测试记录中的卡顿次数发现，统计卡顿次数与比实际测试记录少了1次，统计卡顿次数准确率为8/9=88.89%，说明本文的视频直播感知评估方法是可行的。

4 直播业务感知评估方法应用

2017年5 月广西联通开展直播业务感知质量提升专项，基于直播业务感知评估方法，对斗鱼直播、虎牙直播、熊猫直播、映客直播等主流直播平台的用户感知质量进分析优化，共分析排查了3个服务器IP和120个视频直播质差小区，平均速率提升10.53%，卡顿率改善1.28%，用户感知提升显著。

应用案例：基于直播业务感知评估方法，对南宁校园区域的移动视频直播用户感知质量进行分析，经统计发现30466_6969021（GX南宁广西工商学校_FLTE基站_F_1）小区下的移动视频直播用户存在上行速率过低、卡顿率过高等问题，严重影响了观众用户感知（见表5）。

经排查，30466_6969021小区存在干扰，导致用户在该小区上网时，感知较差。对30466_6969021小区进行优化后，干扰消除。优化后，该小区下的移动视频直播用户没有出现上行速率低、卡顿率高的情况，用户感知得到有效的改善（见表6）。

表5 优化前视频直播流量TOP 5用户感知指标

表6 优化后视频直播流量TOP 5用户感知指标

5 结束语

2016年开始直播业务得到迅速发展，视频直播融入了各行各业。直播不同于传统的视频点播业务，对实时性要求较高，流量缓冲较小，容易产生卡顿，且采用RTMP协议。通过对视频业务的研究，总结出视频直播平台的识别信令特征，有助于识别用户使用的视频直播平台。基于视频直播的TCP长连接，无法准确分析整个过程中是否有卡顿现象，通过时间流分片积累算法，可分析直播过程中产生的卡顿现象，有效地评估视频直播过程中的真实感知情况。