一、前言
 
HTTP ABR (Adaptive Bit Rate)是目前最熱門的OTT (Over-The-Top)傳輸技術，典型的有Apple HLS (HTTP Live Streaming)、Microsoft Smooth Streaming、Adobe Zeri Streaming和DASH (Dynamic Adaptive Streaming over HTTP)。
 
HTTP ABR是以HTTP/TCP協(xié)議進行無損傳輸，且會根據(jù)網絡帶寬自動調整視頻碼率的視頻技術，與傳統(tǒng)的UDP承載或廣電廣播網絡承載的有損傳輸視頻業(yè)務有很大區(qū)別。在網絡性能變化，如路由器擁塞丟包時，傳統(tǒng)的MOS-V等圖像質量指標對于HTTP ABR卻保持不變，失去了指標的意義。因此HTTP ABR業(yè)務需要全新的一套測量體系來進行視頻傳輸質量測量。Spirent針對該業(yè)務所設計的以AS Score為代表的一套指標體系已成為該業(yè)務測量的新標桿，并即將成為IETF標準。
 
二、為什么傳統(tǒng)的IPTV視頻質量分析方法不適用于HTTP ABR業(yè)務？
 
有損傳輸?shù)囊曨l與HTTP ABR視頻對比
 
傳統(tǒng)的網絡視頻IPTV業(yè)務主要是基于UDP承載視頻流的，UDP承載的特點是實時性好，但出現(xiàn)丟包則不會重傳，抖動和時延過大的包會被丟棄，對視頻流而言是一種有損傳輸。所以當網絡損傷出現(xiàn)時，解碼后視頻質量會出現(xiàn)劣化，導致馬賽克、圖像模糊等問題，見下圖1。



　　圖1、UDP承載視頻流出現(xiàn)馬賽克和圖像模糊
 
HTTP ABR視頻業(yè)務是基于TCP承載視頻流的，TCP承載的特點是可靠連接，無損傳輸。丟包后會進行重傳，抖動和延時會被客戶端的下載緩沖所消化，一般情況下客戶不會感知。只有緩沖區(qū)的視頻播放完又沒有及時下載到新的視頻片段時，才會出現(xiàn)畫面等待并緩沖，見下圖2。


　　
　　圖2、TCP承載視頻流
 
傳統(tǒng)的網絡視頻質量分析指標是針對視頻畫面損傷時對視頻質量評估的，而當網絡性能劣化，例如有路由器出現(xiàn)擁塞導致丟包時，HTTP承載的視頻業(yè)務是不會丟失媒體包的，畫面質量跟發(fā)送端是完全一致的，那原有的一些分析指標是否還適用呢？
 
有損傳輸?shù)囊曨l質量常用測量指標是否適用HTTP ABR業(yè)務？
 
基于UDP的IPTV視頻業(yè)務，或廣電廣播網絡的視頻業(yè)務常用于衡量視頻質量的指標常用有如下幾種，Spirent VQA視頻質量測量方案均已支持：
 
MOS-V
 
MOS-V原本是指通過觀測者人眼觀察視頻質量，進行主觀1-5分的打分，參見ITU-T P.910（04/2008）。目前廣泛在視頻質量測試中所使用的MOS-V指標，即通過算法分析客戶端所收到的視頻編碼、幀率、丟包分布、以及圖像組結構等，通過算法換算得出等效于人眼主觀評價測量的MOS-V得分。
 
MOS-V適用于HTTP ABR業(yè)務嗎？
 
只適用于進行實時視頻編碼階段，對于網絡傳輸則失去意義。
 
如前所分析的，ABR業(yè)務采用TCP無損傳輸，已編好碼的視頻流（如H.264碼流）進入網絡（如CDN）后，發(fā)送端發(fā)出的媒體片段和接收端收到的片段是完全一致的。傳輸過程中TCP丟包會重傳，對于視頻流而言即不存在丟包，所以MOS算法所計算的丟包分布是無意義的。即在出現(xiàn)網絡層面的丟包時，對于TCP承載的視頻業(yè)務而言，MOS值是不會改變的。
 
所以MOS在ABR業(yè)務中，充其量只能適用于視頻發(fā)送前進行視頻編碼的階段，即做初步的編碼器編碼質量對比。
 
在某些特殊場合，在傳輸網絡中有實時視頻轉碼的網元情況下，MOS也可用于單獨衡量轉碼設備的編碼質量。但對于HTTP ABR業(yè)務而言，本身就具備提供多種不同的碼率碼流，適應不同的用戶情況，客戶端自動選擇下載碼率，在網絡上再做實時轉碼并不經濟，所以該場景在HTTP ABR業(yè)務中并不常見。
 
要特別指出的是，視頻傳輸質量測量目的是以儀表模擬大量用戶訪問，衡量網絡在大流量情況下的服務質量。而編碼質量則取決于編碼算法，與用戶量或網絡狀態(tài)是無關的。例如VOD業(yè)務，它是編碼軟件離線編碼后，把文件以非實時的方式送入網絡存儲（如CDN），再由網絡向用戶提供服務的。
 
關鍵是，對于運營者最關心的傳輸網絡上各個網元的服務質量，例如出現(xiàn)丟包、抖動、延時等，由于不存在視頻損傷，MOS指標保持不變。即網絡質量變化，用戶感知發(fā)生變化時，MOS指標無法反應，失去了指標的意義。
 
MDI
 
MDI:DF延遲因素指標，指示被測試視頻流的延遲和抖動狀況。DF單位是ms。DF將視頻流抖動的變化換算為對視頻傳輸和解碼設備緩沖的需求。
 
MDI:MLR媒體丟包率指標，網絡傳輸過程中每秒媒體包丟失數(shù)，指示媒體包丟失情況。
 
MDI適用于HTTP ABR業(yè)務嗎？
 
完全不適用。
 
MDI:DF本意是為了指示對解碼設備緩沖的需求，特別是電視機頂盒的緩沖有限，緩沖時間通常是毫秒級的。而對于HTTP ABR業(yè)務而言解碼設備主要是PC和手機等智能終端，它是下載媒體片段的，終端本身就要求有容納大量文件的緩沖空間，緩沖時間起碼是分鐘級。MDI:DF指標失去意義了。
而TCP的重傳機制本身保證了不會有媒體層面的丟包， MDI:MLR必然為0，失去意義。
 
VSTQ
 
視頻服務傳輸質量指標。伴隨MOS而出現(xiàn)的，重點關注網絡傳輸中的視頻質量，對于TCP無損傳輸而言是不適用的。
 
另外還有PSNR峰值信噪比，也是同樣，不再累述。
 
I/B/P幀統(tǒng)計
 
本意是統(tǒng)計在網絡損傷下，視頻編碼的I/B/P幀分別的接收和丟失情況。同樣由于TCP的重傳機制，視頻編碼的I/B/P幀都是100%傳送，不會丟失，統(tǒng)計失去意義。
 
小結
 
傳統(tǒng)的視頻質量分析是基于有損傳輸?shù)模琈OS等指標本意是進行初步的綜合的視頻質量指示，以便做服務質量對比，再進一步做深入的指標分析，例如分析媒體流損傷情況、網絡層丟包、抖動、延時等問題，最終找到影響用戶體驗的原因，并予以解決。
 
但由于HTTP ABR的特殊性，不存在圖像損傷，網絡丟包、抖動、延時等網絡問題都無法影響到MOS指標，而HTTP ABR業(yè)務中，由于網絡損傷而真正影響用戶體驗的主要問題，緩沖等待時間、等待次數(shù)、視頻碼率降低等都無法反應出來。
 
那么HTTP ABR業(yè)務需要怎樣的視頻質量測量體系呢？
 
三、需要怎樣的指標體系來測量HTTP ABR業(yè)務？
 
HTTP ABR視頻傳輸質量測量體系分為三個層面，Spirent測試方案對應給出了測試的方法和指標：
 
用戶感知層面
 
Adaptive Streaming Score
 
Spirent提供了一個綜合評估用戶體驗的，專門針對HTTP ABR設計的指標Adaptive Streaming (AS) score。AS score指示了有多少比例的用戶收到最高速率的碼流，并持續(xù)播放。AS score的范圍是0-100，極端情況下“0” 表示所有用戶都在最低碼率下， “100”表示所有用戶都在服務器能提供的最高碼率下。
 
該指標綜合指示了用戶實際感知：碼率包含了分辨率、幀率、色階、清晰度等圖像細節(jié)信息，而持續(xù)播放與否也反應了網絡和服務器原因導致的延遲、丟包、抖動等傳輸情況。AS反應了用戶在HTTP ABR業(yè)務中的 QoE。該指標便于測試者作為測試分析的入口。也便于將不同的測試結果進行對比。
 
在下圖的例子中，視頻被編碼成多個碼率，最低碼率是64K，最高碼率的1.5M。一開始用戶都集中在64K最低碼率，隨時間推移有更多用戶從低碼率跳到了高碼率的視頻，在播放一分鐘后，所有用戶都在使用1.5Mbps的碼率視頻，對應的Adaptive Streaming Score也從0一直上升到了100。


 
圖3、Adaptive Streaming Score
 
媒體服務層面
 
Adaptive Streaming Buffering Wait Times
 
在線的HTTP ABR媒體流Buffer等待時間，Buffer等待時間是指在這個時間內視頻處于圖像靜止的Loading狀態(tài)。
 
Adaptive Streaming Avg. Fragment Response & Download Time
 
媒體文件片段平均響應時間（從發(fā)出GET到收到第一個數(shù)據(jù)字節(jié)）和下載時間（收到第一個字節(jié)數(shù)據(jù)到最后一個字節(jié)數(shù)據(jù)），統(tǒng)計顯示兩個時間之和，并檢查該文件片段是屬于哪個視頻碼率段的，對該碼率段的所有響應和下載時間取均值。該指標是指示在某個碼率段中文件片段的響應和下載時間。
 
Adaptive Streaming Active Video Channels
 
實時顯示在線的HTTP ABR媒體流在各個碼率段分布情況


 
圖4、HTTP ABR媒體流的碼率分布
 
Fragment Run Statistic
 
Abort Fragment Request下載文件片段中斷次數(shù)
 
Buffer Underrun Fragment用戶等待視頻下載才能播放的次數(shù)，除了用戶剛發(fā)起新的視頻請求播放的之外，在播放過程中該指標在網絡理想情況下應為0，出現(xiàn)額外的Underrun則表示有卡頓。
 
Pre-Cached Fragment 預下載的文件片段數(shù)量
 
Bitrate Shift
 
碼率向上升速的次數(shù)Total Upshifts、碼率向下降速的次數(shù)Total Downshifts、碼率維持不變的次數(shù)Total Rate Maintaining
 
其他統(tǒng)計計數(shù)
　　Sessions、Channels、Http Requests、Manifest Requests、Fragment Requests的計數(shù)統(tǒng)計
 
網絡層面
 
網絡流量、TCP連接統(tǒng)計、TCP SYN/ACK時間統(tǒng)計、Round Trip時間統(tǒng)計、TCP重傳超時統(tǒng)計、TCP收到第一個數(shù)據(jù)包的時間統(tǒng)計、估算服務器響應時間統(tǒng)計、TCP Checksum fail、Bad header length、Bad data length、Duplicate、Out of sequence、Timeout統(tǒng)計等等網絡參數(shù)，以分析網絡層面的抖動、時延、丟包、錯包等各種問題。
 
ABR Scores測量體系正在成為IETF標準
 
Spirent針對HTTP ABR業(yè)務所設計的整套ABR測量指標體系是業(yè)界領先的測量體系，已成為該業(yè)務測量的新標桿，并已提交IETF即將成為IETF標準。
 
注1：Spirent是The Internet Engineering Task Force (IETF 互聯(lián)網工程組)的重要成員，先后制定過很多如RFC 2544等測量領域重要的標準文檔。
 
ITU等標準組織現(xiàn)有的測量標準主要針對的是有損傳輸?shù)膽脠鼍?，目前還沒有針對HTTP ABR這種OTT Internet業(yè)務的已發(fā)布標準。
 
附錄A：HTTP ABR傳輸機制說明

 
圖8、HTTP ABR視頻分發(fā)機制
視頻源內容經編碼器編碼形成不同碼率的視頻文件，一個視頻文件包含了一串文件片段和對應的列表。由客戶端根據(jù)下載的速率情況選擇下載什么碼率的視頻文件。以下以一個文件名為sample的視頻文件在Apple HTTP Live Streaming服務器上播放為例說明其碼率選擇機制。見圖9。

 
圖9、碼率選擇機制
 
客戶端向服務器發(fā)起GET請求獲取sample.m3u8文件列表，服務器回復200 OK并將文件列表發(fā)給客戶端。文件列表包含了sample視頻所能提供的幾種播放碼率。
 
客戶端根據(jù)自身設置的策略決定是先從最小碼率開始，還是從最大，或者從中間碼率開始獲取視頻。本例是設置了從最小碼率開始，于是客戶端向服務器請求64K碼率的文件列表。服務器回復64K碼率視頻的文件串列表。
 
客戶端根據(jù)收到的文件串列表請求獲取第1個文件片段TS文件。
 
到達一定的時間間隔后，客戶端自動計算第一個文件片段的下載速率，得知當前下載速率較高，例如下載速率達到500Kbps，則根據(jù)第一次所獲取的碼率列表，改為向服務器請求256K的文件列表，服務器返回256K碼率視頻的文件串列表。
 
客戶端請求256K文件串列表中的第2個文件片段TS文件
 
再經過一定時間間隔后，客戶端再次計算該文件片段的下載速率，并決定是否改變碼率。
 
注：客戶端參考的標準版本
• Microsoft IIS Smooth Streaming Client 1.1
• Apple HTTP Live Streaming draft-pantos-http-live-streaming-06, IETF
• Adobe Flash Video Specification 10.1