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



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


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


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


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

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

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