视频直播业务性能研究分析与感知评估方法Word文档格式.docx
《视频直播业务性能研究分析与感知评估方法Word文档格式.docx》由会员分享，可在线阅读，更多相关《视频直播业务性能研究分析与感知评估方法Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。
而按照内容来分，直播可以分为泛娱乐类直播、游戏类直播、体育赛事直播、泛生活类等直播，基本可以涵盖个人生活的大部分内容（如下图）：
直播分类内容及特点
2.2直播与视频点播的差异分析
直播业务和点播业务有很大差异，包括行为方式、性能侧重点要求和采用网络协议等几个方面。
1）行为方式不同。
直播业务为包含主播和观看2个方面，视频主播是指利用PC或者移动终端实时上传体育、游戏和各种生活节目的行为，这种行为称之为“Publish”，这些实时画面经过视频和音频设备采集、编码等处理后，上传到各个OTT平台服务器，再经过转码、内容分发，供粉丝们实时观看。
因此主播主要为上行方向流量，对网络带宽、速率和时延等网络性能要求较高。
观看直播，称之为“Play”，观看行为很简单，用户在众多直播频道中找到感兴趣的频道，点击播放即可，在播放过程中可以与主播进行互动。
观看主要为下行方向流量，对下行网络带宽、速率和时延等网络性能要求较高。
点播业务只有下行流量，对网络带宽、速率和时延等网络性能要求也较高；
2）性能侧重点要求不同。
直播业务对延时、卡顿、清晰度、美颜、推拉流、高分辨率等都有更高要求。
对实时性要求很高的同时，首屏时延和画面追赶等，都非常影响用户体验感知。
视频点播主要侧重于高质量（高码率）、流畅（低卡顿）和初始缓冲时长（即加载时间）；
3）使用协议的不同。
直播业务中主播主要使用RTMP协议和私有协议，观看主要使用HLS协议和RT⁃MP协议，其中HLS协议比RTMP协议时延长约2s。
点播业务主要使用HTTP渐近下载HPD（HTTPPro⁃gressiveDownload）、HTTP流媒体直播AppleHLS（HTTPLiveStreaming）和HTTP动态自适应流媒体MPEGDASH（DynamicAdaptiveStreamingoverHTTP），其中HLS和DASH均支持自适应码流技术。
直播业务中的观看和点播业务都使用HLS协议，但是直播业务和点播业务的HLS存在较大差异：
Ø
点播中使用HLS（多次请求多次下载）方式下，媒体组织格式为MPEG2-TS，媒体流和metadata信息合并保存。
每一个视频分段作为独立单位进行请求，视频分段时长2~10s，每一个分段对应一个URL，在第1个视频分段请求前需先请求分段索引文件m3u8；
在直播中使用HLS是以点播的技术方式来实现直播。
但是直播客户端获取到的，并不是一个完整的数据流。
HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断地下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停地按顺序播放从服务器获取到的文件，就实现了直播。
各直播平台推流、拉流列表
3直播业务信令原理分析
3.1直播业务原理
一个完整的视频直播系统，大致可以分为采集、前处理、编码、传输、解码、渲染6个环节（如下图）。
视频直播流程图
在主播侧，通过手机或者电脑的摄像头对图像进行采集；
在前处理阶段对采集到画面进行美颜、模糊效果、水印等视频处理；
经过前处理阶段处理后，进行分辨率、帧率、码率等编码。
终端转码后通过互联网到服务器集群中的推流服务器、转码服务器、存储服务器、分析服务器等等，最后通过分发CDN到观看节点。
在观众侧，终端通过解码，对画面进行渲染后进行观看（见下图）
直播业务架构图
3.2直播业务使用协议
直播业务主要使用实时消息传送协议（RTMP），此协议是AdobeSystems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。
也有部分平台采用私有协议，如YY直播和虎牙直播等。
RTMP协议是应用层协议，要靠底层可靠的传输层协议（TCP）来保证信息传输的可靠性，默认使用端口1935。
在基于传输层协议的链接建立完成后，RT⁃MP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMPConnection链接，在Connec⁃tion链接上会传输一些控制信息。
其中CreateStream命令会创建一个Stream链接，用于传输具体的音视频数据和控制这些信息传输的命令信息。
握手过程如图所示。
客户端发送的消息块被指定为C0、C1、C2，被服务器端发送的消息被指定为S0、S1、S2。
握手过程图
客户端发送C0和C1消息块位开始，客户端必须等到S1到达再发送C2，等到S2接收到才可以发送其他的数据；
服务端必须等到C0到达才发送S0和S1，在C1之后也会等待，等到C1到达才发送S2，等到C2到达后才发送其他数据。
3.3直播业务信令流程
以斗鱼直播为例，分析信令流程。
建立斗鱼直播房间，开始视频直播时，主播流程如下：
1）DNS查询，返回服务器地址；
2）TCP三步握手；
3）RTMP的握手；
4）建立成功，传输视频和音频数据。
4直播业务性能评估方法
4.1直播业务类型及参数识别
4.1.1直播业务类型识别
视频直播业务主要采用RTMP协议，和部分私有协议，在信令交互过程中，现有的DPI无法进行解析，需要编辑新的视频规则进行识别。
通过RTMP协议的推流服务器地址，识别推流的“Property”关键字中的“tcurl”值，并进行判断解析，可知道视频直播业务类型。
如图示，Property’tcurl’String’RTMP:
//:
1935/Live’，通过识别tcurl的值，可知其为斗鱼直播业务：
直播业务类型识别示意图
4.1.2直播业务参数识别
在主播流程建立完成后，开始进行直播时，在RT⁃MP协议的message消息中，可以看到直播终端视频中的画面分辨率、码率和视频协议等，音频中的码率和采样率等，直播软件的名称和版本号，直播终端的型号和系统版本号等信息。
4.2直播业务视频卡顿分析
直播业务采用RTMP协议应用在TCP协议层上，结合直播业务的特性，在全端采集到主播的画面和语音，迅速上传到服务器集群，分发给不同地方的观众观看。
因此主播上传视频依赖于上行带宽，当主播网络环境差或者上行带宽不足，会出现数据上传问题，此时客户端APP并无提示，主播无感知。
由于主播方数据上传出现问题时，观看方视频会出现停滞和卡顿等情况，观众体验较差。
以斗鱼直播为例，使用2台测试手机，其中一台作为主播，另外一台作为观众，标清模式下测试。
通过测试得出的结论为：
主播上行速率的最小速率门限值为1Mbit/s。
当速率低于1Mbit/s时，重传率急剧增加到10%以上，导致大量重传，观众观看主播画面卡顿严重。
因此，主播业务的理想速率在1.5Mbit/s，主播上行速率门限值在1Mbit/s，重传率在10%以下（见下图）。
实测主播业务卡顿门限制对比
4.3基于时间流分片积累算法的直播业务视频卡顿
通过现场测试，总结影响直播的主要因素为上行速率和上行重传率。
但是由于直播采用RTMP协议，属于长连接，在整个直播过程中，仅有从直播开始到直播结束建立的一个链接，在某一个时刻或者几个时刻存在重传率过高导致速率下降，观众视频画面出现卡顿问题，但整个长时间的TCP流中，指标上并不能表现出来，需要一种新的方法方式能在重传率突发时及时发现，并发出预警。
因此设计了TCP流时间分片算法，按照一定时长把TCP流进行分段，把一次直播过程按照一定时间（如5s，可以根据业务的不同，可以按需求调整），分成n个段，从t0到tn，这样可以分析每一段的速率和重传率是否满足直播要求。
如果在tx段满足重传率超过10%或者上行速率低于1Mbit/s条件，那么可以判断tx出现视频卡顿现象，卡顿次数置1，那么整个直播过程中如果有a个段出现了卡顿现象，那么整个直播过程的卡顿率=a/n。
如图7所示，直播时间为120s，按照5s一个段，那么可以分为n=24段，其中有t6和t21出现重传率高速率低问题，有卡顿现象，因此卡顿数a=2，那么这段直播的卡顿率=a/n=2/24=8.33%。
时间分片累计算法分片原理
4.4结合时间流分片积累算法的直播业务KPI指标
按照视频直播业务信令流程中的各个节点和各个功能对直播业务的信令流程性能的影响，建立评估直播业务的用户感知的KPI指标（如下）：
各指标计算方式
4.5直播业务感知评估方法实例验证
基于斗鱼直播进行测试，使用2台测试手机，其中一台作为主播，另外一台作为观众，标清模式下测试。
当观看主播出现画面卡顿时并进行记录，通过测试一共记录了9次卡顿现象。
对本次测试的主播关键指标进行统计，其整体指标良好，上行平均速率为1201.17kbit/s，上行重传率为6.62%，整体指标未达到卡顿门限值，但实际上观众观看时出现了卡顿现象（如下示）：
主播测试各指标KPI值
通过对主播测试用户信令回放，发现其中部分时段出现了大量的重传包，由于重传包较为集中，短时间内突发大量的重传包，导致观众画面停滞，画面模糊等现象。
把主播测试用户观看直播的过程，按照时间分片积累算法，由于此业务为直播业务中的主播，对实时性要求较高，因此把时间按照秒为单位分段，计算每一个时间分段的速率和重传率，是否满足直播对速率和重传的要求。
本次主播测试用户直播时长为903.71s，按照5s一个分段，共分成了180个段，其中上行速率小于1000kbit/s的有8个（如下），速率无法满足要求，观众出现视频卡顿的现象，所以卡顿率为8/180=4.44%。
速率低分段情况
截取重传率导致视频卡顿的58、59段分析，看到有连续的上行RTMP重传，导致流量急剧下降至0，出现直播视频画面停滞现象，持续约8s后才恢复正常。
对比统计卡顿次数与实际测试记录中的卡顿次数发现，统计卡顿次数与比实际测试记录少了1次，统计卡顿次数准确率为8/9=88.89%，说明本文的视频直播感知评估方法是可行的。
4.6直播业务感知评估方法应用案例
对杭师大校园区域的移动视频直播用户感知质量进行分析，经统计发现LF_H_余杭仓前杭师院宿舍楼_50（307996_50）小区下的移动视频直播用户存在上行速率过低、卡顿率过高等问题，严重影响了观众用户感知：
cell
IMSI
hour
流量MB
上行速率kbps
卡顿率%
307996_50
46011*****01785
15
17.13
601.8
9.81
46011*****03581
16
15.19
230.6
6.9
46011*****12713
11.39
910.1
6.73
46011*****19868
18
14.19
802.6
8.89
46011*****55044
19
23.59
894.4
9.91
优化前视频直播流量TOP5用户感知指标
经排查，LF_H_余杭仓前杭师院宿舍楼_50（307996_50）小区存在干扰，导致用户在该小区上网时，感知较差。
对LF_H_余杭仓前杭师院宿舍楼_50小区进行基础优化以及部分参数优化后干扰消除。
优化后，该小区下的移动视频直播用户没有出现上行速率低、卡顿率高的情况，用户感知得到有效的改善：
14
18.13
1801.8
0.42
46011*****07782
12.19
2430.6
0.53
46011*****12623
17
13.59
1710.1
0.21
46011*****16918
16.19
1902.6
0.72
46011*****15558
28.59
1874.4
0.92
优化后视频直播流量TOP5用户感知指标
优化前后视频直播流量TOP用户感知指标对比：
基于直播业务感知评估方法，对视频直播平台的TOP用户感知质量进分析优化，平均速率提升1.826mbps，卡顿率改善93%，用户感知提升显著。
5总结
近年开始直播业务得到迅速发展，视频直播融入了各行各业。
直播不同于传统的视频点播业务，对实时性要求较高，流量缓冲较小，容易产生卡顿，且采用RTMP协议。
通过对视频业务的研究，总结出视频直播平台的识别信令特征，有助于识别用户使用的视频直播平台。
基于视频直播的TCP长连接，无法准确分析整个过程中是否有卡顿现象，通过时间流分片积累算法，可分析直播过程中产生的卡顿现象，有效地评估视频直播过程中的真实感知情况。
本次通过对视频直播业务的研究分析，总结出视频直播平台的识别方法。
同时，基于视频直播的TCP长连接特性，提出一种基于时间流分片积累算法的直播业务视频评估方法，可对直播过程中的感知进行有效的评估分析，真实反映且优化改善视频直播用户的感知情况。
升级会员 