网络流媒体协议之——MPEG-DASH协议简述
最近又把MPEG-DASH协议大概看了一下，本篇算是一篇学习笔记，主要参考下面这篇英文文档：
https://bitmovin.com/dynamic-adaptive-streaming-http-mpeg-dash/
DASH(Dynamic Adaptive Streaming over HTTP)是在2011年底由MPEG和ISO共同制定的标准，通过HTTP共同影音档案通讯协定，可使高品质影音内容通过网路传送到联网电视、机顶盒及移动终端设备。在MPEG-DASH之前，市场上已有Apple的HLS、Microsoft的Smooth Streaming以及Adobe的Dynamic Streaming等渐进式流媒体协议，但彼此并不相容，MPEG-DASH整合了这三种流媒体协议，同时支持TS profile和ISO profile，更具通用性。
MPEG-DASH的形成历史可以参见下图：
目前，MPEG-DASH已经被越来越多的应用在互联网上，随着一些有影响力的大公司如Netflix、YouTube和Google等的加入，加速了MPEG-DASH协议的部署。有了这些主要的互联网流量来源，MPEG-DASH已经占据了网络流媒体总流量的半壁江山。
DASH自适应码率下载工作示意图如下，首先，HTTP Server端将媒体文件切分成一个个时间长度相等的小分片(Segments)，每个分片被编码为不同的码率和分辨率；这些分片可以通过GET请求下载，客户端通过评估自身的性能和带宽情况，下载相应码率和分辨率的切片。码率切换以Segment为单位，当自身带宽较好时，在下载下一个切片时，就可以请求对应码率的较高分辨率的切片；而当带宽变差时，则当前切片下载完成后，可以下载码率和分辨率较低的下一个切片。由于不同质量的切片在时间上都是对齐的，因此，在不同质量的切片之间切换时，是自然流畅的。
下面我们来着重介绍一下MPD文件，MPD文件的结构大概如下图所示：
Periods
一个MPD文件可以包含一个或多个Periods，每个Period代表某一个时间段，比如某条码流有60s长，Period1为0~15s，Period2为16~40s，Period3为41~60s。在同一个Period内，可用的媒体内容及其各个可用码率(Representation)不会发生变更。直播情况下，可能需要周期性地去服务器请求新的MPD文件，服务器可能会移除已过时的Period，添加新的Period，而新的Period中可能会添加新的可用码率，或去掉上一个Period中存在的某些码率。
AdaptationSet
一个Period由一个或多个AdaptationSets组成，AdaptationSet包含了逻辑一致的媒体呈现的格式，例如，相同的codec、language、resolution，以及音频通道数(5.1，stereo等)的媒体内容可以组成一个AdaptationSet。每个AdaptationSet由一组可供切换的不同码率的码流(Representation)组成，这些码流中可能包含一个(ISO profile)或多个(TS profile)media content components，因为ISO profile的mp4或fmp4 segment中通常只含有一个视频或者音频内容，而TS profile中的TS segment同时含有视频和音频内容，当同时含有多个media component content时，每个被复用的media contentcomponent将被单独描述。
Representation
一个AdaptationSet由一组媒体内容版本可切换的Representations构成。每个Representation包含了相同媒体内容的不同版本，即不同的分辨率、码率等，以供客户端根据自身的网络条件和性能限制来选择合适的版本下载播放。
Segment
每个Representation中的内容都被切分成一段段Segments，使得客户端在播放时能够方便在不同的Representations之间切换。每个Segment由一个对应的URL指定，也可能由相同的URL与不同的byte range指定。DASH客户端可以通过HTTP协议来获取URL对应的分片数据。MPD中描述Segment URL的形式包括Segment list，Segment template，Single segment。
Subsegment
Segments可以进一步划分为更小的Subsegments，Subsegments表示Segment中一些更小的access units。Segment index描述了Subsegments的presentation time range和byte position，客户端可以先获取Segment index，再通过HTTP 1.1的byte range requests去请求相应的Subsegment。
在媒体播放过程中，虽然可以方便地在不同的码率(Representations)之间，但并不能做到在码流的任意点切换。需要注意的是，Segments之间不允许互相覆盖(overlap)，而且Segments之间是解码独立的，也就是每个Segments可以单独解码，而不依赖其之前或之后的其他Segments，这就涉及到了Stream Access Point (SAP)的概念。SAP可以简单理解为I帧或IDR帧，一般每个Segments的起始帧都是IDR帧(H.264 / AVC)，这样就保证了每个Segments传输完成之后，可以切换到其他的Representation。
下面我们对Segment URL的几种形式做一些必要的说明。
Representation中会包含(且仅包含)这几个选项之中的一个：(1) 一个或多个SegmentList元素；(2) 一个SegmentTemplate；(3) 一个或多个BaseURL元素，最多一个SegmentBase元素，不含有SegmentTemplate或SegmentList元素。下面我们分别来描述这三个元素。
(1) SegmentList
SegmentList包含了一个SegmentURL的列表，客户端按照segment列表元素在MPD文件中出现的顺序来请求和播放相应的Segments。SegmentURL即为每个Segment的地址，可以是绝对地址，也可以是相对地址，也可能是字节范围。看一个示例：
上例中，SegmentListduration表示每个Segment的目标长度为10S，Initialization sourceURL中包含了该Representation的初始化信息。
(2) SegmentTemplate
SegmentTemplate提供了一种通过给定的模板构造出一个segment list的机制，这意味着一些特定的标识符将被动态值取代。在SegmentList模式中为每个Segment构造一个URL，当Representation中分段较多时，会使得MPD文件变得很大，而SegmentTemplate模式则可以通过少数几行描述来构造出一系列segments。有两种形式的SegmentTemplate，一种是基于数字的SegmentTemplate，另一种是基于时间的SegmentTemplate。
基于数字的SegmentTemplate见如下示例：
上例中，通过“SegmentTemplate”元素中的地址和startNumber就可以构造出不同的segmentlist了，只需要短短几行表述，使得MPD文件更加简洁和紧凑。这种方式特别适用于含有多个Representations的长视频，能够有效压缩MPD文件的大小，提升客户端的下载速度和播放启动速度。
“SegmentTimeline”字段中描述了当前Representation中第一个Segment的起始时间，duration，以及段的repeat次数(个人理解，应该是具有相同duration的segments的个数，这样读取完一个Segment之后，就可以根据该数值直接去读取下一个Segment，而不需要重新去读取一遍MPD)。
(3) SegmentBase
在MPEG-DASH中，SegmentBase是当Representation中只有一个media segment存在时使用的方式。举个例子：
上例中，Representation内仅有一个Segment，BaseURL为http://cdn.bitmovin.net/bbb/video-1500k.mp4，SegmentBaseindexRange="0-834"表示SAP和其他初始化信息包含在开头的834字节中。
有了以上的概念，我们来最后看一个完整的MPD文件，由于内容较多，其中隐藏了部分内容，但保留了整个MPD文件的结构。
