文章目录

1. What is DASH?
2. Why DASH?
3. 学术研究
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视频系统（服务器&播放器）搭建

关于ABR算法的实际应用，可参考：dash.js的ABR逻辑；如何在dash.js中添加自定义ABR规则？

DASH标准&ABR算法介绍