数字电影中的MXF文件解析

数字电影中的MXF文件解析
沈涛;顾沛峰;徐加军
【摘要】随着数字电影的飞速发展,数字电影发行包所采用的MXF打包格式正在被越来越多的人所熟知.本文介绍了MXF文件的基础知识和组织结构,并结合作者的实践经验介绍了MXF文件的一般分析方法,以供数字电影相关从业人员参考和研究.
【期刊名称】《现代电影技术》
【年(卷),期】2010(000)006
【总页数】4页(P15-18)
【关键词】数字电影;klv;mxf;元数据
【作者】沈涛;顾沛峰;徐加军
【作者单位】上海文广科技(集团)有限公司研发中心;上海文广科技(集团)有限公司研发中心;上海文广科技(集团)有限公司研发中心
【正文语种】中文
随着科学技术的发展,电影的数字化进程正在加速。

与传统电影相比,数字电影最大的区别是不再以胶片拷贝形式发行,而换之以数字文件形式,通过网络、卫星直接传送到影院、家庭等终端用户。

根据美国《DCI数字影院规范》的规定,数字电影包 (DCP)采用MXF打包格式。

MXF(Material eXchange Format素材交换格式)是SMPTE(美国电影与电视工程师学会)组织定义的一种专业音视频媒体文件格式。

相比其他格式,具有更好的扩展
性、兼容性和互操作性,主要应用于影视行业媒体制作、编辑、发行和存储等环节。

本文先介绍了MXF格式的一些预备知识,然后详细研究了MXF文件的组织形式,重点研究元数据和加密数据的解析,最后简单阐述MXF文件如何制作成DCP包。

要想理解MXF文件的格式,必须先了解相关的基础知识,下面介绍几个常用的概念。

UL(Universal Label)是ISO/ITU管理的一个可变长度的标签,对于SMPTE组织来说,只能使用16字节固定长度的标签,并且前4个字节为0x06 0x0E 0x2B 0x34。

通用标签用来标识特定的对象实体。

UMID(Unique Material Identifier),MXF用它来为视音频素材提供一个全球唯一
的识别码。

UMID可以被简单地当作一个单独的32字节的数据。

为了提供全球的唯一性,这个字节串是由12字节的通用标签 (UL)、1个字节的长度标识、3个字节的瞬时号码和16个字节的素材码组成。

KLV代表键值 (key),长度 (length)和取值(value),它起源于最初的程式化概念。

KLV做为一种连续的、关联的包含分段信息的数据包已被使用多年,它提供了一种
分割用户数据和确认用户数据类型 (key)的方式。

MXF文件是不同类型的连续的KLV序列的组合。

KLV的结构非常灵活,它除了简单的 keylength-value的结构外,还支持KLV组的
数据封装形式,包括各种集 (Sets)和包 (Packs),这样,可以在表示某些相关数据的时
候尽量减少信息的重复。

在MXF文件中,用的比较多的是本地集 (Local Sets)这种KLV组,如图1所示。

在这种KLV结构中,可以用2字节的本地标签 (Local Tag)来代替16字节的UL Key形成新的KLV结构,这些相关的新KLV结构的集合组成了最外层KLV的value 部分。

当然,这样的话开发者还需要另外提供一张Local Tag到UL Key的映射表。

“强引用(Strong Reference)”是指对于任何元数据组用UUID使相同变量的元
数据以同一ID顺序相连。

MXF使用有序排列规划,它希望各数据立即相互连接并
排序,并且这种连接是一一对应的,MXF头部元数据使用强引用将各个相关的KLV Set相连接。

“弱引用(Weak Reference)”是使用UUID连接相对独立的数组,这种连接往往是多对一的关系。

在MXF文件中,它可以视为文件中或者文件外的一个“全局定义”。

MXF文件通常被视为一种“容器”文件格式,也就是说MXF文件格式与内容数据的格式无关,这得益于MXF底层使用了KLV三元组编码方式。

MXF文件通常包含文件头、文件体和文件尾三个部分,如图2所示。

文件头 (The File Header)必须存在于每个MXF文件的起始位置,并且由头部包(Header Partition Pack)和头部元数据 (Header Metadata)组成。

头部包描述了头部元数据所占的字节数(HeaderByteCount)、操作模式(OperationalPattern)等一些重要信息,需要指出的是,MXF文件内部结构根据不同的应用场景可以有不同的复杂度,并用操作模式这一属性加以限制,数字电影使用的是最简单的OPAtom模式。

头部元数据分为两种:结构化的 (Structural Metadata)和描述性的 (Descriptive Metadata)。

前者是MXF文件结构的组成部分,后者只是作为“插件”来描述文件中的某些内容。

头部元数据是由一系列带ID的KLV set结构的数据组成的,他们之间通过强引用相互连接起来。

头部元数据的结构如图3所示。

从图中可以看到,头部元数据的起始位置是起始包 (Primer Pack),它的作用是提供local set中2字节的Local Tags到16字节的UL的映射,并且保证下面所有在set中出现的Local Tag的唯一性。

序言集 (Preface Set)结构体是对后面内容的总括性的描述,具体包括:版本号;修改者的信息(Identification),如公司名、产品名、产品版本等等;本文件中所存储的内
容 (ContentStorage);内容容器的类型 (如音频、视频等);描述性元数据(DMSchemes)。

在MXF文件中,为了能够成功捕获其中的图像数据和声音数据,必须存在一种轨迹
数据(T rack),它被用来描述图像和声音的起点和终点。

MXF对文件中的每个部分
都采用时间线轨 (Time-LineTrack)的概念,实体内容和元数据的分段都挂在一个虚
拟的时间轴上。

素材包 (The Material Package)就是用于指示输出时间轴,并且管理各个片段的同
步和播放顺序的元数据结构。

具体来说,素材包包含了有起始位置和帧率信息的轨迹数据,一份轨迹数据包含了一
个场景 (Sequence),场景定义了持续时间 (Duration),一个场景被划分成一个或者
多个片段 (SourceClip),每个片段都通过SourcePackageID(实际是该片段的UMID值)和SourceTrackID这两个值对应于一个文件包 (SourcePackage)中的一个轨迹,并且指明了需要的数据在所对应轨迹中的起始位置和持续时间。

文件包 (SourcePackage)是用来描述内容容器(EssenceContainer)的,它的结构和素材包类似,一个文件包通过UMID对应于一个内容容器。

文件包还会引用一个描述子 (Descriptor)用来描述内容容器中音视频数据的具体信息,如视频的分辨率、
宽高比、位深,音频的采样率、比特深度、声道数等等,这些都是解码时的必要参数。

这样,通过这种方式,素材包的时间轴上的每个片段都可以找到自己对应的文件包和
其中的轨迹数据,直到遇到SourcePackageID值为0的Source-Clip,则表示所有
的片段都已经找到。

在头部元数据的尾部,通常情况下我们都会加上一些KLV填充项来表示数据填充,这样做的作用如下:
1、在不改变头部元数据整体大小的前提下,允许修改元数据中某些可变长的字串。

2、可在填充处根据需要来插入索引表。

文件体 (Body Partition)紧跟在文件头之后,是由一个或者多个内容容器组成 (对于OPAtom操作模式,只允许存在一个内容容器)。

音视频数据被分割且KLV编码后依次放入内容容器中,数据分割的方法很灵活,MXF支持以帧、片段或者自定义的方式进行KLV编码,编码后的数据称为Edit U-nit(可编辑单元),最常用的是以帧为单位进行打包(Frame Wrapping)。

音视频数据分加密和未加密两种,如果是未加密数据,解析的时候只要将KLV解码就可以得到需要的数据并送给解码器。

如果数据是加密的,则要先将数据解密后才能解码。

根据DCI规范的规定,内容加密要使用AES(Advanced Encryption Standard高级加密标准)算法,并使用128位的密钥和CBC(Cipher Block Chaining密码分组链接)模式,且需要用一种称之为Encrypted Triplet(加密三元组)的KLV pack结构来存储密流和加密信息。

如图4所示。

为了更好地理解解密的过程,我们先简单介绍下AES-CBC算法。

AES是一种对称加密算法,就是说它加密和解密所使用的密钥是同一把,对于128bit的密钥,加密长度必须是16字节的整数倍,不足16字节的部分要填充后加密。

不管是加密还是解密,除了密钥,还需要一个16字节的IV(初始化向量)作为输入参数用来进行异或运算。

在数字电影中,IV是可以从文件中读取的,而密钥 (又称内容密钥)需要加密后传输给最终的播放设备。

在Triplet结构中,我们重点关注如何找到加密的信息以及如何进行解密。

其
中,Plaintext Offset参数指出了加密的起始位置,简言之,在原始明流中,Plaintext Offset之前的数据存放时不会加密,因此,未加密部分 (Plaintext)的大小就是Plaintext Offset。

Source Length指的是原始明流的总长,其长度是Plaintext和Ciphertext(加密部分)的长度之和。

这样,我们就可以很容易地找到加密数据的起始点Ciphertext。

DCI规范指出,在Triplet中,需要有一种机制来验证密钥的正确性,16字节密文checkbuf就是起这个作用的。

在每次解密前,需要先将checkbuf里的数据解密,并和已知的校验用明文比较,来验证内容密钥的正确性,如果验证通过,再把 Ciphertext 和填充数据一起送到解密模块进行解密。

需要注意的是,解密后的数据必须要去掉填充才可以送给解码模块,填充数据大小计算方法如下:
填充大小=长度5-32-Source Length
文件尾 (The File Footer)是由尾部包 (Footer Partition Pack)和索引表段 (Index Table Segments)组成的,索引表提供了一种从Edit Unit到文件偏移量的转换机制,由于每秒Edit Unit的个数(edit rate)可以从头部元数据中获得,因此我们可以很方便地计算出某个播放时间点在文件中的偏移位置。

DCP(数字电影包)在发行的时候,除了音视频MXF文件,还需要一些描述文件,有CPL(CompositionPlaylist播放列表)、PKL(Packing-List打包列表)、ASSETMAP(资产映射表)和Volume Index(卷索引)。

CPL会包含一组按照播放顺序排列的本(Reel),每个本中的音视频都有一个UUID 号,对应于MXF文件头部元数据中的素材UMID后16字节;PKL会把CPL中的UUID值对应到具体的文件名,并且会给出文件的大小的SHA1校验值;最后,所有的文件资产都会汇总到ASSETMAP中。

在数字电影发行和放映阶段,使用MXF格式的节目文件和基于MXF的文件打包技术有其重要意义。

目前,全球的数字放映都在力推MXF格式,我国的1.3K数字电影为了与国际接轨,也采用了这种打包格式。

可以说,了解MXF格式已经成为数字电影技术人员必修的一门课程。

【相关文献】
[1]DCI数字电影系统规范V1.2
[2]SMPTE 336M-2001 Television Data Encoding Protocol using Key-Length-Value
[3]SMPTE 377M-2003 Television Material Exchange Format(MXF)File Format Specification
[4]SMPTE 379M-2003 Television Material Exchange Format(MXF)M XF Generic Container
[5]SMPTE EG41-2003 Material Exchange Format(MXF)Engineering Guideline(Informative)
[6]SMPTE 390M Specialized Operational Pattern Atom(Simplified Representation of a Single Item)
[7]SMPTE,Proposed 429-3.Packaging-Sound and Picture Track File
[8]SMPTE,Proposed 429-6.Packaging-MXF Track File Essence Encryption
[9]SMPTE,Proposed 429-7.Packaging-Composition Playlist
[10]SMPTE,Proposed 429-8.Packaging-Packing List
[11]SMPTE,Proposed 429-9.Packaging-Asset Mapping and File Segmentation。