程 喬，王映華，韋 亮

（中國聯通廣西分公司，廣西南寧530028）

0 引言

隨著智能手機的普及，云計算的應用推廣，技術壁壘的打破，直播業(yè)務得到了迅速發(fā)展。隨著眾多影視明星、體育明星、大佬為直播的推廣，還有電商、社交平臺、新聞等的加入，直播參與人群迅速擴大，對網絡性能速率和時延敏感，對感知要求提高。并且直播業(yè)務的用戶ARPU值貢獻較高，具有較強的消費能力和較高的流量貢獻。

視頻直播采用RTMP協議，實時傳輸性較強，與傳統(tǒng)視頻點播業(yè)務存在差異，采用普通的點播視頻的評估方式，無法對直播業(yè)務進行有效的性能評估。迫切需要針對直播業(yè)務進行相應的研究分析，分析直播業(yè)務特性和DPI深度識別，研究直播速率和直播過程中的卡頓評估方法，為直播業(yè)務熱點場景進行保障。

1 網絡直播業(yè)務現狀

1.1 網絡直播概述

直播這種社交泛娛樂方式早在2005年左右就已經出現，但真正將直播帶入大眾視線的還是在移動互聯網時代下的移動直播。

a）技術壁壘打破。云計算技術應用使很多技術可以通過云端和第三方來實現。

b）智能手機攝像發(fā)展。高清智能手機攝像技術被大量應用。

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

這3個方面的發(fā)展使2016年直播真正成為了“全民直播”，有統(tǒng)計數據顯示存在200個左右的直播平臺，因此2016被稱為直播元年。

按照直播設備的不同，直播分為PC端的秀場直播以及移動直播；而按照內容來分，直播可以分為泛娛樂類直播、游戲類直播、體育賽事直播、泛生活類等直播，基本可以涵蓋個人生活的大部分內容（見圖1）。

1.2 直播與視頻點播的差異分析

圖1 直播分類內容及特點

直播業(yè)務和點播業(yè)務有很大差異，包括行為方式、性能側重點要求和采用網絡協議等幾個方面。

a）行為方式不同。直播業(yè)務為包含主播和觀看2個方面，視頻主播是指利用PC或者移動終端實時上傳體育、游戲和各種生活節(jié)目的行為，這種行為稱之為“Publish”，這些實時畫面經過視頻和音頻設備采集、編碼等處理后，上傳到各個OTT平臺服務器，再經過轉碼、內容分發(fā)，供粉絲們實時觀看。因此主播主要為上行方向流量，對網絡帶寬、速率和時延等網絡性能要求較高。觀看直播，稱之為“Play”，觀看行為很簡單，用戶在眾多直播頻道中找到感興趣的頻道，點擊播放即可，在播放過程中可以與主播進行互動。觀看主要為下行方向流量，對下行網絡帶寬、速率和時延等網絡性能要求較高。點播業(yè)務只有下行流量，對網絡帶寬、速率和時延等網絡性能要求也較高。

b）性能側重點要求不同。直播業(yè)務對延時、卡頓、清晰度、美顏、推拉流、高分辨率等都有更高要求。對實時性要求很高的同時，首屏時延和畫面追趕等，都非常影響用戶體驗感知。視頻點播主要側重于高質量（高碼率）、流暢（低卡頓）和初始緩沖時長（即加載時間）。

c）使用協議的不同。直播業(yè)務中主播主要使用RTMP協議和私有協議，觀看主要使用HLS協議和RTMP協議，其中HLS協議比RTMP協議時延長約2 s。點播業(yè)務主要使用HTTP漸近下載HPD（HTTP Progressive Download）、HTTP流 媒 體 直 播Apple HLS（HTTP Live Streaming）和HTTP動態(tài)自適應流媒體MPEG DASH（Dynamic Adaptive Streaming over HTTP），其中HLS和DASH均支持自適應碼流技術。

直播業(yè)務中的觀看和點播業(yè)務都使用HLS協議，但是直播業(yè)務和點播業(yè)務的HLS存在較大差異。

點播中使用HLS（多次請求多次下載）方式下，媒體組織格式為MPEG2-TS，媒體流和metadata信息合并保存。每一個視頻分段作為獨立單位進行請求，視頻分段時長2～10 s，每一個分段對應一個URL，在第1個視頻分段請求前需先請求分段索引文件m3u8。

在直播中使用HLS是以點播的技術方式來實現直播。但是直播客戶端獲取到的，并不是一個完整的數據流。HLS協議在服務器端將直播數據流存儲為連續(xù)的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷地下載并播放這些小文件，因為服務器端總是會將最新的直播數據生成新的小文件，這樣客戶端只要不停地按順序播放從服務器獲取到的文件，就實現了直播。

表1給出了直播平臺推流、拉流列表。

2 直播業(yè)務信令原理分析

2.1 直播業(yè)務原理

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

一個完整的視頻直播系統(tǒng)，大致可以分為采集、前處理、編碼、傳輸、解碼、渲染6個環(huán)節(jié)（見圖2）。

圖2 視頻直播流程圖

在主播側，通過手機或者電腦的攝像頭對圖像進行采集；在前處理階段對采集到畫面進行美顏、模糊效果、水印等視頻處理；經過前處理階段處理后，進行分辨率、幀率、碼率等編碼。終端轉碼后通過互聯網到服務器集群中的推流服務器、轉碼服務器、存儲服務器、分析服務器等等，最后通過分發(fā)CDN到觀看節(jié)點。在觀眾側，終端通過解碼，對畫面進行渲染后進行觀看（見圖3）。

圖3 直播業(yè)務架構

2.2 直播業(yè)務使用協議

直播業(yè)務主要使用實時消息傳送協議（RTMP），此協議是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸開發(fā)的開放協議。也有部分平臺采用私有協議，如YY直播和虎牙直播等。

RTMP協議是應用層協議，要靠底層可靠的傳輸層協議（TCP）來保證信息傳輸的可靠性，默認使用端口1935。在基于傳輸層協議的鏈接建立完成后，RTMP協議也要客戶端和服務器通過“握手”來建立基于傳輸層鏈接之上的RTMPConnection鏈接，在Connection鏈接上會傳輸一些控制信息。其中CreateStream命令會創(chuàng)建一個Stream鏈接，用于傳輸具體的音視頻數據和控制這些信息傳輸的命令信息。

握手過程如圖4所示。客戶端發(fā)送的消息塊被指定為C0、C1、C2，被服務器端發(fā)送的消息被指定為S0、S1、S2。

圖4 握手過程

客戶端發(fā)送C0和C1消息塊位開始，客戶端必須等到S1到達再發(fā)送C2，等到S2接收到才可以發(fā)送其他的數據；服務端必須等到C0到達才發(fā)送S0和S1，在C1之后也會等待，等到C1到達才發(fā)送S2，等到C2到達后才發(fā)送其他數據。

2.3 直播業(yè)務信令流程

以斗魚直播為例，分析信令流程。建立斗魚直播房間，開始視頻直播時，主播流程如下。

a）DNS查詢，返回服務器地址。

b）TCP三步握手。

c）RTMP的握手。

d）建立成功，傳輸視頻和音頻數據。

3 直播業(yè)務性能評估方法

3.1 直播業(yè)務類型及參數識別

3.1.1 直播業(yè)務類型識別

視頻直播業(yè)務主要采用RTMP協議，和部分私有協議，在信令交互過程中，現有的DPI無法進行解析，需要編輯新的視頻規(guī)則進行識別。

通過RTMP協議的推流服務器地址，識別推流的“Property”關鍵字中的“tcurl”值，并進行判斷解析，可知道視頻直播業(yè)務類型。如圖5所示，Property‘tcurl’String‘RTMP：//send3.douyu.com：1935/Live’，通過識別tcurl的值，可知其為斗魚直播業(yè)務。

圖5 直播業(yè)務類型識別示意圖

3.1.2 直播業(yè)務參數識別

在主播流程建立完成后，開始進行直播時，在RTMP協議的message消息中，可以看到直播終端視頻中的畫面分辨率、碼率和視頻協議等，音頻中的碼率和采樣率等，直播軟件的名稱和版本號，直播終端的型號和系統(tǒng)版本號等信息。

3.2 直播業(yè)務視頻卡頓分析

直播業(yè)務采用RTMP協議應用在TCP協議層上，結合直播業(yè)務的特性，在全端采集到主播的畫面和語音，迅速上傳到服務器集群，分發(fā)給不同地方的觀眾觀看。因此主播上傳視頻依賴于上行帶寬，當主播網絡環(huán)境差或者上行帶寬不足，會出現數據上傳問題，此時客戶端APP并無提示，主播無感知。由于主播方數據上傳出現問題時，觀看方視頻會出現停滯和卡頓等情況，觀眾體驗較差。

以斗魚直播為例，使用2臺測試手機，其中一臺作為主播，另外一臺作為觀眾，標清模式下測試。通過測試得出的結論為：主播上行速率的最小速率門限值為1 Mbit/s。當速率低于1 Mbit/s時，重傳率急劇增加到10%以上，導致大量重傳，觀眾觀看主播畫面卡頓嚴重。因此，主播業(yè)務的理想速率在1.5 Mbit/s，主播上行速率門限值在1 Mbit/s，重傳率在10%以下（見圖6）。

圖6 實測主播業(yè)務卡頓門限制對比

3.3 基于時間流分片積累算法的直播業(yè)務視頻卡頓

通過現場測試，總結影響直播的主要因素為上行速率和上行重傳率。但是由于直播采用RTMP協議，屬于長連接，在整個直播過程中，僅有從直播開始到直播結束建立的一個鏈接，在某一個時刻或者幾個時刻存在重傳率過高導致速率下降，觀眾視頻畫面出現卡頓問題，但整個長時間的TCP流中，指標上并不能表現出來，需要一種新的方法方式能在重傳率突發(fā)時及時發(fā)現，并發(fā)出預警。

因此設計了TCP流時間分片算法，按照一定時長把TCP流進行分段，把一次直播過程按照一定時間（如5 s，可以根據業(yè)務的不同，可以按需求調整），分成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 結合時間流分片積累算法的直播業(yè)務KPI指標

按照視頻直播業(yè)務信令流程中的各個節(jié)點和各個功能對直播業(yè)務的信令流程性能的影響，建立評估直播業(yè)務的用戶感知的KPI指標（見表2）。

表2 各指標計算方式表

3.5 直播業(yè)務感知評估方法實例驗證

基于斗魚直播進行測試，使用2臺測試手機，其中一臺作為主播，另外一臺作為觀眾，標清模式下測試。當觀看主播出現畫面卡頓時并進行記錄，通過測試一共記錄了9次卡頓現象。對本次測試的主播關鍵指標進行統(tǒng)計，其整體指標良好，上行平均速率為1 201.17 kbit/s，上行重傳率為6.62%，整體指標未達到卡頓門限值，但實際上觀眾觀看時出現了卡頓現象（見表3）。

表3 主播測試各指標KPI值

通過對主播測試用戶信令回放，發(fā)現其中部分時段出現了大量的重傳包，由于重傳包較為集中，短時間內突發(fā)大量的重傳包，導致觀眾畫面停滯，畫面模糊等現象。把主播測試用戶觀看直播的過程，按照時間分片積累算法，由于此業(yè)務為直播業(yè)務中的主播，對實時性要求較高，因此把時間按照秒為單位分段，計算每一個時間分段的速率和重傳率，是否滿足直播對速率和重傳的要求。

本次主播測試用戶直播時長為903.71 s，按照5 s一個分段，共分成了180個段，其中上行速率小于1 000 kbit/s的有8個（見表4），速率無法滿足要求，觀眾出現視頻卡頓的現象，所以卡頓率=8/180=4.44%。

截取重傳率導致視頻卡頓的58、59段分析，看到有連續(xù)的上行RTMP重傳，導致流量急劇下降至0，出現直播視頻畫面停滯現象，持續(xù)了約8 s后才恢復正常。

表4 速率低分段情況

對比統(tǒng)計卡頓次數與實際測試記錄中的卡頓次數發(fā)現，統(tǒng)計卡頓次數與比實際測試記錄少了1次，統(tǒng)計卡頓次數準確率為8/9=88.89%，說明本文的視頻直播感知評估方法是可行的。

4 直播業(yè)務感知評估方法應用

2017年5 月廣西聯通開展直播業(yè)務感知質量提升專項，基于直播業(yè)務感知評估方法，對斗魚直播、虎牙直播、熊貓直播、映客直播等主流直播平臺的用戶感知質量進分析優(yōu)化，共分析排查了3個服務器IP和120個視頻直播質差小區(qū)，平均速率提升10.53%，卡頓率改善1.28%，用戶感知提升顯著。

應用案例：基于直播業(yè)務感知評估方法，對南寧校園區(qū)域的移動視頻直播用戶感知質量進行分析，經統(tǒng)計發(fā)現30466_6969021（GX南寧廣西工商學校_FLTE基站_F_1）小區(qū)下的移動視頻直播用戶存在上行速率過低、卡頓率過高等問題，嚴重影響了觀眾用戶感知（見表5）。

經排查，30466_6969021小區(qū)存在干擾，導致用戶在該小區(qū)上網時，感知較差。對30466_6969021小區(qū)進行優(yōu)化后，干擾消除。優(yōu)化后，該小區(qū)下的移動視頻直播用戶沒有出現上行速率低、卡頓率高的情況，用戶感知得到有效的改善（見表6）。

表5 優(yōu)化前視頻直播流量TOP 5用戶感知指標

表6 優(yōu)化后視頻直播流量TOP 5用戶感知指標

5 結束語

2016年開始直播業(yè)務得到迅速發(fā)展，視頻直播融入了各行各業(yè)。直播不同于傳統(tǒng)的視頻點播業(yè)務，對實時性要求較高，流量緩沖較小，容易產生卡頓，且采用RTMP協議。通過對視頻業(yè)務的研究，總結出視頻直播平臺的識別信令特征，有助于識別用戶使用的視頻直播平臺。基于視頻直播的TCP長連接，無法準確分析整個過程中是否有卡頓現象，通過時間流分片積累算法，可分析直播過程中產生的卡頓現象，有效地評估視頻直播過程中的真實感知情況。