MPEG-DASH白皮书第一版翻译

3,058 阅读16分钟

注:英语太烂基础太差,本翻译文档仅供本中自己参考。而且包含一大堆自己YY的意译。

编号:ISO/IEC JTC1/SC29/WG11 W13533

时间:2012年4月

标题:MPEG-DASH标准白皮书

在线观看奥运会,把最爱的电视节目插曲下到游戏机上,或在手机上浏览24小时不间断的新闻频道,以上这些应用场景都渗透到了我们的日常生活中。据统计,在过去的2008年奥运期间,NBC一共大约传输了3.4PB的视频内容[1]。但相较其巨大的潜在市场,网络流媒体仍处于发展初期。导致这种情况的原因之一就是目前各个商业平台的封闭性:每一家都有自己的音视频格式、流协议以及播放形式。也就是说,不同设备和服务器供应商之间根本没有互通。有研究表明,不久后的将来,视频将占据网络流量的绝大部分[2]。而在不同设备和服务器供应商之间形成统一标准,基于这样的兼容性,台式机/电视机/笔记本/机顶盒/游戏机/平板电脑以及手机上可以实现一个大规模的内容和服务生态圈,将大力推进视频行业的发展。MPEG-DASH就是为此而诞生。

一、为何使用HTTP流?

20世纪90年代开始,视频内容的网络传输逐步兴起,实时传输和大规模的数据逐渐成为主要的技术瓶颈。IETF发布的RTP协议(Real-time Transport Protocol)定义了超低延时前提下的网络传输音视频包格式。RTP在组建IP网络(managed IP networks)中有良好的表现。但是,目前网络应用已经基本转移到CDN上,CDN大多数都不支持RTP流;此外,RTP包很容易被防火墙拦截;另外,RTP流要求服务端与每一个客户端都保持独立的长连接,这对服务端负载造成巨大的压力。

随着网络带宽的增加以及万维网的迅猛扩展,使用很小的封装包来传输音视频数据逐渐变得不那么重要了。当前使用HTTP协议可以非常高效地传输大分片(相对于小封装包而言)的多媒体内容。HTTP流有许多的优势:1)在目前网络结构下的高效性,比如CDN的边缘节点缓存减少了远程传输;2)HTTP能有效避开防火墙的阻拦,因为几乎所有的防火墙都支持HTTP穿透;3)HTTP服务端技术已经完全商业化,用来支持百万级的直播用户是非常高效和有价值的;4)HTTP流传输时,客户端无需与服务端维持一个长连接,因此服务端只要使用CDN的标准http技术管理即可,无需浪费大量额外资源用于保证大量流客户端的连接。

综上所述,商业应用部署时通常选用HTTP流这一途径。比如Apple公司的HLS协议(HTTP Live Streaming)[3]、Microsoft公司的MSS协议(Microsoft's Smooth Streaming)[4]、Adobe公司的HDS协议(HTTP Dynamic Streaming)[5]均基于HTTP传输。不过,这些协议的定义、描述和包结构都各不相同,客户端必须针对不同协议做特有的兼容性支持,才能正常接收数据。统一的http流媒体传输标准可以在所有规范化的客户端和服务端之间传输流数据,这将实现不同供应商之间客户端和服务端的互通。

基于市场的发展和行业要求,2009年4月MPEG开始征集HTTP流媒体标准的提案。截至2009年7月,当MPEG开始评估提交的技术时,一共收到了15份完整的提案。在随后的两年中,在大量专家参与下,通过与其他标准组织(例如3GPP[6])的合作,MPEG完成了该规范的制定。该标准最终版的核心部分,ISO/IEC 23009-1,即MPEG-DASH协议(MPEG Dynamic Adaptive Streaming)于2012年4月发布[7]。

二、码率自适应的简单例子

图一中给出了按需动态切换码流的简单示例。在这个图片中,媒体流包含了音频和视频部分。视频源被编码为三种码率供选择:5M/2M/200Kbps,此外还提供了仅包含I帧的低帧率码流用于特殊场景下的播放。对应的音频内容有两种语言版本供选择:音频流1为英文杜比声,编码为环绕音、AAC 128K和48Kbps两种码率;音频2则是原始的法语版,编码为AAC 128K和48Kbps两种码率。

图一

图一、动态码率自适应的简单示例,编号圆圈表示客户端执行切换动作时间点

假设客户端启动播放时请求了最高码率(5M)的视频流及英文版128K音频流(由于客户端不支持环绕声音频播放)。传输了音视频的第一个分片后,通过对有效带宽的监控,客户端察觉到实际可用带宽低于5Mbps。于是,在下个可用的切换点(编号2),客户端将视频流切换为2Mbps,即下个分配请求中等质量的视频流,同时保持128Kbps的音频流传输。客户端继续监控可用网络带宽,意识到带宽进一步降低到2Mbps以下了,为了保持播放的流畅性,它将视频流和音频流分别降到500Kbps和48Kbps(编号3)。客户端继续以上述码率播放,直到带宽增加时,才将视频流码率提升到2Mbps(编号4)。过了会儿,用户决定暂停和倒带,这时客户端开始从特殊场景模式下载并倒序播放视频数据,同时将音频静音(编号5)。用户在自己期望的时间点(编号6)点击播放原始法语流,这时客户端切换为5Mbps的高清晰度视频流传输,以及128Kbps的法语音频流传输。

以上示例或许是流媒体传输中动态码率切换最为简单的情况。更进阶的使用包括在不同摄像视角、3D流媒体内容、带字幕或说明的视频流、动态广告插入、低延迟直播流、混合流和备播流等码流之间的切换。

三、MPEG-DASH标准涵盖范围

图二简单说明了HTTP服务端和DASH客户端之间的流媒体传输方案。在该图中,HTTP服务器获取并存储了多媒体内容,并使用HTTP协议来传输。服务端包含两部分内容:1)MPD文件(Media Presentation Description),列举了可用分片的清单、可供切换的不同码率、URL地址及其他特征;2)分片文件,以块、单一文件或多文件形式存储了实际的多媒体码流。

图二

图二、MPEG-DASH标准范围。红色块中格式和功能在标准中定义,客户端控制模块和播放器不在标准范围内

DASH客户端首先下载MPD文件来启动播放。MPD文件可以使用HTTP、邮件、U盘、广播或其他途径来传输。MPD解析完成后,DASH客户端获取到了媒体内容时长、可用性、媒体类型、分辨率、最小和最大带宽以及可供选择的各种码流、可访问性功能及所需的数字版权证书(DRM)、网络中各媒体组件所处位置及其特征。使用以上信息,DASH客户端可以选择合适的码流,开始通过HTTP GET请求获取分片数据。

客户端适当缓冲一定量数据来适应网络抖动,不断地下载后续分片并且监控带宽的波动。基于这个结果,客户端在不同备选码流(码率更高或更低)中切换并下载分片数据,用以保证带宽波动下足够的缓冲。

MPEG-DASH规范只定义了MPD和分片格式。MPD文件的传输、分片文件及媒体编码格式、客户端下载方式、码率切换装置、媒体数据的播放都不在MPEG-DASH标准的涵盖范围内。

四、MPD文件

动态HTTP流传输要求服务端提供多媒体内容的不同码率方案供选择。此外,多媒体内容可能包含若干媒体组件(如音频、视频、文本等),每种组件都可以具备不同的特征。在MPEG-DASH标准中,这些特征在MPD中以XML形式描述。

图三

图三、MPD分层数据模型 图三是MPD分层数据模型的演示。MPD由一个或多个以时间轴划分的区段(Period)构成。每个Period都定义了开始时间及时长,由一个或多个自适应子集(AS)组成。AS指出了所对应的(一个或多个)媒体内容,及其不同编码方案信息。比如,某个AS可以包含某媒体内容中视频部分的不同码率信息,另一个AS则包含该媒体内容中音频部分的不同码率信息(比如较低质量的立体声和较高质量的环绕声)。通常情况下,一个AS会包含多个表述(Representation)。

表述是指某个媒体组件的可选编码方案,以码率、分辨率、信道或其他特征区别于其他表述。每个表述由一个或多个分片(Segment)组成。分片就是媒体流基于时间轴的分块。分片都带有特定的URI(即服务器上的可寻址地址),使用HTTP GET请求(可以指定字节范围)即可下载媒体数据。

DASH客户端首先解析MPD中的XML文档来使用以上数据模型。然后,根据MPD中的描述性元素、客户端支持的功能以及用户的决定来挑选自己将使用的一组表述。接着,客户端构建出时间轴,请求对应的多媒体分片数据来开始本次播放。表述中给出的分片信息,使得对应分片的HTTP URL及字节范围能正确构建和请求。在直播场景下,MPD中还会描述出使用该分片文件的起始时间、临近媒体数据开始时间,以及分片的固定或可变时长。

四、分片文件格式

用户可以将多媒体内容看成一组分片文件来访问。DASH客户端发起完整或部分的HTTP GET请求时,所收到响应的实体主体就是一个分片。媒体组件会被编码并划分为多个分片。其中,第一个分片一般包含DASH客户端解码器初始化所需信息,它不包含任何实际的媒体数据。流数据则会被划分为一个或多个连续的媒体分片。每个媒体分片有独一无二的URL(有时候会附带有字节范围)、索引、显式或隐式的开始时间及时长。每个分片至少包含一个流接入点(Stream Access Point),可以仅基于当前数据开始流媒体解码,这实现了该媒体流在本分片位置的随机接入或切换。

MPEG-DASH规范通过使用分片索引框(segment index box)[8],标识所包含的子分片,来实现分片内各部分的并行下载。该索引框记录了各子分片的时长和字节偏移,用于标识子分片及流接入点。DASH客户端可以使用索引信息,通过部分的HTTP GET请求获取子分片数据。索引框可以是单一的,位于该分片开始位置,也可以是多个,存在于分片内各处。索引信息的分布可以是多元化的,例如分层结构、菊花链或混合结构。这避免了因在分片头部添加非常大的索引框造成的较大初始延迟。

MPEG-DASH基于ISO的MP4[9]和MPEG-2的TS[10]文件分别进行了封装格式的定义。它未指定具体的编码标准,且支持单一码流或码流复用。

五、多DRM(数字版权管理)及通用加密

在MPEG-DASH中,每个AS可以拥有一个或多个DRM来对内容进行保护,客户端解析出至少一个DRM后便可以传输和解码数据。

为实现MPEG-DASH标准化,MPEG还提出一个通用加密标准(即ISO/IEC 23001-7),定义了媒体内容通用加密方案的信令。基于此标准,数据在完成一次加密后传输到各个支持不同DRM证书的客户端,客户端通过解析MPD文件中的信令,使用各自的DRM系统来获取特定的解密密钥,然后从同一服务器传输得到通用加密后的媒体内容。

六、其他功能点

MPEG-DASH标准包含了多种丰富的功能,比如:

  • 1).多路可供切换的流:MPD文件为DASH客户端提供了足够信息,便于在不同流之间进行选择和切换,比如切换不同语种的音频流、不同视角的视频流、不同语种的字幕文件,或同一摄像机不同码率之间的动态切换。
  • 2).动态广告插入:无论点播还是直播场景,广告都能以区段的形式插入原有区段或分片之间。
  • 3).简化描述文件:分片的URL可以使用模板来标识,这使得MPD文件非常简洁。
  • 4).模块化描述文件:MPD文件可以划分为多个部分,其中一些元素可以从外部引用到,这一特点实现了MPD分段下载的可行性。
  • 5).分片时长可变:分片的时长可以变化。直播场景下,当前分片中可以带有下一分片的时长信息。
  • 6).多URL支持:同一内容在不同服务器或CDN上具备各不相同的URL,客户端可以选择其中任意一个来最大化利用当前网络带宽。
  • 7).直播场景的时钟偏移控制:每个分片中都可以包含UTC时间,用来保证客户端对时钟偏移的控制。
  • 8).可伸缩视频编码(SVC)和多视图视频编码(MVC)支持:MPD文件可以为表述之间的解码依赖关系提供足够的信息,用于保证诸如SVC和MVC多层编码的正常使用。
  • 9).描述符的灵活性:用于对内容分级、组件构成、可访问性、视角、帧封装和音轨属性等进行描述。
  • 10).可根据内容制作者的要求,将AS进行分组。
  • 11).会话质量评估:对于通信会话有明确定义的质量指标,便于客户端测量评估并上报。

七、MPEG-DASH附加部分

目前,MPEG委员会正在开发三个新的模块,将用来增加到ISO/IEC 23009-1标准的核心部分中。以下模块是该规范核心部分的支持或扩展:

  • 1).ISO/IEC 29002-2(卷2):"Conformance and reference software"规定了用于实现ISO/IEC 23009所有其他部分规范性条款所需的一致性和参考软件。
  • 2).ISO/IEC 29002-3(卷3):"Implementation Guidelines"给出了使用该标准及达到最佳体验的指导信息。它为点播、直播、特殊模式、广告插入场景下制作和发布MPEG-DASH内容提供了指导。它还提供了客户端实现指南,包括MPD文件检索、码率自适应、流切换、拖拽和特殊模式播放。此外,卷3还描述了直播服务部署时的DASH时序模型构建。
  • 3).ISO/IEC 29002-4(卷3):"Segment encryption and authentication"定义了MPEG-DASH分片的加密和验证方法。此部分允许忽略分片内具体格式和内容,将整个分片进行加密和验证。该规范还扩展了MPD文件,用于标识加密和验证信息。

ISO/IEC 23009-1的更改和修正也在进行中,该规范得到了进一步明确定义,并且增加了一些关键功能。

八、后续工作

该规范定义了五个特定的配置条款,各自对应不同类型的应用。每种配置都有不同的限制条件,其所约定的MPD和分片文件格式构成了整个规范的一个子集。因此,对应某一配置的DASH客户端仅需实现该配置(而不是整个规范)要求的功能。某些配置专门用于兼容已有内容,这为现存的非标准迁移到标准方案提供了可行性。

其他一些标准组织和机构也在与MPEG合作,实现自己标准中对MPEG-DASH的应用。与此同时,业界在提供MPEG-DASH解决方案上反应迅速,一些DASH相关开源项目正在开发中。未来几年将是行业(即内容服务提供商、平台提供商、软件供应商、CDN供应商和设备制造商)采用该标准构建网络多媒体生态圈的关键时机。

九、引用

  • [1] Miller, P., SVP/GM Digital Media at NBC Sports, keynote, blogs.msdn.com/b/tims/arch…, March 2009.
  • [2] Cisco Networks, “Cisco’s Visual Networking Index Global IP Traffic Forecast 2010-2015,” www.cisco.com/en/US/netso…, June 2011.
  • [3] Pantos, R. and May, E. W., “HTTP Live Streaming”, Informational Internet Draft, tools.ietf.org/html/draft-…, March 2011.
  • [4] Microsoft, “IIS Smooth Streaming Transport Protocol,” www.iis.net/community/f…, September 2009.
  • [5] Adobe, “Adobe HTTP Dynamic Streaming,” www.adobe.com/products/ht….
  • [6] 3GPP TS 26.247: "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP".
  • [7] ISO/IEC 23009-1:2012, “Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats”, April 2012.
  • [8] ISO/IEC 14496-12:2008/DAM 3, “Information technology – Coding of audio-visual objects – Part 12: ISO base media file format – Amendment 3: DASH support and RTP reception hint track processing”, January 2011.
  • [9] ISO/IEC 14496-12, “Information technology – Coding of audio-visual objects – Part 12: ISO base media file format”, 2008.
  • [10] ITU-T Rec. H.222.0 | ISO/IEC 13818-1, “Information technology – Generic coding of moving pictures and associated audio information: Systems”.