文章目錄

1. What is DASH?
- 1.1 MPD檔案
- 1.2 QoE & ABR演算法
- 附：VBR & AVC/H.264編碼
- 附：DASH白皮書結構 [2.c]
2. Why DASH?
- 2.1 HAS vs. 傳統方案
- 2.2 DASH vs. other HAS
- 2.3 DASH vs. others
- 2.4 DASH的劣勢
3. 學術研究
- 3.1 多客戶端的競爭/穩定性問題
- 3.2 恒定質量的流
- 3.3 QoE的優化與衡量
- - 3.3.1 QoE優化
  - 3.3.2 QoE衡量
- 3.4 目標間多媒體同步
4. 實際部署（個人經驗）
相關資料

（注：本檔案主要包含DASH與點播相關的內容，對直播相關的部分涉及不多，）

1. What is DASH?

DASH又稱MPEG-DASH，全稱為Dynamic Adaptive Streaming over HTTP（基于HTTP的動態自適應流），
DASH的架構如下圖所示[5.b]，藍色部分為標準指定內容，紅色部分可以自由實作：

在這里插入圖片描述
在DASH中，一個視頻會被編碼為多個不同的版本（稱為Representation），通常對應不同的解析度（如480p、720p、1080p）和平均碼率（如1.85Mbps、2.85Mbps、4.3Mbps），一個完整的視頻被切分為多個視頻塊（稱為segment/chunk/GoP），包含幾秒的視頻內容（通常2～5s，時長相等），DASH使用MPD檔案（Media Presentation Description）來描述視頻資訊，

所有視頻內容與MPD檔案保存于服務器上，在開啟視頻會話時，客戶端首先請求并決議MPD檔案，獲取服務器上的視頻資訊，之后，客戶端每次使用HTTP GET請求一個視頻塊，通過ABR演算法（Adaptive Bitrate，自適應碼率)決定所請求視頻塊的碼率級別，下載相應視頻塊并使用播放器播放視頻，

1.1 MPD檔案

DASH標準的核心內容之一是對MPD檔案格式的規范，MPD檔案是一種用XML語言描述的分層結構，其結構如下圖[5.b]：

在這里插入圖片描述
關鍵欄位：

Period：代表一個時間段，包含開始時間和持續時間，由一個或多個Adaption Set組成
Adaption Set：包含不同媒體型別的不同編碼版本（Representation），比如一個Adaption Set包含視頻的多個碼率版本，另一個Adaption Set包含音頻的多個碼率版本
Representation：表示同一媒體內容的不同編碼（碼率、解析度、信道數量等）版本，由一個或多個Segment組成
Segment：代表媒體塊，每個Segment都有一個URI，可以使用HTTP GET（or with byte ranges）下載

一個真實的MPD檔案內容如下，該視頻由FFMpeg編碼、GPAC（MP4Box）切片生成，總時長9m56.459s（“mediaPresentationDuration”, “duration”），每個視頻塊時長2s，幀率24fps，比例為16:9，共分為144p、240p、360p、480p、720p、1080p六個解析度，對應六擋平均碼率（“bandwidth”），格式為mp4，附帶的音頻只有一個版本，

<?xml version="1.0"?>
<!-- MPD file Generated with GPAC version 0.8.0-rev178-g44c48d630-master  at 2021-03-07T05:59:46.633Z-->
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" minBufferTime="PT1.500S" type="static" mediaPresentationDuration="PT0H9M56.459S" maxSubsegmentDuration="PT0H0M2.458S" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011,http://dashif.org/guidelines/dash264">
 <ProgramInformation moreInformationURL="http://gpac.io">
  <Title>bbb.mpd generated by GPAC</Title>
 </ProgramInformation>

 <Period duration="PT0H9M56.459S">
  <AdaptationSet segmentAlignment="true" maxWidth="1920" maxHeight="1080" maxFrameRate="24" par="16:9" lang="und" startWithSAP="1" subsegmentAlignment="true" subsegmentStartsWithSAP="1">
   <Representation id="1" mimeType="video/mp4" codecs="avc1.640028" width="1920" height="1080" frameRate="24" sar="1:1" bandwidth="4258031">
    <BaseURL>BBB1920x1080_dashinit.mp4</BaseURL>
    <SegmentBase indexRangeExact="true" indexRange="916-4523">
     <Initialization range="0-915"/>
    </SegmentBase>
   </Representation>
   <Representation id="2" mimeType="video/mp4" codecs="avc1.64001F" width="1280" height="720" frameRate="24" sar="1:1" bandwidth="2847609">
    <BaseURL>BBB1280x720_dashinit.mp4</BaseURL>
    <SegmentBase indexRangeExact="true" indexRange="915-4522">
     <Initialization range="0-914"/>
    </SegmentBase>
   </Representation>
   <Representation id="3" mimeType="video/mp4" codecs="avc1.64001F" width="896" height="504" frameRate="24" sar="1:1" bandwidth="1878775">
    <BaseURL>BBB896x504_dashinit.mp4</BaseURL>
    <SegmentBase indexRangeExact="true" indexRange="915-4522">
     <Initialization range="0-914"/>
    </SegmentBase>
   </Representation>
   <Representation id="4" mimeType="video/mp4" codecs="avc1.64001E" width="640" height="360" frameRate="24" sar="1:1" bandwidth="1240660">
    <BaseURL>BBB640x360_dashinit.mp4</BaseURL>
    <SegmentBase indexRangeExact="true" indexRange="915-4522">
     <Initialization range="0-914"/>
    </SegmentBase>
   </Representation>
   <Representation id="5" mimeType="video/mp4" codecs="avc1.640014" width="416" height="234" frameRate="24" sar="1:1" bandwidth="757000">
    <BaseURL>BBB416x234_dashinit.mp4</BaseURL>
    <SegmentBase indexRangeExact="true" indexRange="915-4522">
     <Initialization range="0-914"/>
    </SegmentBase>
   </Representation>
   <Representation id="6" mimeType="video/mp4" codecs="avc1.64000D" width="256" height="144" frameRate="24" sar="1:1" bandwidth="294059">
    <BaseURL>BBB256x144_dashinit.mp4</BaseURL>
    <SegmentBase indexRangeExact="true" indexRange="914-4521">
     <Initialization range="0-913"/>
    </SegmentBase>
   </Representation>
  </AdaptationSet>
  <AdaptationSet segmentAlignment="true" lang="und" startWithSAP="1" subsegmentAlignment="true" subsegmentStartsWithSAP="1">
   <Representation id="7" mimeType="audio/mp4" codecs="mp4a.40.2" audioSamplingRate="48000" bandwidth="139642">
    <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>
    <BaseURL>BBB_dashinit.mp4</BaseURL>
    <SegmentBase indexRangeExact="true" indexRange="856-4475">
     <Initialization range="0-855"/>
    </SegmentBase>
   </Representation>
  </AdaptationSet>
 </Period>
</MPD>

1.2 QoE & ABR演算法

ABR演算法的設計目標是提高用戶的QoE（Quality of Experience，體驗質量），點播視頻的QoE主要包括：

高視頻質量（一般用碼率表征）
低卡頓時間
少質量切換
低啟動時延

ABR演算法將網路吞吐量及播放器Buffer時長等資訊作為輸入，輸出下一個視頻塊的碼率級別，DASH標準并沒有規定ABR的實作方式，由客戶端自由實作，ABR演算法在DASH中的結構如下圖所示（From Neural Adaptive Video Streaming with Pensieve | SIGCOMM’17）：

在這里插入圖片描述
最直觀的ABR邏輯是選擇不高于預測吞吐量的最高碼率的視頻，該方法稱為Rate-based（RB），

附：VBR & AVC/H.264編碼

早期的視頻編碼方案均為CBR（Constant Bitrate，固定碼率），即整個視頻的所有片段的碼率都幾乎一致，
后來出現了VBR編碼（Variable Bitrate，可變碼率），可以根據畫面變化對不同的幀進行壓縮，AVC/H.264即為一種廣泛應用的VBR編碼方案，

在這里插入圖片描述
如圖所示，VBR編碼后，一個GoP（Group of Pictures）內包含一個I幀和多個P幀（*可能還有B幀），I幀可以獨立解碼為完整圖片，P幀則根據與I幀之間的差異生成，需要依賴I幀解碼，VBR可以對相對靜止或者復雜度較低的畫面使用較少的位元組進行編碼，因此其優勢在于降低了視頻壓縮的資料量，

下圖展示了不同解析度下VBR視頻的塊碼率變化（From ABR Streaming of VBR-encoded Videos: Characterization, Challenges, and Solutions | CoNEXT’18）：

*塊碼率=塊大小/塊時長，在視頻塊等長的情況下，塊碼率取決于塊大小

在這里插入圖片描述
對于VBR編碼的視頻而言，通常所說的視頻碼率指的是整個視頻的平均碼率，視頻解析度越高，平均碼率越高，對于單個視頻，其視頻塊大小的變化程度非常劇烈，因為視頻塊大小與其包含的畫面復雜度呈正相關，

VBR編碼對于ABR演算法設計也提出了新的挑戰：播放器Buffer的變化，既取決于網路的動態性，也取決于視頻內容的動態性，

附：DASH白皮書結構 [2.c]

Media presentation description and segment formats
Reference software and conformance
Implementation guidelines
Format Independent Segment encryption and authentication
Server and network assisted DASH (SAND)
DASH with Server Push and WebSockets
Delivery of CMAF content with DASH
Session based DASH operation

2. Why DASH?

2.1 HAS vs. 傳統方案

傳統視頻傳輸方案基于UDP，HAS（HTTP Adaptive Streaming）基于TCP進行視頻傳輸，

設計對比 [5.b] ：

傳統的流傳輸：服務器向客戶端push，在服務器端實作ABR（下文會講）——>增大了服務器的復雜度和運算壓力
HAS：將媒體內容看作普通Web資源，由客戶端向服務器pull，在客戶端實作分布式ABR

在這里插入圖片描述
架構對比[5.b] ：

HAS的優勢，首先在于HTTP用于媒體傳輸的優勢[5.b] ：

穿越NAT和防火墻
可以利用傳統的Web服務器及網路快取（如CDN）
客戶端端維護播放會話狀態，服務器端不需要維護任何狀態，因此客戶端可以從不同服務器下載視頻且不會影響系統的擴展性
客戶端與服務器間不需要持久連接，提高了系統的可擴展性，且降低了實作和部署開銷

其次，HAS允許客戶端根據網路變化請求不同碼率的視頻，提高了帶寬利用率，帶來了QoE的提高，

2.2 DASH vs. other HAS

在DASH之前，HAS主要為各公司的私有方案：

微軟：MSS（Smooth Streaming）
蘋果：HLS（HTTP Live Streaming）
Adobe：HDS（HTTP Dynamic Streaming）、OSMF（Open Source Media Framework）
Akamai：HD

這些方案的思路和技術大部分相同，但是無法互相兼容，增加了播放器的開發成本，為了解決這一問題，MPEG組織與微軟、蘋果、Netflix、高通、愛立信、三星和等公司聯合推出了MPEG-DASH，使其成為開放的國際標準（ISO/IEC 23009-1 [2.a] ），相對于私有解決方案（尤其是較為廣泛應用的HLS），MPEG-DASH的主要優勢在于降低了兼容成本，簡化了視頻流系統的實作，提高了通用性和靈活性，包括：

整合了之前幾種HAS方案，方便播放器進行兼容
不限定視頻編碼，方便視頻內容提供商進行兼容
有豐富的開源實作，便于應用

2.3 DASH vs. others

在DASH之前，工業界也有一些其他非HAS的視頻傳輸方案，但DASH很明顯在靈活性和QoE上具有更好的表現，?
國內點播視頻的主流方案包括整段/分段FLV、整段MP4等，整段MP4的問題在于，對于長視頻而言，其頭部過于復雜，首幀加載很慢，
?

以下二圖為國內主流視頻傳輸方案的對比：

（From 我們為什么使用DASH | 嗶哩嗶哩）
在這里插入圖片描述
（From DASH、HLS和MP4格式有什么播放體驗區別？ | 華為云）

2.4 DASH的劣勢

盡管DASH可以同時應用于直播和點播場景，但受限于視頻切片，DASH目前的劣勢在于其應用于直播場景的時延較大（至少一個視頻塊的時長，如2s），

下圖對比了不同直播傳輸方案的時延差異（From 打造極致觀看體驗：超低時延直播技術探索與實踐 | 2020阿里云云棲大會）：
在這里插入圖片描述
（注：DASH工業論壇 [2.a] 似乎最近在關注DASH應用于直播的問題)

3. 學術研究

*此部分內容可以參考：ABR研究綜述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP（IEEE CST’18）閱讀筆記

針對DASH（HAS）的相關研究主要分為以下幾個方面[5.b]：

多客戶端的競爭/穩定性問題（Multi-Client Competition/Stability Issues）
恒定質量的流（Consistent-Quality Streaming）
QoE的優化與衡量（QoE Optimization and Measurement）
目標間多媒體同步（Inter-Destination Multimedia Synchronization）

3.1 多客戶端的競爭/穩定性問題

一個合理的DASH（HAS）機制應該能夠實作：

穩定性：避免頻繁的碼率切換
公平性：多個DASH（HAS）客戶端公平共享網路資源（網路資源）
高利用率：客戶端盡可能有效地利用網路資源

但DASH（HAS）客戶端獨有的ON-OFF請求模式，為實作以上目標帶來了挑戰，

在一個視頻流會話中，客戶端會處于兩種狀態：buffer填充狀態和穩定狀態，在buffer填充狀態下，客戶端持續向服務器請求視頻塊，以快速填充buffer，使其達到目標值，從而進入穩定狀態；而在穩定狀態下，客戶端僅在buffer低于目標值時才進行請求，導致實際的請求行為并不連續，將客戶端進行請求的時間段稱之為ON，不請求的時間段稱之為OFF，可以看出，客戶端的請求行為呈現出明顯的ON-OFF周期性特征，

一個真實場景下的ON-OFF請求行為如下圖，Request表明客戶端向服務器發出請求但還未收到回應，Download表明客戶端收到回應并開始下載，Idle表明客戶端與服務器之間沒有任何資料傳輸，

在這里插入圖片描述
需要注意的是，若OFF的持續時間超過某一閾值（Linux默認值為200ms），對于CUBIC等擁塞控制演算法（不包括BBR），其擁塞視窗會恢復到初始大小（Linux默認值為10)，則穩定狀態下每個視頻塊的請求都是一個獨立的慢啟動增窗程序，
?

由于ON-OFF周期的存在，若多個客戶端共享瓶頸鏈路（各客戶端的ON-OFF周期不重疊），或一個客戶端與其他持續流共享瓶頸鏈路（慢啟動導致客戶端無法競爭到足夠的可用帶寬），一方面客戶端很難準確估計真實的可用帶寬，另一方面客戶端無法獲得公平的網路資源，導致客戶端無法實作穩定、公平、高利用的目標，

3.2 恒定質量的流

視頻流傳輸的目標之一是提供質量恒定的視頻流，以避免頻繁的質量切換影響QoE，過去的方案直接用視頻碼率表征視頻質量，然而研究表明，視頻質量（可以用PSNR、SSIM、VMAF等指標衡量）與視頻碼率之間呈非線性關系，如下圖[5.b]所示：
在這里插入圖片描述
可以看出，視頻質量和視頻碼率的不一致性（非線性關系），既體現在單個視頻中，也體現在不同視頻的對比之中，網路的動態性與視頻內容的動態性，為實作恒定質量的視頻傳輸帶來了挑戰，

3.3 QoE的優化與衡量

3.3.1 QoE優化

DASH客戶端部署ABR演算法（注：此外，還有一些非客戶端的ABR方案，以及非ABR的QoE優化方案）以實作QoE的最大化，近些年來，學術界在此領域有非常豐富的研究，目前主流的ABR演算法按照其決策依據主要分為：

基于吞吐量預測：僅根據吞吐量預測進行碼率決策
- 最直觀的ABR演算法，通過吞吐量預測給定可選碼率的上界，以在不卡頓的前提下盡可能提高視頻質量
- 存在兩個問題：1) 準確的吞吐量預測很難實作，尤其是在弱網下；2) 存在頻繁的質量切換，造成QoE損失
- 代表：FESITIVE（CoNEXT’12）
基于播放器Buffer：
- 由于吞吐量的準確預測較為困難，此類演算法僅根據播放器當前的Buffer水平進行碼率決策
- 存在的問題：buffer的變化本身并不足以同時表征網路環境和視頻資訊
- 代表：BBA（SIGCOMM’14）、BOLA（INFOCOM’16，已成為dash.js [3.a] 默認ABR演算法的一部分）
基于混合資訊：基于吞吐量預測（可能是隱式的）和buffer等資訊進行碼率決策，是目前工業界部署和學術界研究的主流方案，可分為機器學習方法與非機器學習方法：
- 非機器學習方法：主要為控制論方法，代表為MPC（SIGCOMM’15）
  - MPC使用的基于調和平均數的吞吐量預測不夠準確，最近很多研究致力于提升其預測準確性，
- 機器學習方法：主要為強化學習方法，代表為Pensieve（SIGCCOMM’17）
  - Penieve在實際場景中表現不佳，可能是由于離線仿真器與真實場景的差異過大，此外，機器學習的模型較為復雜，可解釋性差，給實際部署和除錯帶來了較大的困難

3.3.2 QoE衡量

為簡便起見，目前ABR學術研究的QoE形式，是將其主要影響因素賦以權重后線性加和，形如下式（From A Control-Theoretic Approach for Dynamic Adaptive Video Streaming over HTTP | SIGCOMM’15）：
在這里插入圖片描述
等號右邊四項，分別代表一個視頻流會話中的：總視頻質量、總視頻質量切換、總卡頓時間、總啟動時延，

*早期的研究直接用碼率代替質量，近期研究則偏向于使用特定的質量衡量指標（如SSIM）
*大部分研究不關注啟動時延

然而，真實場景中的QoE則更為復雜，研究將影響QoE的因素分為兩類：

perceptual（用戶感知層面）：視頻影像質量、啟動時延、卡頓的時間和頻率、質量切換的程度和頻率
technical（技術指標層面）：演算法、引數、視頻流系統的軟硬體

視頻流領域的一個主要挑戰是缺乏統一的量化方法來衡量QoE，現有的工業和學術方案基于三方面的指標來衡量QoE：

客觀指標：如PSNR（Peak Signal-to-Noise Ratio，峰值信噪比）、SSIM（Structural SIMilarity，結構相似性）
主觀指標：如VMAF（Video Multimethod Assessment Fusion）
QoS衍生指標：如啟動時延、平均視頻碼率、質量切換、卡頓事件

3.4 目標間多媒體同步

不同用戶同步觀看視頻的需求逐漸顯現，在傳統方案中，每個客戶端僅根據自身的網路環境進行視頻傳輸，并不考慮與其他客戶端的同步，因此，如何為分布在不同地理位置的多個客戶端實作播放狀態同步，也成為了需要研究的問題，該問題稱為目標間多媒體同步 (IDMS)，

4. 實際部署（個人經驗）

目前DASH已經在諸多視頻廠商的產品中得到廣泛部署，國外廠商如Youtube、Netflix、Hulu等，國內廠商如Bilibili，

dash.js [3.a] 是DASH工業論壇[2.a]推薦的DASH標準播放器，dash.js基于Javascript實作，可以在HTML網頁中實作DASH視頻播放的功能，

基于Nginx（HTTP/1.1）與dash.js搭建DASH視頻播放系統的個人實踐：DASH視頻系統（服務器&播放器）搭建

DASH標準&ABR演算法介紹