Dash相关领域知识总结

转自:http://blog.csdn.net/datamining2005/article/details/62225579?locationNum=4&fps=1

1.DASH介绍

DASH，又叫MPEG DASH，DASH：Dynamic Adaptive Streaming over HTTP ，是一种在互联网上传送动态码率的Video Streaming技术，类似于苹果的HLS，DASH会通过media presentation description (MPD)将视频内容切片成一个很短的文件片段，每个切片都有多个不同的码率，DASH Client可以根据网络的情况选择一个码率进行播放，支持在不同码率之间无缝切换。

DASH是由MPEG (Moving Picture Experts Group)组织制定，2010年开始启动，2011年11月发布Draft版本，2012年4月发布第一稿Version（ISO/IEC 23009-1:2012），2014年5月发布第二稿（ISO/IEC 23009-1:2014），最新稿（ISO/IEC 23009-3:2015）。

目前3GPP Release 10已经将DASH纳入其中；在HbbTV 1.5中也支持DASH；DVB-DASH也将DASH纳入到DVB（ETSI TS 103 285 v.1.1.1）。目前DASH Industry Forum由发起厂家组成，致力于推进DASH产品生态，将DASH产业化和业界最佳实践推向批量应用。

ISO/IEC 23009包含四个部分:

Part 1: Media presentation description and segment formats

Part 2: Conformance and reference software

Part 3: Implementation guidelines

Part 4: Segment encryption and authentication

DASH相比HLS、HSS等协议的优势在于：
DASH支持多种编码，支持H.265、H.264
4000
、VP9等等；
DASH支持MultiDRM，支持PlayReady、Widewine，采用通用加密技术，支持终端自带DRM，可以大幅度降低DRM投资成本；
DASH支持多种文件封装，支持MPEG-4、MPEG-2 TS（Transport Stream）；
DASH支持多种CDN对接，采用相同的封装描述对接多厂家CDN；
DASH支持异构终端，浏览器原生不用插件就可以支持，Android/iOS/Windows/Flash可以通过JITP将DASH转换为HLS、HDS、HSS等，已支持Legacy终端类型，支持一份存储，大幅度减少文件存储量；
DASH支持直播、点播、录制、时移等等丰富的视频特性；
DASH支持动态码率适配，支持多码率平滑切换；
DASH支持紧缩型描述以支持快速启动；
DASH支持客户端和服务端的广告插入。

DASH的厂家支持情况：
Android原生ExoPlayer播放器；
主流OTT：Youtube、Netflix；
主流浏览器（采用MSE、EME）；
主流智能电视厂商：三星、LG、飞利浦、SONY等。

主要的开源框架和Lib库有：

1、客户端
GStreamer
Dash.js
Libdash，支持Android、iOS多平台

2、服务端
Akamai CDN
Amazon Elastic Transcoder
Azure Media Service
BrightCove Zencoder
Nginx RTMP module
Wowza Streaming Engine

DASH典型的一个端到端的系统包含Encoder、Dash Server、Origin Server、Edge Server、DASH Client：



Media Presentation Description是描述分片和时序的信息：从MPD->Period->Adpatation Set(Video/Audio Track)->Representation(Multiple bitrate)->Segement



DASH内容准备提供不同码率的视频文件（使用不同的质量需求和网络环境），然后使用特定的分片方法， 将视频文件分片，然后分片传输到客户端进行播放。MPD文件时在视频文件进行分片时获得的视频本身的属性信息和视频分片信息。

至于为什么要用
TS 而不是 MP4，这是因为两个 TS 片段可以无缝拼接，播放器能连续播放，而 MP4 文件由于编码方式的原因，两段 MP4 不能无缝拼接，播放器连续播放两个 MP4 文件会出现破音和画面间断，影响用户体验。

2.OTT DASH和IPTV的对比

OTT的视频技术和IPTV的视频技术都是基于IP的，但是采用了完全不同的技术，对比如下：

网络：IPTV基于管理网络、高质量、低丢包率、网络时延小、网络结构相对简单、网络带宽恒定有保障，OTT基于非管理网络、网络质量不可控、丢包率高、网络时延大、网络结构复杂、网络带宽变化显著；

终端：IPTV终端基本上是运营商自己定义的STB，OTT终端型号、配置、能力、资源有极大的差异；

业务：IPTV网络是基于直播业务发展起来的，其核心诉求是直播时延小、基于组播的高效传送，而OTT网络是基于点播业务发展起来的，其核心诉求是对网络质量的容忍度；

技术：IPTV基于UDP 组播的传送技术，无法穿越防火墙，如果出现丢包会有马赛克，OTT基于HTTP over TCP传送技术，可以穿越防火墙，一般不会有马赛克，但会容易出现缓冲。

3.如何在OTT支持高并发的直播服务？

OTT采用的单播技术，在类似于世界杯、阅兵式、春晚等大型高集中度的直播事件时，传统的OTT单播技术无法满足要求，主要有3个问题：
如果是自建的CDN，边缘CDN无法支持超过平时10-100倍的的带宽服务；

如果是租用的CDN，成本会高到运营方无法承受；

即便不考虑成本因素，由于并发访问量带来的大量的网络拥塞。

解决办法一：ABR Multicast

将DASH Origin Server的流通过Multicast Server将HTTP转到UDP组播网络上，在Multicast Client上将UDP组播码流接受下来。在广播和eMBMS网络上传送DASH已经有相应的规范支持。



解决办法二：P2P

通过P2P节点互助，大幅度降低对CDN边缘节点的压力，可以卸载CDN的90%以上的流量压力，降低90%的带宽租用成本，并且大幅度降低网络路径的拥塞效应，自动通过P2P节点选择规避拥塞路径。



高热点的直播节目是非常适合P2P技术，对于Android/iOS等Mobile Phone/PAD一样非常有效，对本地的存储要求很低，可以基于内存缓存，在WiFi网络下提供P2P流服务。

Dash与HLS对比：

http://www.doc88.com/p-9962134662286.html

除了HLS,其他的动态自适应流媒体技术还有微软的IIS Smooth Streaming,Adobe公司的Dynamic Streaming等。这些共存的协议采用的技术80%是相同的，但是100%是不相兼容的。为了对业界存在的多种自适应流技术进行规范，MEPG推出MEPG-DASH标准。旨在为动态自适应流媒体技术创造一种同一的协议标准。DASH也得到了许多公司的支持，Apple，Adobe，Microsoft，Netflix，Qualcomm表示只要DASH完成，就会支持这个标准。

因此HLS和DASH的区别主要如下图：



DASH基于MEPG-DASH流媒体协议的系统架构如下图：



流媒体协议一共三种：rtmp，rtsp，http live streaming(apple和adobe各一种)
rtmp是adobe的，rtsp Android native支持，http
live streaming(以下简称hls)当然是apple主打，后来adobe也终于开窍支持了。
rtmp和rtsp都要求特殊的服务器，例如rtmp要求FMS/red5,
rtsp要求darwin等，hls只要普通的server。
类似于adaptive streaming的技术hls和rtmp都有，rtsp好像没有。

视频相关的协议有很多，不同的公司，甚至有自己的协议标准。本文尽量涵盖目前常见的视频相关的协议。
1，RTSP/RTP/RTCP协议族

本协议族是最早的视频传输协议。其中RTSP协议用于视频点播的会话控制，例如发起点播请求的SETUP请求，进行具体播放操作的PLAY、PAUSE请求，视频的跳转也是通过PLAY请求的参数支持的。而RTP协议用于具体的视频数据流的传输。RTCP协议中的C是控制的意思，用于在视频流数据之外，丢包或者码率之类的控制。
该协议族RTSP是建立在TCP之上的，RTP、RTCP建立在UDP之上。不过也可以通过interleave的方式，将RTP和RTSP一起在同一个TCP连接上传输。
RTSP协议族，是最早被提出来的，因此很多考虑的地方，都还带有早期的特征。比如使用UDP，是考虑到传输的效率，以及视频协议本身对丢包就有一定的容忍度。但是UDP协议，显然不能用于更大规模的网络，而且复杂网络下路由器的穿透也是问题。
从视频角度而言，RTSP协议族的优势，在于可以控制到视频帧，因此可以承载实时性很高的应用。这个优点是相对于HTTP方式的最大优点。H.323视频会议协议，底层一般采用RTSP协议。RTSP协议族的复杂度主要集中在服务器端，因为服务器端需要parse视频文件，seek到具体的视频帧，而且可能还需要进行倍速播放（就是老旧的DVD带的那种2倍速，4倍速播放的功能），倍速播放功能是RTSP协议独有的，其他视频协议都无法支持。
缺点，就是服务器端的复杂度也比较高，实现起来也比较复杂。
2，HTTP协议

HTTP的视频协议，主要是在互联网普及之后。在互联网上看视频的需求下形成的。

2.1

最初的HTTP视频协议，没有任何特别之处，就是通用的HTTP文件渐进式下载。本质就是下载视频文件，而利用视频文件本身的特点，就是存在头部信息，和部分视频帧数据，就完全可以解码播放了。显然这种方式需要将视频文件的头部信息放在文件的前面。有些例如faststart工具，就是专门做这个功能的。
但是最为原始的状态下，视频无法进行快进或者跳转播放到文件尚未被下载到的部分。这个时候对HTTP协议提出了range-request的要求。这个目前几乎所有HTTP的服务器都支持了。range-request，是请求文件的部分数据，指定偏移字节数。在视频客户端解析出视频文件的头部后，就可以判断后续视频相应的帧的位置了。或者根据码率等信息，计算相应的为位置。

2.2

支持HTTP range-request的服务器，目前就可以支持我们一般网络看视频的要求了。但是，这种方式，无法支持实时视频流，或者准实时视频流。因为视频流，是不存在一个视频文件的概念的。HTTP协议播放视频的好处，就是简单。采取通用的HTTP服务器，就可以提供服务，不需要专门类型的服务器，也不需要特别的网络端口，穿过路由器防火墙一点都没有问题。而且还可以利用通用的CDN来简化视频的部署分发的工作，减少带宽的使用。

这个是目前用于PC端或者网页端，视频点播业务，最常见的解决方案。客户端的实现，一般采用flash完成，flash本是的videoplayer或者videodisplay控件就可以完成。资源一般采用flv格式，也可以使用mp4格式。

在此基础上，多家公司推出了自己的解决方法。

2.3 HLS HDS MSS DASH

苹果推出的HTTP Live Streaming，就是随着苹果设备的普及得以广泛应用的一种。从名词就可以判断出来，HLS支持Live直播式的视频传输。HTTP采用m3u8作为索引文件，视频为MPEG2-TS格式的片段文件。如果为直播视频流，则采取更新m3u8文件，从而更新视频索引列表，达到视频直播的目的。但是这种方法，因为最终视频是片段文件，所以必然存在片段视频长度的延迟。因此只可以用于对实时性要求没有那么高的准实时视频流。但是HLS方式，因为采用了较早的MPEG2-TS格式，这种格式的overhead，也就是头部信息占据总文件的比例比较大，也就是效率不够高。之所以没有使用其他格式，主要是商业竞争和版权的问题。
相应的，adobe公司，推出相似的HTTP dynamic streaming。这种方式本质和HLS的策略是类似的，就是通过索引文件+视频片段的方式。但是显然采用的索引格式和视频片段格式都不一样的。HDS采用的是视频格式是flv或者f4v，索引格式记不清楚了。

类似的，微软也推出了Microsoft Smooth Streaming，也即是mss的视频播出方式，采用的视频格式是分段mp4格式。
MPEG标准组则推出了Dynamic Adaptive Streaming over HTTP,DASH.采用的视频格式为3GPP吧。
显然，这个目前是百花齐放的状态，虽然最常用的的是HLS，谁叫苹果这么霸气呢。而安卓和苹果上面对于flash都有限制，而HDS是adobe推出在adobe平台上面的。mss，只有在少数几个地方见到过。dash，目前仅仅是论文里面的产物。

以上的协议，主要是解决一个问题，就是自适应码率切换，上面的dynamic，adaptive都是类似的意思。主要是利用索引文件中同时给出不同码率的视频文件的地址，这样播放器端，可以根据带宽情况，自适应选择不同码率的视频文件。

同时在视频直播方面，在安卓和iOS平台以外，还有很多视频服务器提供厂商，自己开发协议，一般采用方式为固定时间片段的flv文件的方式（采用flv，是因为flash上方便播放）

2.4 HTML5

同时HTML制定厂商也不寂寞，推出HTML5这种方式，这种方式本质上，和前面的HTTP视频协议没有任何区别。但是播放器端，不再依赖于特定的插件如flash，或者其他播放软件，而是可以支持浏览器的直接视频播放。采用的是html中嵌入video标签，同时直接指明视频的url。不过，不同的浏览器，对于音视频的格式支持不完全相同。比较通用的是视频H。264格式，音频AAC格式，封装格式MP4。

2.5其他

在HTTP协议的基础上，各家公司，针对自己的业务特性，也可能开发自己的专有的数据格式，或者协议。但是都是在上述的基本上做出一些细微的修改而已。毕竟国内的技术体系，还完全无法提出一个新的技术的程度。（google，就提出新的编码格式替换H.264,SPDY协议，这个国内做不到的）。
一般只会做到例如HTTP特殊字段或者特殊参数，传递到flash中做出一定的解释。或者在原有的视频文件格式基础上添加一些特殊意义的头部等等。

3，RTMP

这个是adobe公司自己推出的视频播放协议。需要专用的服务器，如FMS，开源的有red5.这种协议也是flash默认支持的。

播放方式

单播

在客户端与媒体服务器之间需要建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户机，这种传送方式称为单播。每个用户必须分别对媒体服务器发送单独的查询，而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余首先造成服务器沉重的负担，响应需要很长时间，甚至停止播放；管理人员也被迫购买硬件和带宽来保证一定的服务质量。

组播

IP组播技术构建一种具有组播能力的网络，允许路由器一次将数据包复制到多个通道上。采用组播方式，单台服务器能够对几十万台客户机同时发送连续数据流而无延时。媒体服务器只需要发送一个信息包，而不是多个；所有发出请求的客户端共享同一信息包。信息可以发送到任意地址的客户机，减少网络上传输的信息包的总量。网络利用效率大大提高，成本大为下降。

点播与广播

点播连接是客户端与服务器之间的主动的连接。在点播连接中，用户通过选择内容项目来初始化客户端连接。用户可以开始、停止、后退、快进或暂停流。点播连接提供了对流的最大控制，但这种方式由于每个客户端各自连接服务器，却会迅速用完网络带宽。

广播指的是用户被动接收流。在广播过程中，客户端接收流，但不能控制流。例如，用户不能暂停、快进或后退该流。广播方式中数据包的单独一个拷贝将发送给网络上的所有用户。
使用单播发送时，需要将数据包复制多个拷贝，以多个点对点的方式分别发送到需要它的那些用户，而使用广播方式发送，数据包的单独一个拷贝将发送给网络上的所有用户，而不管用户是否需要，上述两种传输方式会非常浪费网络带宽。组播吸收了上述两种发送方式的长处，克服了上述两种发送方式的弱点，将数据包的单独一个拷贝发送给需要的那些客户。组播不会复制数据包的多个拷贝传输到网络上，也不会将数据包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。