原文鏈接：A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP | IEEE Journals & Magazine | IEEE Xplore

主題：基于HTTP的視頻碼率自適應方案綜述

注：由于原文內容過長，省略了大部分背景內容，重點保留文章中對于各種ABR方案的介紹和評價。

以下為正文筆記，大部分為翻譯或總結。

---

目錄

I. INTRODUCTION

II.?BACKGROUND AND DEFINITIONS

A. Video Coding Standards

B. Common Problems in HTTP Adaptive Streaming

1) Multi-Client Competition/Stability Issues

2) Consistent-Quality Streaming

3) QoE Optimization and Measurement

4) Inter-Destination Multimedia Synchronization

III. BITRATE ADAPTATION SCHEMES

A. Client-Based Adaptation

1) Available Bandwidth-Based Adaptation

2) Playback Buffer-Based Adaptation

3) Proprietary Solutions

4) Mixed Adaptation

5) MDP-Based Adaptation

B. Server-Based Adaptation

C. Network-Assisted Adaptation

D. Hybrid Adaptation

1) SDN-Based Adaptation

2) Server and Network-Assisted Adaptation

IV. COMPARISON BETWEEN BITRATE ADAPTATION SCHEMES

---

I. INTRODUCTION

HAS：HTTP adaptive streaming

非HAS的視頻播放架構：由Media server主動push，在server端實現ABR，增大了server的復雜度和運算壓力

HAS：由client向HTTP server主動pull，在client端實現分布式ABR

Multiple versions (also called representations) of each segment：碼率/分辨率/質量

HAS的優勢：

• HTTP簡化了穿越NAT和防火墻的實現

• 可以利用傳統的Web server及網絡緩存（如CDN）

• clinet端維護播放會話狀態，server端不需要維護任何狀態，因此client可以從不同server下載視頻且不會影響系統的擴展性

• clinet與server間不需要持久連接，提高了系統的可擴展性，且降低了實現和部署開銷

HAS的例子：

• 微軟：MSS（Smooth Streaming）

• 蘋果：HLS（HTTP Live Streaming）

• Adobe：HDS（HTTP Dynamic Streaming）、OSMF（Open Source Media Framework）

• Akamai：HD

DASH：MPEG和3GPP共同制定的標準（未規定ABR，允許第三方實現）

MPD：Media Presentation Description，MPD是一個XML文檔，它為服務器上的可用媒體段提供索引

基于JS的DASH客戶端：

• dash.js：DASH工業論壇推薦

• DASH-JS

之前survey（A Survey of Rate Adaptation Techniques for Dynamic Adaptive Streaming Over HTTP）的分類：

• client-side

  • DB

  • RB

  • Hybrid/Control Theory-Based

• server-side

• in-network

本文與之前survey的區別：

• 不同機制的分類方式（基于ABR邏輯的獨特特征）

• 更多ABR機制以及比較

ABR方法分類（基于ABR邏輯在系統中的位置，以及涉及哪些entities）：

• client-side

• server-side

• network-assisted

• hybrid

II.?BACKGROUND AND DEFINITIONS

A. Video Coding Standards

最常用的視頻編碼格式：H.264（MPEG-4 Advanced Video Coding (AVC)）

每個視頻段從intra/key幀開始

SVC（Scalable）：AVC的擴展，允許將視頻流分成多個比特流或層

通常將視頻分為三個質量維度：【注：這里不是很懂】

• 時間（temporal）：幀速率（frame rate）。視頻以給定分辨率的多個幀速率進行編碼。 基礎（base）層具有最低的幀速率，而增強（enhancement）層增加幀速率，這逐漸提高了質量

• 空間（spatial）：分辨率（resolution）。對于給定的幀速率，視頻以多個空間分辨率進行編碼

• 質量/信噪比（quality/Signal-to-Noise Ratio, SNR）：視頻以單個空間分辨率編碼，并且增強層改善質量，保持分辨率恒定

H.265（High Efficiency Video Coding (HEVC)）：提供幾乎兩倍于AVC的編碼效率

SHVC：HEVC的擴展

VVC：兩倍于HEVC的編碼效率，專門針對使用沉浸式和高動態范圍（HDR）視頻的應用和服務，預計2020年推出標準

B. Common Problems in HTTP Adaptive Streaming

影響HAS系統的四個主要問題：

• 多客戶端的競爭和穩定性問題

• 恒定質量的流

• QoE優化與衡量

• 目的地間多媒體同步

1) Multi-Client Competition/Stability Issues

集中管理控制器的HAS系統有三個目標：

• Stability/穩定性：避免頻繁的碼率切換

• Fairness/公平性：競爭可用帶寬的多個HAS客戶端應根據viewer-，content-和設備特征平等地共享網絡資源。 這里所需的公平性通常不會導致帶寬公平

• High Utilization/高利用率：盡可能高效地利用網絡資源

一個流session一般由兩種狀態組成：

• buffer-filling state：填充buffer使其達到可以開始或恢復播放的特定閾值

• steady state：在帶寬波動或中斷時，仍能讓buffer保持在最小閾值以上，以避免buffer為空或播放停止

  • ON：下載當前視頻段，記錄吞吐量

  • OFF：空閑

ON的重疊情況不同，可能會引起客戶端高估可用帶寬，進而可能引起視頻不穩定、質量震蕩、碼率切換、buffer耗盡、不公平、帶寬利用不充分等問題，統稱為HAS的穩定性問題

2) Consistent-Quality Streaming

研究表明，視頻碼率與感覺到的視頻質量呈非線性相關，且視頻內容類型（運動快慢）對視頻質量也有影響

3) QoE Optimization and Measurement

影響QoE的因素：

• perceptual（用戶直接感知）：視頻圖像質量，啟動延遲，rebuffering時間，卡頓頻率，質量切換的程度和頻率

• technical：算法，參數，硬件/軟件

視頻流的一個主要挑戰是缺乏統一的量化方法來衡量QoE

三個metric：

• 目標metric

• 主觀metric

• QoS衍生的metric

4) Inter-Destination Multimedia Synchronization

（略）

III. BITRATE ADAPTATION SCHEMES

A. Client-Based Adaptation

目標：

• (i) minimal rebuffering events when the playback buffer depletes

• (ii) minimal startup delay especially in case of live video streaming

• (iii) a high overall playback bitrate level with respect to network resources

• (iv) minimal video quality oscillations, which occur due to frequent switching.

五類：

• (1) available bandwidth-based

• (2) playback buffer-based

• (3) proprietary solutions

• (4) mixed

• (5) Markov Decision Process (MDP)-based

1) Available Bandwidth-Based Adaptation

• [51] Rate adaptation for adaptive HTTP streaming（MMSys'11）：使用基于SFT（塊獲取時間，從發送HTTP GET請求開始到接收到塊的最后一個字節結束）的平滑吞吐量

• [52] Rate adaptation for dynamic adaptive streaming over HTTP in content distribution network（Elsevier SPIC'12）：[51]的擴展，通過使用一個比較ESFT（預期SFT）和SFT的度量，確定選定的碼率是否與網絡容量相匹配，在CDN中引入串行和并行的段獲取方法

• [14] A seamless Web integration of adaptive HTTP streaming（EUSIPCO'12）：使用上一視頻段的碼率和之前估計的吞吐量來計算下一視頻段的估計帶寬。初始化基于下載MPD時測量的帶寬

• [53] PANDA（IEEE JSAC'14）：準確估計可用帶寬，并試圖解決穩定狀態下共享瓶頸鏈路的多客戶端的ON-OFF異步產生的碼率震蕩問題

• [54] piStream（MobiCom'15）：LTE場景，使客戶端能夠根據資源監視器模塊（物理層daemon）估計可用帶寬

• [55] Quality selection for dynamic adaptive streaming over HTTP with scalable video coding（MMSys'12）：通過使用基于帶寬傾斜（bandwidth-sloping）的啟發式算法，預取未來視頻塊的base層或為已有視頻塊下載enhancement層，將SVC整合入DASH

• [56] DASH2M（MM'16）：直播場景，為使用HTTP/2服務器推送和流終止屬性的移動流客戶端設計，旨在提高QoE并減少客戶端的電池消耗

• [57]?Low latency live video streaming over HTTP 2.0（NOSSDAV'14）：自適應k-push方案，根據帶寬增加/減少來增加/減少k，同時記錄推送周期中的總功耗

• [58] LOLYPOP（ACM?TOMCCAP'16）：直播場景，基于低延遲預測的ABR，在無線鏈路上，利用多個時間尺度（即1到10秒）上的TCP吞吐量預測來降低時延并改善QoE

• [59]?GTube（MMSys'14）

• [60]?A comparison of quality scheduling in commercial adaptive HTTP streaming solutions on a 3G network（MoVid'12）

• [61]?Improving QoS in high-speed mobility using bandwidth maps（IEEE TMC'12）

• [62]?Empirical evaluation of HTTP adaptive streaming under vehicular mobility（NETWORKING'11）

• [63]?Predictive buffering for streaming video in 3G networks（WoWMoM'12）

• [64]?GeoStream（MM'16）

[59]-[64]：運動中的移動客戶端

• [59]-[63]：在真實的移動網絡中部署帶寬查找服務，以指導移動客戶端之間的帶寬估計。不足：從帶寬波動的空間角度入手，很少關注時間因素

• [64]：利用了帶寬波動的時間因素，使用地質統計學來估計未知位置的未來帶寬

【缺點：由于缺乏可靠的帶寬估計方法，該類算法取得的QoE相對較差】

2) Playback Buffer-Based Adaptation

• [65]?Oscillation compensating dynamic adaptive streaming over HTTP（ICME'15）：將buffer大小與客戶端metric工具集相結合，以實現準確的碼率選擇和平滑切換

• [66] BBA（SIGCOMM'14）：目標是最大化平均視頻質量并避免不必要的rebuffering。缺點：在長期帶寬波動時，QoE會發生下降

• [67] BOLA（INFOCOM'16）：將ABR視為效用最大化問題，將平均播放質量和rebuffering時間視為QoE的兩大指標，從理論上證明了其近似最優。該算法已在dash.js中實現

• [68] BIEB（IM'13）：基于SVC優先級最大化視頻質量，同時減少質量振幅，避免stall和頻繁的碼率切換。BIEB在提高視頻質量（增強層）之前保持穩定的buffer。不足：在網絡中出現動態交叉流量的高峰時間內，沒有在QoE模型中考慮碼率改變或stall的情形

• [69]?QUETRA（MM'17）：將DASH客戶端公式化為M/D/1/K隊列，可以在給定碼率、網絡吞吐量、buffer容量時計算預期buffer占用率

• [70]?SVC-based HTTP adaptive streaming（Bell Labs Technical Journal’12）

【限制：較低的總體QoE&不穩定性問題（尤其是在長期帶寬波動的情況下）】

基于SVC的方法的限制：SVC編碼和解碼的復雜性，處理資源和開銷

[70]：嘗試使用多個SVC流，使用少量增強層的分層編碼和編碼開銷

3) Proprietary Solutions

• [8] MSS（Microsoft'08）：周期性檢測網絡情況以避免帶寬波動，使用可用帶寬、播放窗口分辨率、客戶端CPU負載作為ABR的決策metric。MSS為每個流會話建立兩個TCP連接，分別用于傳送視頻和音頻，兩個連接可以根據條件進行交換。用于北京2008年奧運會的直播中

• [9][72] HLS（Apple'15）：直播&點播（Video on Demand）場景，重點針對移動端，使用網絡吞吐量、設備性能（如CPU、分辨率、內存等）做出碼率決策。可以同時請求多個視頻段，且提供了一個媒體加密的靈活框架。現用于iOS和macOS的Safari、win10的Edge和Android 3.0+中

• [10] OSMF（Adobe'15）：免費開源軟件，適用于直播&點播，使用可用帶寬及設備處理性能進行ABR決策，支持漸進式下載、串行及并行視頻組合，目標是(1)簡化播放器開發；(2)為渲染、廣告、報告提供一系列第三方服務；(3)簡化第三方開發。

【總結：以上算法在單客戶端面對帶寬波動時較為有效。但是，多客戶端競爭瓶頸鏈路時會產生穩定性問題。】

• 啟發式ABR算法僅能做出次優決策，因為它們無法迅速適應快速的網絡變化

• 在某些情形下，它們不能確保公平的觀看體驗

• MSS相對其他兩種表現最優，因為它可以獲得最高的播放碼率，只產生少量的碼率切換

• 基于標準功能和特性，與這些專有格式相比，DASH提供了幾乎所有功能

4) Mixed Adaptation

使用組合metric進行決策，包括帶寬、buffer占用、視頻段大小、視頻段持續時間

• [81] MPC（SIGCOMM'15）：提出了一個控制論框架，使用模型預測控制（MPC），將帶寬預測和buffer大小預測最優地結合起來

• [82]?A control-theoretic approach to rate adaptation for dynamic HTTP streaming（VCIP'12）：與[81]類似

• [32]?Streaming video over HTTP with consistent quality（MMSys'14）：將ABR公式化為優化問題

• [83]?A video bitrate adaptation and prediction mechanism for HTTP adaptive streaming（TOMM'17）：使用模糊邏輯（fuzzy logic）機制

• [84]?ELASTIC（PV'13）：基于反饋控制理論，生成long-lived TCP流，避免ON-OFF穩態時的帶寬高估問題。用于確保帶寬公平性，但是不考慮QoE

• [86]?Adaptation algorithm for adaptive streaming over HTTP（PV'12）：使用當前buffer占用水平、估計可用帶寬、所有碼率級別的平均碼率作為ABR決策metric。目標：(1)準確估計可用帶寬，避免帶寬高估；(2)最大化碼率，同時最小化啟動延遲、stall次數、視頻質量波動及播放中斷。可以提高多個競爭客戶端的公平性，但不考慮QoE

• [87]?FESTIVE（CoNext'12）：包含(1)帶寬估計模塊；(2)碼率選擇和更新方法；(3)。目標：提高效率、公平性和穩定性

• [88] TFDASH（IEEE?TCSVT'17）：利用基于對數性增加乘性減少（LIMD，logarithmic-increase-multiplicative-decrease）的帶寬探測算法來估計可用帶寬，使用估計可用帶寬及雙閾值buffer來做出ABR決策

• [89]?Towards agile and smooth video adaptation in dynamic HTTP streaming（CoNext'12）：利用支持向量回歸（SVR）估計可用帶寬，使用buffer中的視頻時間作為反饋信號，根據估計可用帶寬進行ABR決策。目標：平衡單個/多個CDN場景下的DASH帶寬利用和平滑度

• [91] SQUAD（MMSys'16）：使用可用帶寬和buffer提高視頻的平均碼率，同時最小化碼率切換次數。啟動階段，使用保守方法選擇更多低質量的視頻段；之后，使用頻譜（平均段碼率的變化）和buffer選擇下一個視頻段的碼率

• [92]?Receiver driven rate adaptation for wireless multimedia applications（MMSys'12）：適用于無線網絡的多路徑ABR，通過在應用層實現類似邏輯避免TCP擁塞。相對單個TCP流，并行TCP流已被證明可以提高吞吐量，但會產生額外的請求/響應開銷，還需要修改應用棧

• [93] SARA（ICCW'15）：基于視頻段大小變化、可用帶寬估計（使用視頻段大小估計）、buffer進行決策。在HTTP中，吞吐量取決于文件大小，因此SARA在MPD文件中加入了每個視頻段的大小

• [94]?ABMA+（MMSys'16）：基于估計的視頻rebuffering概率選擇最高碼率。利用buffer maps，它定義了在某些條件下滿足rebuffering閾值并避免繁重在線計算所需的buffer容量

• [95]?GTA（MMSys'18）：基于博弈論，使用合作博弈（cooperative game），將ABR公式化為議價過程（bargaining process）和共識機制（consensus mechanism），因此客戶端之間可以建立協議并實現它們的QoE目標

[81]-[83]：僅考慮單客戶端場景，不考慮多客戶端競爭可用帶寬時的公平性和內容類型/屬性

[93]-[95]：包含更多的決策指標，比如當前視頻段的質量、大小、下載時間

5) MDP-Based Adaptation

在基于馬爾可夫決策過程（MDP）的ABR中，視頻流過程被形式化為有限MDP

• [97]?A real-time adaptive algorithm for video streaming over multiple wireless access networks（IEEE JSAC'14）：多接入網絡上的實時最佳動作搜索算法。使用藍牙和WiFi同時下載視頻段，輸入為buffer、SVC層index、藍牙流量、可用帶寬及每個視頻段的index。獎勵函數（reward function）包括平均播放質量、中斷率、播放平滑度。不足：用戶移動場景

• [98]?Optimizing HTTPbased adaptive streaming in vehicular environment using Markov decision process（IEEE?TMM'15）：解決用戶移動性問題，將ABR建模為車輛環境中的MDP問題，引入了基于強化學習（RL）的三種變體算法，利用歷史帶寬樣本構建精確的帶寬估計模型

• [99]?A multi-agent Q-learning-based framework for achieving fairness in HTTP adaptive streaming（NOMS'14）：解決多個客戶端在瓶頸鏈路上競爭時的QoE和公平性問題。基于多agent的RL，使用中央管理器收集QoE統計數據（段碼率）和協調競爭客戶端，確保各客戶端的QoE公平并提高QoE。不足：不考慮stall和質量切換

• [100]?Online learning adaptation strategy for DASH clients（MMSys'16）：基于MDP的在線ABR算法，目標是最大化長期預期reward（QoE），獎勵函數通過視頻段質量、質量震蕩、客戶端經歷的stall計算。使用RL進行決策，利用并行技術以避免RL的緩慢收斂和次優解

• [101]?mDASH（IEEE?TMM'16）：將ABR邏輯公式化為MDP優化問題，將buffer大小、帶寬條件、碼率穩定性視作馬爾可夫狀態變量，提出了一種低復雜度的貪婪次優算法

• [102] Pensieve（SIGCOMM'17）：基于A3C，不需要依賴對環境的預編程模型或者假設，而是從觀察和經驗中學習最佳策略

• [103]?D-DASH（IEEE Transactions on Cognitive Communications and Networking‘17）：結合深度學習與強化學習（Deep Q-Learning），使用混合學習架構（包括具有高級策略的前饋和循環神經網絡RNN），實現了決策過程中策略最優性和收斂速度之間的良好平衡

[102]-[103]：基于深度強化學習，展示了將DRL和ABR啟發式*方法結合的優勢。不足：當客戶端數量增加時，可能會受到不穩定性、不公平、不充分利用（帶寬）的影響。

*注：原文為“heuristics”，猜測意思是ABR決策使用的metrics，不知道此處怎么翻譯比較好

B. Server-Based Adaptation

在server端使用碼率整形方法，不需要client端的任何協作。碼率切換由碼率整形器隱式控制，客戶端仍可以做出碼率決策，但最終決策或多或少地取決于服務器上的整形方法。

• [106]?Server-based traffic shaping for stabilizing oscillating adaptive streaming players（NOSSDAV'13）

• [107]?Shaping HTTP adaptive streams for a better user experience（MMSys'12）

• [108]?Tracker-assisted rate adaptation for MPEG DASH live streaming（INFOCOM'16）：直播場景，存在網絡cache時的跟蹤器輔助（tracker-assisted）ABR，由多個客戶端（通過共享代理與服務器通信）和一個服務器（具有管理客戶端狀態的跟蹤器功能）組成，需要修改MPD

• [109]?Feedback control for adaptive live video streaming（MMSys'11）：基于反饋控制理論，旨在保持每個播放器的buffer盡可能穩定，并使碼率決策與可用帶寬相匹配。目標：通過控制服務器發送buffer大小，為每個DASH播放器調整和選擇最合適的碼率

• [110]?MS-stream（CNCC'17）：用于提高QoE的多源ABR，其中客戶端從多個MS-Stream中獲取視頻段

[106]-[107]：分析多個HAS客戶端競爭可用帶寬時的不穩定性和不公平性問題，提出了一種流量整形方法，可以在家庭網關中部署，以優化公平性、穩定性、收斂延遲[107]，并消除穩定狀態下的OFF時期（引起不穩定性問題的根源）[106]

【不足：增加了服務器端的開銷和復雜度（尤其是客戶端數量增加時）。部分方案還需要修改MPD或特定的服務器軟件，這可能違反DASH標準設計原則。】

解決方法：服務器+網絡輔助（[16] [111]），見III-D2

C. Network-Assisted Adaptation

通過收集網絡測量信息并通知客戶端選擇合適的碼率，網絡輔助方法允許客戶端考慮ABR過程中的網內（in-network）決策

• [112] QDASH（MMSys'12）：QDASH是客戶端與服務器間的代理，包括一個QDASH-abw模塊（用于測量帶寬）和一個QDASH-qoe模塊。通過使用集成的中間級別（integrated intermediate levels）來保證碼率級別的逐漸變化，進而提高QoE。不足：在網絡中產生大量開銷（尤其是客戶端數量增加時），可能導致網絡擁塞，從而降低QoE

• [113]?QoE-driven in-network optimization for adaptive video streaming based on packet sampling measurements（Elsevier CN'15）：QoE驅動的網內優化系統，解決了多個DASH客戶端競爭可用帶寬的問題。系統由一組沿著客戶端與服務器之間的路徑部署的agent組成，這些agent均為代理（proxy），使用packet采樣技術定期測量可用帶寬，并通過解優化問題做出碼率決策，最終將碼率決策發給客戶端。不足：可能會產生大量開銷，且無法應對agent失效

• [114]?BUFFEST（MMSys'17）：BUFFEST是一個從HTTP/HTTPS流量中預測客戶端buffer狀況的分類框架，由基于事件的buffer模擬器（負責準確跟蹤/預測客戶端的buffer狀況）和自動訓練的在線分類器（負責TCP/IP數據包級的流量分類）組成

• [116]?Price-based controller for utility-aware HTTP adaptive streaming（IEEE MultiMedia‘17）：受[115] NUM（IEEE JSAC'06）的啟發，是一個基于分布式價格的網絡輔助HAS系統，用于共享瓶頸的多個并發HAS客戶端。受擁塞控制算法的啟發引入了價格定義（一個關于視頻段下載時間的函數），中央協調器使用價格信息協助客戶端做出決策，以最大限度地提高整體用戶滿意度和QoE公平性

• [117]?FINEAS（ACM TOMCCAP’16）：QoE驅動的網內ABR，目標：減輕開銷，解決多客戶端的公平性問題。使用網內組件（如代理）提供網絡狀況（可用帶寬等）的信息并給出碼率建議，客戶端可以基于建議做出碼率選擇。不足：盡管在同類系統中表現良好，但在現實世界中存在大量異構設備，可能會導致不同設備的QoE不同

• [118] NOVA（INFOCOM'14）：將多客戶端競爭問題公式化為受buffer、網絡狀況、傳遞開銷（delivery cost）約束的優化問題，為每個客戶端選擇最優碼率。包含帶寬分配和質量自適應兩個主要元素。不足：雖然相對于DASH實現了良好的QoE，但其效率依賴于強大的統計假設（如靜態遍歷性stationary ergodicity），可能會對收斂世界產生影響

• [120] AVIS（MobiCom‘13）：蜂窩網絡場景，基于網絡的radio資源分配框架，為每個客戶端最優地分配資源（將DASH流與其他流分開）并確保它們之間的公平性和穩定性，同時保持高資源利用率

• [121]?Quality-of-experience driven adaptive HTTP media delivery（IEEE ICC’13）：蜂窩網絡場景，QoE優化器和資源管理框架，在無線信道狀況、buffer、可實現的QoE的約束下動態尋找最優碼率。基于每個客戶端的QoE為其分配可用帶寬【[120][122]是均分帶寬，但由于設備本身的性能差異，不是所有設備都能取得好的播放體驗】

• [122]?Modeling stability and bitrate of network-assisted HTTP adaptive streaming players（ITC'15）：蜂窩網絡場景，在網關上安裝HTTP代理，均勻分配客戶端之間的可用帶寬。若客戶端請求的碼率比代理指定的碼率高，則代理會重寫客戶端請求【相當于不讓客戶端請求的碼率超過代理指定碼率】，并會在響應中添加HTTP頭部通知客戶端。將流過程建模為MDP，其中每個狀態表示活動的客戶端數量，狀態間的切換與播放器的啟動和停止相關聯。出于對穩定性的考慮，switches的數量與MDP的狀態轉移頻率有關

• [123] RAGA（ICC'14）：蜂窩網絡場景，跨層buffer感知無線資源分配算法，僅使用buffer（level and rate of level changes）做出ABR決策

• [124]?Video-QoE aware resource management at network core（Globecom‘14）：蜂窩網絡場景，由網絡核心的視頻感知控制器（VAC，Video Aware Controller）組成，VAC作為中央智能單元，將視頻質量、buffer級別轉換為QoS參數。根據從反饋中獲得的buffer級別，為每個客戶端計算動態最大碼率

• [125] MP-DASH（CoNEXT'16）：蜂窩網絡場景，能夠感知客戶端網絡接口設置的多路徑框架，旨在改善MPTCP以支持DASH（考慮用戶網絡接口設置），從而在不降低QoE的情況下提高視頻傳輸的效率。由MP-DASH調度器和視頻適配器組成，調度器基于用戶接口設置、視頻段大小、視頻段傳遞時間在多路徑中選擇獲取視頻段的最佳路徑，視頻適配器是現有client-based方案的多路徑友好的附加組件，負責ABR方案與調度器間的交互

• [126] Prius（IEEE?TCSVT’17）:蜂窩網絡場景，由混合和邊緣云和client-based自適應方案組成的框架。目標：減少蜂窩網絡中的視頻不穩定性、QoE的不公平性和卡頓

• [127] SAP（MMSys'17）：蜂窩網絡場景，DASH客戶端流量管理方案，利用網絡和客戶端狀態信息優化每個播放器的QoE。目標：在有不同信道狀況的多個DASH客戶端競爭資源時，減少視頻卡頓同時保持一致的QoE

• [129]?QoE multi-stage machine learning for dynamic video streaming（IEEE Transactions on Cognitive Communications and Networking’18）：利用[128] （IEEE CST'08）中的ML（機器學習）機制，多個DASH客戶端在共享信道中競爭可用帶寬時的多級ML認知方法，使用無監督ML和有監督ML學習質量-速率（Q-R，Quality-Rate）的關系。通過部署認知HTTP代理（CHP，cognitive HTTP proxy），控制發往客戶端視頻流量，執行流量分類，幫助客戶端做出決策，并根據Q-R函數應用資源分配

• [131] Oboe（SIGCOMM'18）：根據不同的網絡狀況自動調整ABR方案的參數配置

• [132] OpenCache（Elsevier CC’15）：基于OpenFlow的網內緩存服務，利用軟件定義網絡（SDN）為媒體內容提供緩存即服務（CaaS，cache-as-a-service）來優化視頻點播（VoD）DASH流。通過盡可能靠近客戶端推送視頻段（無需修改傳遞方法）減輕last mile可擴展性問題，并提升網絡資源利用率和QoE。此外，它還可以提供網絡和DASH客戶端的測量結果，幫助CDN提供商優化內容放置和傳遞機制

• [133]?Design and experimental evaluation of networkassisted strategies for HTTP adaptive streaming（MMSys'16）：研究多個異構自適應流媒體播放器共享同一瓶頸鏈路下的視頻質量公平性（VQF，video quality fairness），由視頻控制平面（VCP）實施視頻質量管理策略以確保公平性。作為網絡控制器應用，VCP在SDN控制器之上實現，由三種網絡輔助流方法組成：帶寬預留、碼率引導、碼率引導和帶寬預留的混合方法

• [134]?SABR（MMSys'17）：SDN輔助架構，利用SDN功能來協助和管理HAS播放器，并收集各種信息（如可用帶寬和客戶端狀態）以指導播放器的碼率決策

• [135]?WVSNP-DASH（IEEE Transactions on Broadcasting‘15）：用于小型化設備（包括傳感器）的基于DASH的視頻平臺（無線視頻傳感器節點平臺），使用替代方法對視頻分段以便小型無線設備和傳感器（傳輸、存儲和播放？）。對視頻段使用特定的命名語法（基于簡化的Backus-Naur形式[136]），在其名稱中嵌入視頻播放所需的基本元數據，使得每個視頻段成為可獨立播放的文件，因此客戶端不需要下載manifest文件和初始段也可以播放視頻段。基于HTML5的核心元素（如HTML5文件系統）設計，此外還可以封裝Web瀏覽器支持的任何容器、編解碼器和DRM。不足：沒有分析引入的開銷，嵌入在每個段中的新數據可能嚴重影響網絡效率和壽命

• [137]?Adaptive multimedia streaming in information-centric networks（IEEE Network‘14）：研究將HAS整合到信息中心網絡（ICN，Information-Centric Networking ）上的可能性

• [138]?Adaptive video streaming over informationcentric networking (ICN)（RFC 7933’16）：HAS over ICN

• [139]?Investigating the performance of pull-based dynamic adaptive streaming in NDN（IEEE JSAC'16）：通過分析不同基于ICN的轉發策略的網絡級理論最優和應用層面各種基于客戶端的ABR之間的性能差距，研究ICN上的DASH的性能。通過將ICN中的并發流客戶端公式化為具有/不具有緩存的分數多商品流問題（MCFP）來得到理論最優的界限，表明ICN多路徑和緩存功能可以提高HAS性能

• [140]?Towards SVCbased adaptive streaming in information centric networks（ICMEW'15）：在ICN上結合HAS與SVC。使用SVC的原因：（i）可以充分利用ICN的優勢，同時避免次優碼率選擇；（ii）有助于客戶避免高估帶寬；（iii）SVC的分層結構可以利用 ICN的多路徑功能帶來的好處

• [141]?EcoMD（Elsevier CC’17）：基于ICN的成本效益（cost-efficient ）多媒體內容傳輸解決方案，用于車載自組織網絡（VANET），以降低高動態VANET中視頻傳輸的成本。首先分析了內容移動性和供需平衡兩個基本因素，其次將與視頻傳輸相關的成本公式化為混合整數規劃（MIP）優化問題， 最后提出了三種自適應啟發式解決方案來解決優化問題：（1）基于優先級的路徑選擇；（2）最少需求的源維護；（3）按需路徑內緩存增強

• [142]?Mobile peer-to-peer video streaming over information-centric networks（Elsevier CN'15）：基于ICN的P2P流媒體應用，用于蜂窩網絡的直播HAS系統，利用ICN功能提供良好的HAS服務并實現簡化的部署過程。HAS客戶端（或對等體peers）構建P2P單跳網狀網絡，允許協同下載相同的直播視頻。 客戶端使用蜂窩網絡接口連接到HAS服務器，并通過鄰近WiFi信道相互連接

[120]-[127]：蜂窩網絡

[132]-[134]：將支持OpenFlow的解決方案與HAS相結合

[137]-[142]：ICN相關

• 所呈現的基于ICN的解決方案使用啟發式信息（從所請求的內容收集）來執行特殊節點的cache決策

• 其中一些解決方案中會產生大量冗余副本，影響存儲資源

• 提供高效的內容管理，確保cache性能，以及在ICN上設計強大的HAS交付系統仍然是一個懸而未決的問題

D. Hybrid Adaptation

在混合ABR中，多個網絡實體相互協作并收集有關網絡狀況的有用信息，這些信息可以幫助HAS客戶端進行碼率選擇。 這種技術包括基于SDN的ABR及服務器和網絡輔助的ABR。

1) SDN-Based Adaptation

SDN相關文獻：[143][144]

將SDN與自適應視頻流系統整合的出發點：

• SDN允許網絡資源控制和功能監管，從而簡化網絡資源編程和部署

• 多客戶端競爭共享鏈路時，單客戶端ABR無法解決公平性和網絡資源利用的問題，可以由具有全局網絡視圖的集中式機制來避免

方案：

• [145] QFF（SIGCOMM FhMN'13）：使用OpenFlow監視視頻流質量并分配/管理網絡資源，通過保證最后一英里的多個競爭的DASH客戶端之間的視頻質量公平性來優化QoE

• [146] IQMF（INFOCOM WKSHPS'15）：同作者對[145] QFF的改進。IQMF作為代理，目標是在視頻會話期間提供對每個客戶端的QoE的透明監控，并隨后通過API向網絡和內容提供商提供反饋。IQMF的提出是因為無法通過傳統網絡級指標（帶寬、丟包率、抖動、端到端延遲等）估算視頻質量。不足：QFF和IQMF在決策時都只考慮了設備分辨率和可用帶寬兩個指標，沒有考慮buffer水平

• [147] Towards QoE-aware video streaming using SDN（Globecom'14）：目標是在多個客戶端競爭共享容量時管理網絡資源，同時監控網絡狀況和客戶端反饋（QoE指標）。當QoE降低時（如卡頓），SDN應用程序使用SDN上的多協議標簽交換（MPLS）流量工程機制動態地重新路由視頻流。該方法可以通過選擇服務器的最佳路徑來改善整體QoE。不足：沒有描述流傳輸會話期間動態改變路徑的時間影響

• [148] GC（ICNP'14）：用于直播視頻流的SDN輔助服務，使用基于GENI SDN的網絡資源基礎設施在校園內提供在線教育視頻流直播，使客戶端可以通過公開共享的Web protal上傳及觀看在線視頻。GC能夠使用SDN的特性動態監視和管理一條或多條路徑上的視頻流和資源，被證明具有可擴展性、穩定性和公平性

• [149] Software-defined network-based prioritization to avoid video freezes in HTTP adaptive streaming（International Journal of Network Management'16）：通過在視頻段傳遞過程中使用優先級技術以減少由突發帶寬波動引起的視頻卡頓。該框架的主要組成部分SDN控制器通過收集網絡狀態信息（如帶寬變化、延遲、HAS客戶端的狀態）決定是否優先下載某個視頻段

• [150] Delivering stable highquality video: An SDN architecture with DASH assisting network elements（MMSys'16）：目標是確保穩定和高質量的視頻傳輸，同時避免TCP機制與DASH流量的動態突發性質之間的不匹配。系統結構包括三層：1)SDN網絡應用控制器：幫助多個競爭客戶端進行碼率選擇；2)SDN網絡管理：使用基于動態隊列的機制進行QoS配置；3)可編程網絡基礎設施。不足：沒有考慮設備異構性，而它對于確定可用帶寬和QoE公平性的公平份額較為重要

• [151] SDNDASH（MM'16）：解決[150]的問題，利用SDN，基于每個客戶端的QoE為其管理和分配網絡資源。由應用層、控制層、網絡層三層所組成，其中包含六個核心實體：DASH服務器、DASH客戶端、基于SDN的外部應用程序、SDN控制器、基于SDN的內部應用程序、轉發設備。 SDNDASH將碼率的QoE最大化和網絡資源分配的最優決策公式化為最大化優化問題，從而顯著提高每個客戶端的QoE，同時避免HAS穩定性問題

• [152] SDNHAS（IEE TMM'17）：解決[151] SDNDASH中未解決的可能影響ABR決策的三個限制：1)HAS播放器的大規模部署；2)通信開銷；3)對系統異構性的更多支持

• [153] ORL-SDN（ACM TOMM'18）：支持SDN的HAS在線強化學習（RL）QoE優化框架，包括三個階段：1)基于感知質量將HAS播放器分組為一系列不相交的集群；2)將碼率選擇公式化為部分可觀察的MDP；3)實現了一個在線Q-learning算法以解決QoE優化問題，并行尋找每個集群的最優碼率決策

• [154] BMS（IEEE Transactions on Broadcasting'18）：基于SDN的帶寬代理解決方案，將碼率決策公式化為凸優化問題，其依賴于凹網絡效用最大化（NUM）函數。目標：滿足每個會話和每個組的QoE目標

• [155] A buffer-aware HTTP live streaming approach for SDN-enabled 5G wireless networks（IEEE network'15）：在用于HLS服務的5G OpenFlow 無線網絡中的基于SDN的管理器。目標：通過在進行碼率決策時考慮視頻段感知質量和客戶端buffer大小，按需分配合適的網絡資源（如帶寬）以改善QoE。不足：既沒有考慮到無線電的突發帶寬波動特性，也沒有考慮由于用戶移動性而導致的切換情況

• [156] C3（NSDI'15）

• [157] CFA（NSDI'16）

• [158] CS2P（SIGCOMM'16）

• [159] Pytheas（NSDI'17）

[151][152][153]：背景相同

【總結：所有這部分研究的共同特征是都存在一個中央控制器來控制、管理、監控HAS流量。不足：不能很好地擴展并支持系統異構性，還會產生額外的開銷，從而影響網絡性能。】

2) Server and Network-Assisted Adaptation

• [16]?Enhancing MPEG DASH performance via server and network assistance（2017）

• [111] SAND（IBC'16）

• [160]?Enhancing MPEG DASH performance via server and network assistance（IBC'15）

[16][111][160] SAND：出發點：DASH的客戶端驅動方法對網絡和服務提供商的控制較少，這為他們在服務差異化方面帶來了新的挑戰。SAND是一個控制平面，提供客戶端-網絡、網絡-客戶端、網絡-網絡之間的異步通信。SAND從系統（包括客戶端）中的不同實體收集度量和狀態信息，并向客戶端和DANE（DASH感知的網絡元素，包括服務器、cache和路徑上的其他網絡實體）發送反饋。這些反饋信息可以協助客戶端進行碼率決策，并改進DANE的媒體傳送。SAND架構主要基于來自客戶端（如QoE度量）和網絡（如可用帶寬）的反饋，主要由SDN推動實現。

IV. COMPARISON BETWEEN BITRATE ADAPTATION SCHEMES

四類ABR對比結論：

Scheme Class	Pros	Cons
Client-Based	在某些環境下表現出良好的性能	由于缺少中央控制器指導播發器進行碼率選擇，大多數方案不是全局最優，在多客戶端共享瓶頸鏈路時會性能下降
Server-Based	具有中央控制的優勢（如可以獲取全局信息）	可能會在服務器上引入較高的復雜度并產生額外開銷，進而降低網絡效率。此外，這些方案需要修改manifests文件或服務器
Network-Assisted?&?Hybrid	可以獲取網絡的全面視圖，從而幫助客戶端進行碼率決策。適用于小型到大型網絡，能夠顯著提高QoE	實際部署較難，因為它們會引入一些可能降低網絡性能的開銷，且需要網絡中其他實體的支持

ABR方案完整對比：

總結

以上是生活随笔為你收集整理的ABR算法研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP（IEEE COMST‘18）阅读笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。