基于主動推送的視頻流優化傳輸算法

汪 靜，丁曉梅，趙麗紅

(安徽文達信息工程學院 計算機工程學院，安徽 合肥 231201)

1 引言

近年來，隨著計算機網絡和移動終端設備的不斷發展，音視頻等多媒體業務在網絡流量中占據的比重也在逐年增長。據思科的調查報告顯示[1]，2019年全世界的流媒體流量占據了互聯網總數據流量的百分之七十五，并在未來將保持持續增長的趨勢。流媒體技術的出現，解決了移動通信技術匯總的帶寬限制問題，大大縮短了多媒體業務的啟動時間，也極大地降低了多媒體業務對客戶端硬件的要求[2]。

與此同時，一些基于HTTP協議的流媒體傳輸協議也得到了迅猛的發展。許多互聯網巨頭公司為了搶占市場先機，也都推出了自己的流媒體傳輸協議，如蘋果公司提出的HLS(HTTP Live Streaming)協議，微軟公司提出的MSS(Microsoft Smooth Streaming)協議，Adobe公司提出的HDS(HTTP Dynamic Streaming)協議等均取得了強烈的反響，但是這些協議只適用于本廠研發的設備和應用軟件，并不具備跨平臺的通用性，極大地影響了流媒體業務的推廣和普及。為此，自2009年起就致力于基于HTTP的流媒體傳輸協議標準研究的國際標準化組織運動圖像專家組(MPEG)，最終與3GPP聯合提出了MPEG-DASH(MPEG Dynamic Adaptive Streaming over HTTP)協議，該協議于2011年底正式被批準為ISO標準，即ISO/IEC 23009-1[3]。

2 相關技術簡介

2.1 HLS協議

HLS協議是蘋果公司推出的一種基于HTTP協議的流媒體傳輸協議[4]，它可以廣泛應用于視頻點播、直播、廣播等場景，但該協議只適用于蘋果公司的IOS系統及相應的設備。HLS協議采用了比較成熟的H.264/AVC編碼技術和TS封裝的視頻流傳輸格式。HLS的系統架構包括服務端、客戶端和內容分發組件三部分。其中服務端主要負責生成內容源，包括視頻流的編碼和視頻流的切片。HLS中的客戶端主要負責向web服務器請求m3u8索引文件和視頻流數據。內容分發組件由若干提供HTTP服務的web服務器組成，主要負責接收客戶端發送的HTTP請求，并對這些請求的視頻切片內容進行響應。

2.2 MSS協議

MSS協議是微軟公司提供的一種基于HTTP協議的流媒體傳輸協議[5]，該協議是基于微軟的Web服務IIS(Internet Information Service)和終端的Silverlight技術實現的。MSS協議與HLS協議不同，其媒體存儲和傳輸格式均為MP4格式，同時在服務端，MSS協議只是將媒體文件進行虛擬切片，即在服務端存儲的還是不同碼率的完整流媒體文件，當客戶端向服務器請求相應的視頻切片時，再將其切割成小的視頻切片進行傳輸。在MSS系統中，Smooth Streaming可以通過web的方式提供高清直播，而Silverlight終端可以根據客戶端的若干特性去選擇合適的碼率，以保證視頻播放的流暢性。MSS協議的整體架構中，服務端必須采用微軟的IIS服務器，而非通用的HTTP服務器，這給MSS的推廣和部署帶來了諸多不便。

2.3 HDS協議

HDS協議是Adobe公司提出的一種基于HTTP的動態碼率自適應的流媒體傳輸協議[6]。HDS協議的系統架構包括內容準備、內容分發、客戶端等三個組件。內容準備組件主要負責視頻流的打包，對于點播業務而言，內容準備組件將FLV格式的視頻流切片，并打包成F4F格式的視頻片段，同時產生包含視頻流切片信息的索引文件。對于直播業務而言，內容準備組件借助Adobe的Flash Media Server媒體服務器，將媒體服務器上的RTMP(Real Time Message Protocol)視頻流進行切片并打包成F4F格式的視頻片段，同時生成F4M格式的索引文件。內容分發組件主要負責將內容準備組件生成的F4F格式的視頻片段和F4M格式的視頻流索引文件部署到相應的Web服務器上，用于后續的網絡傳輸。客戶端組件通過Adobe的Flash播放器或OSMF播放器，將下載好的F4M文件進行解析，根據當前網絡狀態和客戶端狀態，選擇相應碼率的視頻切片，并將下載好的視頻切片進行解碼和播放。

2.4 DASH協議

DASH協議是基于HTTP的動態自適應流媒體傳輸協議[3]，其靈活的結合了HTTP協議漸進式下載的優勢，順應了時代發展的需求。如圖1所示，在DASH系統的服務器端，視頻流被提前編碼為多種碼率的視頻流，同時，這些不同碼率的視頻流被切成固定長度的視頻片段，這些不同碼率、不同片段的視頻片段被存放在HTTP視頻服務器上。在DASH系統的客戶端，ABR算法(碼率自適應算法)根據網絡狀況以及播放器本地緩沖區的特性，請求相應碼率的視頻切片，從而盡可能地提高網絡帶寬的利用率，并保證視頻播放的流暢性。最后這些請求以HTTP Request的方式向服務器請求視頻切片，服務器收到這些請求后以HTTP Response的方式向客戶端響應相應的視頻切片。在客戶端和服務器建立會話連接后，客戶端會首先向服務器請求MPD清單文件，然后將解析MPD清單文件，并根據清單文件的信息和本地網絡、緩沖區等信息，向服務器請求視頻切片。MPD清單文件包含一個或多個連續的視頻片段信息，一個單獨的視頻片段信息包括碼率、幀率、分辨率等信息。

圖1 DASH系統核心架構圖

如圖2所示，視頻流內容被存儲在HTTP服務器上，視頻流在HTTP服務器和DASH客戶端之間通過HTTP1.1協議進行傳輸。其中HTTP服務器上的文件內容包括兩個部分，一部分是MPD清單文件，用于描述視頻片段的碼率、持續時長、URL地址等信息；另一部分是視頻切片，該部分包含了實際的視頻片段數據。一個視頻文件代表一種碼率，每個文件包含若干視頻片段，代表同一種碼率下對應若干固定時長的視頻片段。

圖2 DASH應用場景

在播放過程中，DASH客戶端首先通過HTTP獲取MPD清單文件，通過對MPD文件的解析，可以獲取存儲在服務器上的視頻編碼格式、編碼碼率、切片時長等基本信息，結合對當前網絡帶寬的預測，或對未來播放器中緩沖區占用率的預測選擇合適的碼率，并通過HTTP的GET請求獲取該碼率視頻切片。經過一段時間的緩沖，即客戶端緩沖區中有一定數據量后，客戶端可以應對網絡帶寬的一般性波動，客戶端可以一邊檢測網絡帶寬的波動情況，一邊從服務器下載后續的視頻切片。客戶端根據網絡帶寬的預測、本地緩沖區的占用率等信息，動態地選擇合適的碼率，以維持足夠的客戶端緩存來保證視頻播放的流暢性，同時盡可能地提高視頻的整體碼率，降低視頻塊之間的切換頻率[7]。

3 算法設計

3.1 服務器主動推送

在DASH系統中，不管是點播還是直播場景下，視頻流文件或者攝像機采集到的視頻流都被按照規定的格式分割為MPD索引文件[8]，init.mp4初始分片和一系列m4s格式的連續視頻切片，這些視頻數據都被存放在HTTP服務器上[9]。我們通過本地客戶端播放視頻時，會先輸入MPD清單文件的URL地址，讓播放器首先請求得到MPD清單文件，隨后解析MPD清單文件，并根據ABR算法(動態碼率自適應算法)請求響應碼率的初始分片和后續分片。客戶端在接收到服務端的響應數據后，將視頻分片按照索引順序組織，并在播放模塊解碼播放。整個過程是一個完整的發出請求并收到響應的標準HTTP請求響應過程。這種模式會在視頻啟動的時候獲取索引文件并解析，然后向服務器發送對相應視頻切片的請求，這將會導致較大的延時。同時較大的視頻切片在傳輸過程中會消耗較長的時間，嚴重影響視頻的播放流暢性，較小的視頻切片則會導致單位時間內，客戶端對服務器請求訪問的次數增加，進而導致較長的請求RTT，這也會嚴重影響網絡的傳輸效率。之前的HTTP協議，如HTTP 1.0，HTTP1.1等，在客戶端和服務器之間采用拉(pull)的模式，即客戶端主動向服務器拉取視頻切片。而HTTP2.0作為新一代的HTTP協議標準，其主動推送的特性允許服務器在收到某個視頻切片的請求后，無須等待后續若干視頻切片的客戶端請求而主動推送到客戶端。這種服務器主動推送的模式，可以大大縮減客戶端和服務器之間通過HTTP交互的延時，可以在有限網絡資源的情況下，提高視頻播放的流暢性[10]。

3.2 基于緩沖區的動態碼率推送算法

在DASH系統中，本地播放器的緩沖區滿溢程度可以間接反映網絡狀況的實時波動情況，當網絡狀況較差時，本地播放器的緩沖區中數據量較小，當網絡狀況較好時，本地播放器的緩沖區中數據量較大。在DASH的一個推送周期內，播放器會收到若干視頻切片。在這個周期內，獲取網絡帶寬的實時波動情況非常復雜，但是本地緩沖區的滿溢程度可以輕松獲取，因此我們可以考慮通過本地播放器的緩沖區滿溢程度動態調整主動推送的過程。如圖3所示，我們將播放器的緩沖區劃分為如下階段：BufMin階段，BufLow階段，BufHigh階段，BufMax階段。服務器根據本地緩沖區中的數據量處于不同的階段，進而執行不同的主動推送策略。播放器的緩沖區類似于一個隊列，下載好的視頻切片從左邊進入緩沖區隊列，而待播放的視頻切片從右邊解碼并出隊列[11-12]。

圖3 本地客戶端緩沖區模型

當客戶端向服務器請求第i個視頻切片時，服務器在響應第i個視頻切片的同時會主動推送k-1個視頻切片，即客戶端發送一個請求，總共收到k個視頻切片。整個推送的邏輯功能位于服務器端，當推送的視頻切片數量k較小時，客戶端和服務器交互的次數沒有明顯的減少。當推送的視頻切片數量k較大時，單個推送周期會持續較長的時間，在這期間，網絡狀況和本地播放器的緩沖區可能發生較大的變化，因此，需要根據上述指標，動態調整主動推送的視頻切片質量，避免播放器緩沖區中的數據量耗盡，造成播放中斷。

pushBR(ci)=

(1)

主動推送過程中，動態調整視頻切片質量的邏輯如公式(1)所示，pushBR(ci)代表主動推送的第i個視頻切片的碼率，其中第一個被主動推送的視頻切片碼率為客戶端請求的視頻切片碼率，后續視頻切片的碼率均由上述邏輯判斷，buf代表播放器緩沖區中當前的緩沖滿溢度，以時間為計量單位。

若當前的緩沖滿溢度低于BufMin，說明當前播放器緩沖區的數據量過小，處于數據量耗盡的危險區，有較高的rebuffer風險，為了避免視頻播放過程中的卡頓現象，服務器將主動推送的視頻切片碼率調整為當前索引位置視頻切片的最小碼率minBR，以便盡快填充播放器緩沖區的數據量。

若當前的緩沖滿溢度位于BufMin和BufLow之間時，說明當前播放器緩沖區的數據量較小，服務器將主動推送的視頻切片碼率調整為上一個視頻切片碼率的一半。

若當前的緩沖滿溢度位于BufLow和BufHigh之間時，說明當前播放器緩沖區的數據量正常，服務器將主動推送的視頻切片碼率調整為與上一個視頻切片碼率一致，這樣的調整可以降低視頻切片之間的碼率切換值，進而提升用戶的觀影體驗。

若當前的緩沖滿溢度大于BufHigh時，說明當前播放器緩沖區的數據量較大，視頻rebuffer風險較小，可以考慮適當提高待推送視頻切片的碼率，從而提高視頻的整體碼率水平及用戶的觀影體驗。

4 實驗評估

本實驗使用了由JavaScript開發的開源播放器dash.js，其中動態碼率自適應算法在ABRRulesCollection.js文件中，實驗通過ThroughputRule模塊統計過去五個視頻切片的下載參數來預估未來一個視頻切片在下載時的網絡狀況，進而選擇低于該網絡吞吐量的最大碼率。實驗通過InsufficientBufferRule模塊來計算播放器緩沖區的緩沖滿溢度，當緩沖滿溢度較低時，播放器保守的請求低碼率視頻切片，以快速填充緩沖區；當緩沖區滿溢度較高時，播放器激進的請求高碼率視頻切片，以提高視頻流的整體碼率。同時AbandonRequestRule模塊可以在視頻切片下載過程中不斷預估其最終下載完成時間，若預估的下載時間超過播放其對應的播放進度，即代表播放器有卡頓的風險，此時播放器應主動放棄該視頻切片的下載，取而代之的是更低碼率的視頻切片[13]。最后，在接收來自服務器主動推送的視頻切片時，實時監測播放器當前緩沖區的滿溢程度，利用動態推送調整算法不斷修正后續視頻切片的碼率。

當視頻切片的時間較短，代表著當前視頻切片包含的數據量較小，即網絡中傳輸的速度更快，可以更加靈活地適應網絡的動態變化。但是過小的視頻切片會導致視頻客戶端和服務器之間的請求數激增，這在多客戶端場景下尤為明顯，嚴重時會導致服務器宕機。而服務器主動推送可以很好地解決此類問題，在該部分，我們比較了傳統的請求響應模型中的請求數目和服務器主動推送(k-push，其中k=4)的請求數目，如圖4所示，可以看到服務器主動推送模型的請求數目隨時間沒有明顯的變化，而傳統的請求響應模型的請求數目隨時間有線性增長的趨勢。

圖4 請求響應模型和服務器主動推送模型的請求數

在上述實驗條件的基礎上，我們測試了服務器主動推送算法對不同視頻切片時長的性能影響。如圖5所示，與傳統的請求響應模型相比，服務器主動推送模型的傳輸延時分別縮短了42.24%、50.63%、46.24%和58.48%，可見服務器主動推送模型可明顯縮短傳輸時延。

圖5 服務器主動推送算法對不同切片時長的性能影響

5 結論

人們對觀看網絡視頻質量的要求在日益提升，希望獲得高質量、低切換、不卡頓的觀影體驗。為此，文章分析了當前主流碼率自適應算法對用戶觀影體驗的影響，并將HTTP2.0的主動推送功能與DASH技術相結合，提出了一種全新的基于主動推送的視頻流優化傳輸算法。該算法根據播放器中緩沖區占用率的反饋信息，為k個視頻塊選擇合適的碼率，并將k個視頻塊主動推送給客戶端。經過本地的模擬實驗以及真實環境的實驗，可以看出本文提出的基于主動推送的視頻流優化傳輸算法可以明顯減少客戶端與服務器之間的交互次數，對于那些要求低延時的直播場景，該算法具有明顯的提升。