CMAF调研分析

标签:无 2731人阅读 评论(0)
分类:

简介

CMAF,全称Common Media Application Format,是一种媒体容器标准。由微软、苹果联合MLBAM、思科、Akamai和Comcast在2016年2月向动态图像专家组(MPEG)提出,并在2017年7月被批准成为国际标准。

CMAF是一种可扩展的编码标准,通过指定一致的媒体包装和加密来实现内容和设备之间的互操作性。它与已经使用了多年的fragmented mp4(fMP4)密切相关。CMAF被设计用于兼容多种流媒体协议,包括HLS和DASH。将一种格式提供给多个目标可以大大降低视频编码,打包和存储成本。通过增强内容的可缓存性,CMAF也可以降低传输成本并提高QoE。

CMAF本身并没有减少延迟。它提供了低延迟模式,其中媒体段可以被分成更小的块。

image.png

发展趋势

视频容器为视频文件添加时间信息或其他的一些额外的元数。在CMAF出现以前并没有统一的视频容器标准,常见的视频容器示例如下,苹果的HTTP实时流传输(HLS)协议将数据封装成MPEG-2传输流(.ts),而MPEG-DASH使用MPEG-4容器(fMP4或.mp4)。

容器不同意味着即使最终播放的实际媒体内容相同,由于不同的封装格式,需要创建不同的封装格式版本。同一个视频文件用不同的格式存储,这些不同格式的文件会争抢同一个服务器资源,从而发生相同内容、不同格式之间竞争的情况,造成了无端的资源浪费,降低整体传送效率。具体如下图所示:

       

image.png

     

而CMAF是一个标准化的容器,对于现有编码格式不会有任何改变,即不会影响现有视频的编码技术。 在具体视频文件传输过程中,比如是HLS、DASH等格式的文件,就用m3u8、mpd等播放列表到CMAF容器中取所需要的视频内容,再将其组合成所需要的整块视频文件。CMAF中的视频内容只用一种格式存储了一份统一了视频内容格式,同时又允许m3u8、mpd等不同播放列表的存在。具体如下图所示。

       

image.png

    

 

虽然CMAF的好处很明显,但仍有许多传统设备无法获得更新以支持基于CMAF的内容播放。统一视频容器(封装格式)从而减少传输存储成本对视频服务提供商而言,具有巨大诱惑,限制CMAF发展的主要原因在于旧设备的不支持。

与流式传输协议的关系

       

image.png

image.png

CMAF是为规范化容器格式而诞生的,HLS、MPEG-DASH、HDS等是常见的流式传输协议。

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

相比之下,流传输协议是服务器和播放端之间传送频的规定。这些协议指定并使用容器格式,但也包含其他元素,如媒体文件清单(播放列表)。

在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的通用格式(CMAF)之前,一直是需要提供两种版本才能服务所有设备。

CMAF兼容HLS、MPEG-DASH等多种自适应流媒体协议。可以通过HLS协议中指定的M3U8索引文件或MPEG-DASH中指定的mpd来到CMAF容器中取所需要的视频内容,再将其组合成所需要的整块视频文件。

 

CMAF系统模型

CMAF系统模型示意图如下:

       

image.png

     

  • CMAF序列(CMAF Tracks)包含存储在CMAF指定的容器中的编码的媒体样本,包括音频,视频和字幕, 由一个CMAF头片段和其后的包含媒体样本的CMAF切片组成。CMAF序列包含存储在CMAF指定的容器中的编码的媒体样本,包括音频,视频和字幕,源自ISO基本媒体文件格式(ISOBMFF)。

  • CMAF切片(CMAF Fragments)可以独立解码和解密,并结合相关的CMAF头文件。

  • CMAF交换集(CMAF Switching Sets)包含可以在CMAF片段边界处切换和拼接的备选CMAF序列,以不同的比特率和分辨率自适应地流传送相同的内容。

  • CMAF选择集(CMAF Selections Sets)包含选择替代内容的可选CMAF切换集,例如,不同的语言或角度,可选的编码,或不同的编解码器。

  • CMAF可寻址媒体对象(CMAF Addressable Media Objects)被指定用于CMAF序列存储和传送,包括CMAF Chunks(小于CMAF切片),CMAF Segments(一个或多个CMAF切片)和CMAF Tracks Files(一个完整的CMAF Track)。

  • CMAF假设模型(CMAF Hypothetical Reference Model)定义了CMAF文件如何在CMAF播放器中传递,组合和同步CMAF序列,且允许任何兼容的实现,包括广播和MPEG-DASH自适应流媒体。  

CMAF文件组织如下:

       

image.png

     

可以看出,CMAF将每个切片分成了更小的chunk单位,每个chunk结束后可以直接播放,可以实现降低延迟的功能。

CMAF特点解析

  • 通用加密性

CMAF对在不同的保护设备下不同的DRM系统使用通用性加密。与标准HTML5 API兼容,增强了应用程序的互操作性。

  • 自适应性

CMAF定义可互操作的CMAF媒体配置文件。这些媒体配置文件指定解码和所需的编码和编码规则,以及确保动态自适应流所需的无缝跟踪转换的需求,交换集可以在CMAF切片边界处切换和拼接备选的CMAF序列,以不同的比特率和分辨率自适应地流传送相同的内容。

  • 可拓展性

CMAF是可扩展的。媒体配置文件可以通过引用标准的CMAF切片、序列和切换集来定义,这些格式在核心标准中定义,与媒体文件特定的编解码器以及ISOBMFF的编码相互约束。

  • 独立性

CMAF切片的编码和解码CMAF媒体资料独立于传输方法,可以独立解码和解密。

  • 低延时性

CMAF把每个切片切成更小的chunk单元,因此编码器可以在完成一个chunk单元后就传输给CDN和播放器去处理。既可以保证极低延时的传输,同时还不影响CDN缓存的效率,CMAF可以同时储存多种协议的播放列表,所以CMAF大大降低了编码和存储成本、提高了CDN的缓存效率,从而降低延时。

  • 无缝切换性

CMAF交换集控制各种单向的缓冲和译码器开关,使内容可以在大多数的设备和浏览器中无缝切换。

  • 兼容性

CMAF可以在数以亿计的网络设备上应用,例如Web浏览器中的播放器,或设备自带的播放器。该模型允许使用任何兼容的实现,包括广播和MPEG DASH自适应流媒体。

参考

  1. https://cloud.tencent.com/developer/article/1346159

  2. https://cloud.tencent.com/developer/article/1051357

  3. http://www.sohu.com/a/259122079_100206743

  4. https://www.theoplayer.com/blog/how-cmaf-will-influence-the-online-streaming-industry

  5. https://cloud.tencent.com/developer/article/1167037

  6. http://www.cww.net.cn/article?id=421535

  7. https://bitmovin.com/what-is-cmaf-threat-opportunity/

  8. https://drakeguan.org/blog/2017/03/video-streaming-formats-war-is-not-done-yet/

  9. https://cloud.tencent.com/developer/article/1358728


查看评论

暂无评论

发表评论
  • 评论内容:
      
    个人资料
    文章分类
    发表时间
首页
团队介绍
发展历史
组织结构
MESA大事记
新闻中心
通知
组内动态
科研成果
专利
论文
项目
获奖
软著
人才培养
MESA毕业生
MESA在读生
MESA员工
招贤纳士
走进MESA
学长分享
招聘通知
招生宣传
知识库
文章
地址:北京市朝阳区华严北里甲22号楼五层 | 邮编:100029
邮箱:nelist@iie.ac.cn
京ICP备15019404号-1