文章目录
(注:本文档主要包含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)。关于ABR算法更详细的介绍参见本文3.3.1部分。
附: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优化与ABR算法
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使用的基于调和平均数的吞吐量预测不够准确,最近很多研究致力于提升其预测准确性(例如:Lumos (INFOCOM '22))。
- 机器学习方法:主要为强化学习方法,代表为Pensieve (SIGCCOMM '17)
- Penieve在实际场景中表现不佳,可能是由于离线仿真器与真实场景的差异过大。此外,机器学习的模型较为复杂,可解释性差,给实际部署和调试带来了较大的困难。
- 非机器学习方法:主要为控制论方法,代表为MPC (SIGCOMM '15)
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衍生指标:如启动时延、平均视频码率、质量切换、卡顿事件
*国际电信联盟(ITU-T)最近发布了两个系列的视频质量评估标准,分别为P.1203和P.1204,其性能优于PSNR、SSIM与VMAF,可参阅:ITU-T P.1203/P.1204视频质量评估标准介绍
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算法的介绍,可参考:FESTIVE (CoNEXT ‘12) 论文阅读笔记;BBA (SIGCOMM ‘14) 设计与代码实现;BOLA (INFOCOM ‘16) 核心算法逻辑;BOLA (INFOCOM ‘16) dash.js代码实现;Pensieve (SIGCOMM ‘17) 原理及训练指南
关于ABR算法的实际应用,可参考:dash.js的ABR逻辑;如何在dash.js中添加自定义ABR规则?
相关资料
- 介绍:
- 工业论坛&标准&白皮书:
- 开源实现:
- 工业部署:
- 学术研究(综述):