辛永輝，李 楊，林 濤

（中國科學院聲學研究所 北京 100190）

1 引言

當今互聯(lián)網經歷著從面向主機的點到點通信模式到以內容為中心的通信模式的轉變，與內容位置相比，客戶更關心的是內容本身。為了適應互聯(lián)網的這一改變，業(yè)界提出了以ICN（information-centric networking,信息中心網絡）[1]為代表的下一代網絡，該網絡架構中的路由器具有緩存功能，以便后續(xù)為具有相同內容的請求提供服務。

目前多媒體業(yè)務，尤其是視頻業(yè)務在整個互聯(lián)網的數(shù)據(jù)流量中正占據(jù)越來越大的比重。研究顯示，到2016年，視頻內容將占據(jù)全球移動數(shù)據(jù)流量的55%以上[2]?；贖TTP的動態(tài)自適應流媒體 （dynamic adaptive streaming over HTTP，DASH）因具有部署簡單、不受防火墻影響等優(yōu)點而受到廣泛關注[3]。碼率自適應是DASH的重要特點之一，但選擇合適的碼率自適應算法仍然是其研究的熱點和重點。參考文獻[4]提出了一種基于段抵達時間（segmentfetch time）的碼率自適應標準（SFTM），參考文獻[5]也給出了兩階段式的自適應算法，它們都能有效地改善客戶的觀看體驗。但簡單地將傳統(tǒng)的基于端到端的自適應算法移植到ICN中會出現(xiàn)一些問題，如參考文獻[6]中所示DASC（DASH over CCN）。具體來講，ICN的緩存會造成傳統(tǒng)方法對網速的誤判，導致客戶端緩沖區(qū)下溢甚至中斷，需要盡早判斷下載速度提升的原因并及時進行處理。

本文提出了一種基于預估和中斷機制的動態(tài)自適應流媒體算法。該算法在下一片段碼率的選取上，可以使用現(xiàn)有的任何自適應算法，區(qū)別在于若在預估的時間內該碼率的文件沒有下載完成，就意味著碼率過高，應該立即中斷該碼率的下載，并對碼率進行下調，重新發(fā)出下載請求，這樣可以盡早知道是否對網速進行了誤判并進行下一步處理。

2 DASH在ICN應用的問題

本文在現(xiàn)有的ICN傳輸機制[7]的基礎上，通過修改DASH的VLC播放器的插件[8]，添加自適應流媒體算法。這里先簡述ICN的傳輸機制和MPEG-DASH中媒體文件的自適應算法，然后在此基礎上分析傳統(tǒng)自適應算法在ICN應用中出現(xiàn)的問題。

2.1 ICN傳輸機制

ICN架構主要由具有緩存功能的ICN節(jié)點組成，這些節(jié)點也稱為ICN路由器，具有路由和緩存兩大功能，以目前備受關注的內容中心網絡（content centric network，CCN）為例[9]。內容的獲取采用客戶端驅動模式，網絡中主要有兩種數(shù)據(jù)：興趣（Interest）分組以及內容（Data）分組，格式如圖1所示?？蛻粝蜞徑穆酚善鞴?jié)點發(fā)出興趣分組，若該路由器緩存中有對應的內容，則返回內容分組；若沒有緩存，就按照一定的路由機制向外轉發(fā)該興趣分組，若收到數(shù)據(jù)分組則原路返回該數(shù)據(jù)。

圖1 ICN中的數(shù)據(jù)分組類型

2.2 MPEG-DASH基本模型

MPEG-DASH是一個基于HTTP的動態(tài)自適應流媒體標準，具有簡單易用、適應多種網絡環(huán)境、無需特殊代理等優(yōu)點。在實現(xiàn)中，媒體文件被分隔成若干個小片，并根據(jù)需要進行N種格式的編碼，記錄在XML格式的索引文件MPD（media presentation description）中?？蛻魴C要根據(jù)MPD文件向服務器發(fā)出請求，本文假設客戶端均已獲取MPD文件。

（1）MPEG-DASH中客戶機與服務器的交互

分片文件存儲在服務器上，客戶端通過探查網絡可用帶寬并使用HTTP請求最優(yōu)的碼率文件，分片下載完成后，客戶端就可以順序播放。由于分片之間相互獨立，沒有間隔與重疊，故而可以平滑播放。當網絡帶寬動態(tài)變化時，客戶端采用自適應算法調整即將請求的碼率文件來實現(xiàn)“自適應”。DASH客戶端和服務器的簡單交互流程如圖2所示，具體介紹如下。

圖2 DASH客戶端和服務器的簡單交互流程

步驟1客戶端根據(jù)已獲得的MPD文件，發(fā)出對該視頻分片為S1、碼率為R1的請求req1，服務器通過rep1響應給客戶端該文件。

步驟2 客戶端收到rep1后，根據(jù)MPD文件，發(fā)出對分片為S2、碼率為R2的請求req2，服務器做出相應回應。

步驟3 客戶端收到rep2后，繼續(xù)發(fā)出對片段為Sk、碼率為Rk的請求req k，然后收到服務器回復的rep k，如此下去，直至觀看結束或終止。

（2）傳統(tǒng)的自適應算法舉例

Liu Y N等人在參考文獻[6]中實現(xiàn)了MPEG-DASH在CCN中的原型，并采用rate-based自適應策略，即根據(jù)前一片段的下載速度估算整條鏈路的帶寬，再從MPD文件中選取低于該估算帶寬的最大碼率進行下載。

假定分片的時長都為τ，碼率為Rk的片段Sk請求開始的時間為，其中0，下載結束的時間為，則片段Sk的下載速度為片段Sk+1的請求碼率Rk+1為MPD文件的碼率集中低于VRk的最大碼率。為保證較快的啟動時延，第一片的請求碼率為MPD文件中的最低碼率Rmin。

Miller K等人在參考文獻[5]中提出了基于HTTP自適應流媒體的自適應 （adaptation adaptive streaming over HTTP，HAS）算法，該算法分為快速啟動和正常狀態(tài)兩個階段，不同的階段中下一片碼率的選取、開始下載的時延需要根據(jù)最近一段時間t內下載的n個完整片段的平均速度以及當時整個緩沖區(qū)的長度而定。該算法為了保證碼率調節(jié)的穩(wěn)定性，設置了不同的調節(jié)系數(shù) α1,α2,…,α5，以確保穩(wěn)步調節(jié)，減少碼率的變動次數(shù)來提高客戶的視覺體驗。為保證快速啟動，第一片段的請求碼率也是MPD文件中的Rmin。

2.3 問題分析

rate-based自適應策略只是簡單地根據(jù)前一片段文件的下載速度，確定下一片段的請求碼率，該方法能充分利用帶寬，緊跟網絡變化并做出調整，但當中間節(jié)點具有緩存功能時，該算法自然會將緩存節(jié)點的下載網速誤認為整條鏈路的網速，導致發(fā)出對過高碼率片段的請求并長時間等待，這種現(xiàn)象根據(jù)緩存節(jié)點緩存內容的不同發(fā)生的次數(shù)也不同。如圖3所示，假設該視頻的碼率集為R={100 kbit/s,200 kbit/s,300 kbit/s,…,900 kbit/s,1 000 kbit/s}，客戶端到ICN路由器的局域網帶寬為B1=1 000 kbit/s，ICN路由器到視頻服務器的外網帶寬B2=250 kbit/s。

客戶第一次觀看該視頻，請求最小碼率為100 kbit/s的S1，下載時間為1 s，測得的網速為 200 kbit/s，于是請求碼率為200 kbit/s的S2。經過一段足夠長的時間t，ICN路由器會緩存 S1：100 kbit/s、S2～S10：200 kbit/s的文件；客戶第二次觀看時，依然請求100 kbit/s的S1，由于ICN路由器的緩存，客戶端很快收到回復，測得下載速度為1 000 kbit/s，于是請求1 000 kbit/s的S2，但ICN路由器沒有緩存該文件，于是向服務器轉發(fā)，客戶端會在發(fā)出請求后10 s左右完成下載，測得的網速又變?yōu)?00 kbit/s，繼而請求200 kbit/s的S3，如此進行下去。其中，客戶端獲得的碼率一直在200 kbit/s和1 000 kbit/s中跳變，客戶觀看效果很差；同時下載1 000 kbit/s將會耗時10 s左右，這段時間內播放器很可能由于緩沖區(qū)下溢導致播放中斷。

HAS算法使用兩階段法，能較好地對網絡變化做出穩(wěn)步調整，但步驟比較繁瑣，涉及的調節(jié)系數(shù)較多，而且是根據(jù)經驗設定。在快速啟動階段，選擇低碼率快速填充緩沖區(qū)，網速誤判影響較小，但在正常階段，面對有緩存的網絡也暴露出同樣的缺點，對于帶寬誤判只能長時間地等待。如圖4所示，同一個視頻被請求多次后在ICN路由器中可能緩存有多種碼率，當客戶端執(zhí)行HAS自適應策略后，經過一段時間t發(fā)出對1 000 kbit/s片段S10的請求，而ICN路由器緩存的只有900 kbit/s的S10，沒緩存1 000 kbit/s，ICN路由器不得不向外網轉發(fā)，客戶端也因此被迫等待10 s左右，在此期間播放器的緩沖區(qū)有可能因耗盡導致播放中斷。

3 ICN中的動態(tài)自適應算法

3.1 DASC架構和網絡拓撲

本文在DASC系統(tǒng)基礎上提出適用于ICN的自適應流媒體算法[7]。因為ICN還處于研究階段，如果能夠融合DASH應用對于其發(fā)展有重要意義。圖5展示了DASC的架構，其中有陰影的代表原有的DASH模型，無陰影的表示CCN或者ICN部分。

圖3 rate-based自適應策略示例

圖4 HAS自適應算法示例

圖5 DASC的架構

3.2 ICN中的自適應算法

傳統(tǒng)的自適應算法是基于下載的速度來估算當前的網速，在逐跳模式并且具有緩存的ICN中直接照搬極易誤判網絡帶寬，從而引發(fā)一系列問題，為了盡量避免此問題，同時也盡可能地利用網絡資源，提出了ICN中的動態(tài)自適應算法。

為了充分利用信道帶寬并保證客戶觀看視頻的流暢性和高質量，本文提出的自適應算法遵循以下4個原則：

·盡量避免播放中斷；

·在帶寬允許的情況下盡量提供高質量的視頻片段，即平均視頻質量和最小視頻質量盡量大；

·盡量使視頻切換次數(shù)少，因為從客戶體驗出發(fā)，一直保持在低碼率的視頻比在高低碼率間不斷變化的視頻帶來的觀看體驗要好；

·啟動時延要小，即從客戶選擇播放某個視頻到該視頻第一個切片開始播放的時間要盡量短。

在這4個標準中，第1個標準應該具有最高的優(yōu)先級，因為造成客戶體驗最差的是視頻播放的停滯或中斷，也就意味著為了保證客戶端視頻質量的流暢性，在一定程度上可以犧牲視頻的質量。第2個和第3個標準需要進行權衡，充分利用帶寬的最好方法是選擇目前網絡支持的最高碼率的視頻，但在變化的網絡中這會使得視頻的切換次數(shù)大幅增加。同時第2個和第4個標準也需要進行折中，因為要降低啟動時延就要求客戶端下載第一個視頻切片的時間最短，這樣第一次只能請求最低的碼率，在一定程度上造成了帶寬的浪費，最終的判決過程是在這4個標準中權衡選擇。

具體的自適應算法流程如圖6所示，表1對涉及的主要符號進行了說明。

步驟1 開始時t=0，k=1，為保證最小啟動時延，請求第一片段S1的最小碼率R1=Rmin，并等待第S1_R1下載完。

步驟2 下載完Sk后，k=k+1，可以計算出下載的網速根據(jù)某種自適應算法（可以是RB 或者 HAS等）得出 Rk，預估下載 Sk的時間 PTk=α·Rk·τ/V(k-1,n)。

步驟3 發(fā)出對Sk的請求，同時設定倒計時計時器Tck=PTk，Sk下載完成或Tck=0時中斷計時。

步驟4 計時中斷時若Tck>0，說明可以進行下一片段的請求；否則說明未及時得到Sk_Rk，為了防止長時間不必要的等待，需要提前下調待請求Sk的碼率。

步驟5下調Sk的碼率可以分步進行，先下調到較小的 Rk’，然后請求 Sk_Rk’，若 Sk第二次發(fā)生中斷，則需要立即下載到最低碼率Rk=Rmin。

圖6 ICN中動態(tài)自適應算法流程

表1 主要符號

該算法對獲取下一片碼率的算法沒有限制，可以是傳統(tǒng)的任意自適應算法，如rate-based或者HAS，但在后續(xù)過程中新引入了預判中斷機制和分步下調方法。具體如下。

（1）預判中斷機制

當已知前n個片段的下載速度時，可以通過某種自適應算法給出即將下載片段Sk的碼率Rk。這種基于下載的方式估算鏈路帶寬的方法避免不了對網速的誤判，尤其是當網絡中有緩存節(jié)點時。假設算出的下載速度為V(k,n)，根據(jù)自適應算法得到的分片碼率為Rk，已知分片時長τ、片段Sk的預估下載時間。發(fā)出對該碼率的請求后，考慮到網絡的未知性，認為若能在預估時間內下載完成，說明網絡鏈路跟預期接近，否則意味著鏈路狀況比預期的糟糕，或由于網絡中間節(jié)點沒緩存該高碼率片段。為了防止長時間的等待，提前終止該請求并開始對該片段的低碼率文件發(fā)出請求或許更有意義。

（2）分步下調方法

中斷后，應該請求該片段低碼率的文件，但關于較低碼率的設定和下調的次數(shù)沒做具體的限定?？紤]到客戶觀看視頻的連續(xù)性，即客戶看完某個視頻的片段Sk，很有可能也看了片段Sk+1，這樣網絡中緩存片段Sk+1的可能性非常大；同樣考慮到網絡緩存的影響，對于同一個視頻，后請求的客戶觀看的平均質量要比前面的好，在下調片段Sk的碼率Rk時，可以充分利用網絡中可能緩存的多種碼率資源 （沒有Rk，但很可能有比Rk低一個或者兩個等級的碼率Rk′），分步下調碼率，第一次下調為Rk=Rk′，請求下載。若該片段Sk不止一次發(fā)生中斷，為避免播放停滯，應立即下調為Rk=Rmin。

4 仿真結果與分析

本仿真中采用如圖7所示的物理拓撲，分為兩個場景：場景一中內網帶寬為100 Mbit/s，與外網相連的出口帶寬穩(wěn)定在250 kbit/s，用以驗證仿真的可行性；場景二中內網帶寬也為100 Mbit/s，而出口帶寬為一個動態(tài)變化的網絡，用以測試本文提出的算法的準確性。實驗中調節(jié)系數(shù)α=1.5，所采用的視頻片段總數(shù)為300，每個片段默認等時長 τ=2 s，且每個片段均有 200 kbit/s、250 kbit/s、300 kbit/s、400 kbit/s、500 kbit/s共5種碼率供選擇。

圖7 實驗拓撲

場景一：圖8展示了本地節(jié)點沒緩存、有緩存時前兩個客戶的播放碼率。圖9給出了沒有緩存以及有緩存時前8個客戶端的碼率比例。

圖8 DASH/DASC播放碼率對比

圖9 DASH/DASC請求碼率比例對比

對比圖8和圖9，DASH客戶端請求了少量的200 kbit/s和較多的250 kbit/s碼率的片段，而DASC客戶端1請求了部分300 kbit/s碼率的片段，DASC客戶端2請求了部分400 kbit/s和500 kbit/s碼率的片段；而第7個和第8個客戶端請求的幾乎是最高碼率的片段。由于網絡的緩存，后續(xù)的DASC客戶端可以利用鄰近節(jié)點緩存的內容進而突破出口帶寬小的限制。然而后續(xù)的一些客戶端（第2個和第3個）卻請求了較多的低碼率（200 kbit/s）片段，這主要是因為自適應策略對網速進行了誤判，誤以為從緩存節(jié)點下載的速度為客戶端到服務器整條鏈路的網速，導致緩存區(qū)面臨下溢的危險而被迫請求碼率較低的片段。

場景二：本次實驗中，客戶端緩沖區(qū)默認設置3個緩沖區(qū)閾值，當緩沖區(qū)長度小于緩沖區(qū)最小值Buffermin=10 s時，直接請求最低碼率來填充；盡可能地將緩沖區(qū)長度控制在低值Bufferlow=20 s和高值Bufferhigh=50 s之間。動態(tài)網絡的帶寬變化如圖10中粗實線所示，基于已有的HAS算法，本文提出的基于預判機制的自適應算法PHAS中也采用HAS方法，PHAS的客戶1和客戶2的請求碼率在圖10中分別用兩種虛線表示，可見能夠動態(tài)地適應網絡的變化。圖11給出了前8個客戶端請求碼率的比例，由于緩沖區(qū)最小閾值的限制，每次開始請求的一些片段均為低碼率，后續(xù)階段對碼率進行調整。

圖10 動態(tài)網絡中請求碼率的變化

圖11 動態(tài)網絡中不同客戶端請求碼率比例對比

圖12 和圖13給出了HAS和PHAS兩種自適應算法的對比。在圖12的緩沖區(qū)對比中，當出口帶寬降低時，由于時延特性，HAS算法繼續(xù)請求高碼率的片段，由于這些高碼率片段的鄰近節(jié)點沒有緩存，只能將請求轉發(fā)至源服務器獲取，客戶端也只能等待請求的內容回來，盡管在此期間緩沖區(qū)已降到Buffermin附近，隨時有播放中斷的可能；而使用PHAS方法，可以清楚地看到緩沖區(qū)只是降到了Bufferlow附近，大大降低了播放中斷的可能性。圖13中是請求碼率的對比，在出口帶寬降低后，PHAS和HAS都做出了正確的判斷，降低了碼率，但PHAS算法比HAS算法更能充分地利用網絡中緩存的資源，將碼率盡快地調整回去，從而提高了客戶的觀看體驗。

5 結束語

隨著互聯(lián)網視頻、IPTV等業(yè)務的快速發(fā)展，動態(tài)自適應流媒體技術也得到了廣泛研究。本文在現(xiàn)有ICN的基礎上模擬了簡單的MPEG-DASH應用，并通過仿真表明，改進的自適應算法要優(yōu)于傳統(tǒng)的自適應算法，能給客戶更好的觀看體驗。然而在ICN中部署MPEG-DASH存在的問題還有很多，還有很大的研究價值和應用發(fā)展空間，值得進行更深入的研究和應用開發(fā)工作。

圖12 動態(tài)網絡中客戶端緩沖區(qū)的變化

圖13 動態(tài)網絡中客戶端請求碼率的變化

1 Ahlgren B,D’Ambrosio M,Marchisio M,et al.Design considerations for a network of information.Proceedings of the 2008 ACM CoNEXT Conference,Madrid,Spain,2008

2 Cisco.Cisco Visual Networking Index:Forecast and Methodology,2011-2016.Tech Rep,May 2012

3 Sodagar I.The MPEG-DASH standard for multimedia streaming overthe internet.IEEE Computer Society(S1070-986X),2011,4(18):62～67

4 Akhshabi S,Narayanaswamy S,Begen A C,et al.An experimental evaluation of rate-adaptive video players over HTTP.Signal Processing:Image Communication(S0923-5965),2012,4(27):271～287

5 Miller K,Quacchio E,Gennari G,et al.Adaptation algorithm for adaptive streaming over HTTP.Proceedings of 19th International Conference on Packet Video Workshop(PV),Munich-Garching,Germany,2012:173～178

6 Liu Y,Geurts J,Point J C,et al.Dynamic adaptive streaming over CCN:a caching and overhead analysis.Proceedings of 2013 IEEE International Conference on Communications(ICC),Budapest,Hungary,2013:3629～3633

7 Ccnx project v0.6.0.http://www.ccnx.org

8 Müller C,Timmerer C.A VLC media player plugin enabling dynamic adaptive streaming over HTTP.Proceedings of the 19th ACM International Conference on Multimedia,New York,NY,USA,2011:723～726

9 Jacobson V,Smetters D,Thornton J,et al.Networking named content.Proceedings of the 2009 ACM CoNEXT Conference,Toronto,Canada,2009