演进中视频流媒体容器格式与传输协议

最近几年，在线视频行业发展十分迅速,无论是视频播放设备还是视频传输技术都在不断革新，从60英寸的UHD平面屏幕到平板电脑或者手机，从光纤网络到3G，4G的蜂窝网络技术，这些技术的革新使得流媒体视频制作人员要支持多种自适应流技术。

随着市场的竞争增加，利润率下降，行业中的公司必须将视频编码，打包，存储和交付成本缩减到最低限度，通常从两方面来满足。第一方面的技术是先进的编码器，这方面Apple公司对HEVC推动作用显著。与H.264相比，HEVC可以降低传输成本，同时提高观众的体验质量。第二个方面技术是Common Media Application Format（CMAF），是一种文件格式规范，可以打包支持多种自适应流技术，包括HLS和DASH。将一种格式提供给多个目标的效率可以大大降低视频编码，打包和存储成本。通过增强内容的可缓存性，CMAF也可以降低传输成本并提高QoE。

虽然新技术的出现会给行业发展带来很多的好处，但是，与旧设备或播放器的兼容性不容忽视。在一定时期内，新技术并非取代旧技术而是有益的补充。本文将向读者介绍视频封装打包（Format, Packaging）和分发协议（delivery protocol）方面近期的标准化技术，并讨论如何将新技术整合到视频流服务系统中，同时尽量保持与现有技术的兼容性。

1、编码器的演进

流视频其实就是关于编解码器，容器和协议的。如果一个视频文件没有经过压缩直接传输的话，即使是最快的互联网连接也无法实现传输。因此必须减小视频文件或实时视频流的大小，但同时保持尽可能多的质量。这也是压缩（也称为编码和转码）的由来。

多年来，AVC和H.264是在线视频的主要压缩技术或编解码器，但近年来，HEVC受到青睐，因为它可以实现以一半数据速率获得相同的视频质量。Figure 1中显示了各种压缩格式的质量和效率提升。

图1

HEVC涉及的许多实际编码技术与AVC相同，但做了多方面的扩展。例如，当搜索帧间冗余时，AVC呈现9个方向向量的选择，而HEVC提供33个向量的选择。 HEVC还可以提供更高质量的内容，如4K和高动态范围（HDR）视频。

图2

一般而言，HEVC能以大约一半的数据速率提供与H.264相同质量的视频，但这也会根据视频内容类型而定。例如，对于1080p流，发布者可能能够将数据速率从8Mbps降低到4Mbps而不会降低质量。

比特率的降低会对边缘缓存成本产生重大影响，因为当视频传递给最终消费者时，文件大小现在变小了。在某些情况下，例如通过4G传送到高分辨率平板电脑，这可以让观看者观看1080p流而不是720p流，从而提高整体体验质量。

与几乎能在任何地方播放的H.264不同，支持HEVC播放的领域还比较有限，目前，HEVC主要用于向智能电视和类似的OTT和STB设备以及4K或UHD内容提供视频。

2、流媒体容器格式和传送协议的演进

无论使用哪种编解码器压缩视频，该视频都需要格式或容器存储，还需要选择流式传输协议进行传送。我们将在下面的Streaming Protocols部分讨论协议的最新进展，这里先介绍容器格式和协议之间的关系。

简而言之，容器格式是文件头中的数据，它描述的是视频和相关元数据如何存储在文件中，就像扩展名为.MOV的文件是QuickTime文件；从技术上讲，这意味着它以QuickTime容器格式存储。虽然容器格式决定了文件兼容性和可播放性，但压缩后的视频和元数据构成了整个文件的绝大部分。容器格式实际上只取决于文件头中的几位数据。这也就意味着很容易从一种容器格式转换为另一种容器格式，前提是不以任何方式修改压缩视频或元数据，只更改文件头中的几位即可。

相比之下，流传输协议是服务器和播放端之间传送视频的规定。这些协议指定并使用容器格式，但也包含其他元素，如将在后面介绍的manifest files等。

在CMAF出现之前，各种流媒体协议使用了两种不同的容器格式。 Apple的HLS使用MPEG传输流容器格式（MPEG-TS或.ts），这种格式与有线和IPTV行业数十年相同。当HLS新出现时，是将每个流被分成称为segments的单独文件，每个segment具有.ts扩展名，即使是短电影或节目也会有成千上万个.ts文件，这使得文件传输复杂化并降低了缓存的有效性。后来，HLS更新为使用单个.ts文件，该文件的segments通过byte-range request进行检索，这些请求在较长文件中定义了谨慎的chunks。

所有其他基于HTTP的协议，包括Dynamic Adaptive Steaming over HTTP（DASH），都使用了更新，更灵活的分段MP4容器格式（fMP4或.mp4）。虽然可以为每个segment生成单独的fMP4文件，但DASH的默认操作模式是单个文件，其中通过byte-range request请求segment，从而简化文件传递并提高文件缓存的能力。

因为HLS使用MPEG2传输流容器，而DASH和其他HTTP技术使用Fragmented MP4文件，如果视频发布者想要访问所有设备，它必须打包并提供每个视频的两个版本 - 一个是HLS，一个是DASH。直到2016年苹果和微软合作并宣布了DASH和HLS的通用格式之前，一直是需要提供两种版本才能访问所有设备。我们将在后面介绍这个通用格式。

2.1 流媒体协议

容器格式是简单的元数据描述，详细说明数据如何存储在文件中，而流媒体协议定义了一个系统，通过该系统将视频传送给播放端。在过去十年左右的时间里，流媒体协议已经从RTMP（(Real Time Messaging Protocol）发展到HTTP，RTMP是用于Flash流传输的协议，而HTTP是HLS和DASH使用的协议，并且Microsoft的Smooth Streaming （MSS）和Adobe的HTTP-based Dynamic Streaming（HDS）也是基于HTTP协议。

RTMP到HTTP的发展有几个原因，首先，RTMP需要在播放器和服务器之间建立持久连接，这意味着除标准HTTP Web服务器外，还需要运行特殊服务器。因为流式服务器很昂贵并且只能处理有限数量的终端设备，使得成本提高。相比之下，基于HTTP的流式传输协议可以从标准Web服务器运行，不需要流式服务器。 RTMP也是Adobe许可的专有技术，可能会有与IP相关的问题。

RTMP数据包不能像HTTP数据包一样进行缓存，这会降低总体传输效率，并且RTMP数据包通常会被防火墙阻止，这是因为防火墙可以在没有流的情况下阻止潜在的查看者。最后，支持基于HTML5的浏览器级解决方案Flash已经要被弃用，更使得基于HTTP的传输方式成为最广泛兼容的解决方案。除了基于RTMP的流媒体的衰落之外，Flash的弃用导致Adobe HDS的使用减少，而至少对于基于计算机的交付而言Silverlight的弃用导致MSS的使用下降（MSS仍然用于提供游戏平台）。

但是，虽然RTMP已被HTTP作为传递协议取代，但它经常用于将流传输到云中以用于实时流应用程序以及其他系统到系统通信。这是因为RTMP是基于TCP的，因此它具有纠错功能和其他增强可靠性的特性

除了从RTMP到HTTP的过渡之外，为了能在大多数流媒体制作者所服务的各种连接带宽和播放平台上播放流媒体，流媒体协议已经从单个文件传输演变为多个文件的自适应传输。 HLS和DASH以及MSS都是基于HTTP的自适应流媒体协议，它们的工作方式也非常相似。

也就是说，它们都使用视频文件和manifest file的组合将视频从HTTP服务器传送到播放端。要开始播放时，浏览器中的播放器首先检索主清单文件，该文件指向所有质量级别的所有流的manifest file的位置。这些流级manifest file指向各个媒体文件中各个文件的segments或byte-range位置的位置。当播放期间带宽或其他条件发生变化时，播放器使用主清单文件来查找另一个流，允许播放器动态调整其检索的chunks或文件segments的质量和大小。

2.2 支持多种协议

实际上，大多数流媒体制作者必须使用多种协议来传送内容。 Apple设备都使用HLS，计算机上的许多OTT平台和基于浏览器的解决方案也是如此。 智能电视主要使用DASH，许多其他基于浏览器的计算机解决方案也是如此。 而像Xbox这样的老游戏平台仍然使用MSS。

当向特定用户分发优质内容时，文件加密和数字版权管理（DRM，digital rights management）使服务问题更加复杂。 具体来说，基于HTML5的交付的兴起意味着生产商可能需要支持多个DRM，例如用于iOS设备和Safari的FairPlay，用于Microsoft浏览器和游戏平台的PlayReady，用于Chrome和Android设备的Widevine，甚至可能是用于传输到智能电视，机顶盒或其他平台的额外的DRM。而加密，存储所有协议的排列和DRM会增加存储和传输成本。

2.3 JIT封包

用于最小化这些成本的一种技术称为Just-in-Time（JIT）或动态封包。简而言之，JIT打包是指基于服务器的技术，可以从一组实时流或VOD MP4流中工作，并根据请求播放的终端的特殊要求对这些流进行打包和加密。如图3所示。

图3

具体来说，上图左侧的一组通用文件打包成多个组，以用于不同的协议和DRM。如前所述，由于容器格式仅由文件头中包含的几位数据确定，因此JIT技术可以即时转换为正确的格式，并满足请求视频的客户端的特定需求。在较高的层面上，JIT技术允许生产者在原始服务器上存储单一格式，从而节省了打包和存储多种格式的成本。

除了封包之外，JIT技术还可以为不同的协议定制segment的大小。有些还可以管理中断期，或自行根据提前设置好的规则来执行操作，例如在传输到移动设备时，提供1080p流就毫无意义，因为观看者对720p和1080p之间是无法分辨的。

2.4 The Common Media Application Format (CMAF)

CMAF是分段媒体传送的标准，形式化为MPEG-A Part 19或ISO / IEC 23000-19。 具体来说，CMAF使用ISO基础媒体文件格式（ISOBMFF）容器，可以支持H.264，HEVC和其他编解码器。 CMAF仅定义媒体格式，而不定义manifest file的结构或内容，并且HLS播放列表（.m3u8文件）和DASH清单文件（.mpd文件）都可以检索CMAF格式的内容。

CMAF还简化了为多种语言提供隐藏式字幕的过程，这一直是一项复杂的挑战。一直以来，Apple使用基于文本的Web视频文本轨道（WebVTT）标准在HLS中隐藏字幕（Figure4），并可能继续使用它。

图4

DASH可以使用WebVTT，但也使用称为Timed Text Markup Language Profiles for Internet Media Subtitles and Captions或IMSC1，它不仅允许文本，还支持图像，如许多亚洲和中东语言或非拉丁语系的语言所要求的语言。（Figure5）。因此，CMAF支持WebVTT和IMSC-1格式。

图5

对于DRM，CMAF支持通用加密（CENC，Common Encryption），它可以将多个DRM合并到一个包中。CMAF还支持两种不兼容的加密模式，AES-128 Counter (CTR)和AES-128 Cipher Block Chaining CBC（CBC）。当CMAF最初推出时，Apple的DRM FairPlay仅支持CBC，而PlayReady，Widevine和许多其他DRM仅支持CTR，这导致了单个加密文件包在Apple和非Apple平台上无法同时播放。

随后，谷歌已将CBC纳入Widevine，而微软已承诺计划于2018年发布的PlayReady 4.0也将支持CBC。但是在短期内单个加密文件集仍旧很难在所有相关终端上播放。

3、典型的应用场景

实施任何新技术的挑战之一是它如何适应现有技术。考虑下面三种典型情形：

场景1 - 创建了一个新的移动应用程序，仅针对最新的iOS和Android手机。单个CMAF文件集能够支持所有目标终端。如图6所示，编码器输入单个文件，而输出CMAF ABR集，其中包含用于DASH的MPD文件和用于HLS的M3U8文件。它们被上传到CDN，从CDN可以将它们传送到设备并按原样播放。

图6

场景1.5 – 支持按次付费的订阅直播服务，比如现场音乐活动。用户只能购买特定的新设备和浏览器，或使用Apple TV的APP。为了支持所有可用的终端，部署了两个DRM; Widevine和FairPlay。如图7所示，具有HLS和DASH的manifest的单个CMAF文件集和CBC加密可以使用FairPlay for HLS和Widevine for DASH来支持所需的设备。

图7

显然，这两个应用程序仅支持一组有限的设备，这极大地限制了目标受众。下面是一个更现实的场景。

场景2 – 提供catch-up TV或订阅VOD服务，并且必须保留对现有设备的支持和向后兼容性，不仅要支持最新的iOS和Android设备，还要支持旧版本的设备和操作系统，以及一系列流行的，新旧的机顶盒和游戏设备，如Apple TV，Fire TV，Chromecast，Roku，Xbox，智能电视，连接蓝光播放器等。

图8

在这种情况下，CMAF只能服务于一定比例的目标客户，因此需要JIT解决方案才能实现全覆盖。CMAF将有助于限制JIT封装的负载，因为最流行的设备很可能是可以播放兼容CMAF的HLS和DASH的新设备，因此，只需要非常轻量级的manifest package，并且在缓存和CDN中使用更多共享视频片段的能力将提高整体传输效率和性能。

使用JIT打包解决方案可以扩展对未升级的旧设备的支持，并继续支持无法升级的旧设备。这可以确保观众数量不受限制，任何想要观看的人都可以在他们想要的任何设备上观看。

CMAF and JIT 协同工作

CMAF无法为所有终端提供服务，因为与CBC不兼容，而且许多终端都不会兼容（特别是游戏设备）。 而除了传统设备支持之外，DASH本身在实现方面存在差异，不同终端可能会阻止单一的manifest文件为所有DASH终端提供服务。 出于这些原因，JIT封包仍然是确保持续支持最广泛设备，并保持灵活性以支持更多设备的最有效方式。

显然，将CMAF格式文件传输给新设备的能力将提升服务器效率，并产生可提高服务器吞吐量和增强缓存的公共视频片段。 但是，对于绝大多数流媒体服务而言，CMAF更多地被认为是JIT封包系统中支持的格式，而不是它的替代品。

4、 结论

使用HEVC，可以在与AVC相同的带宽下获得更高的视频质量，或者以使用AVC的一半带宽提供相同的质量。使用CMAF，只需编码，打包和添加DRM一次即可访问大量的播放设备。虽然CMAF的好处很明显，并且基于HTML5的CMAF内容播放是未来发展的趋势，但许多公司仍旧必须继续支持与CMAF不兼容的旧设备，需要综合使CMAF和JIT封包技术。

参考资料：

AWS Elemental, Evolving Standards in Video Mastering, Packaging, and Delivery, Streaming media Spotlight Series, 2018.5