MXF素材文件交换格式深入研究.docx

MXF素材文件交换格式深入研究.docx

《MXF素材文件交换格式深入研究.docx》由会员分享，可在线阅读，更多相关《MXF素材文件交换格式深入研究.docx（11页珍藏版）》请在冰豆网上搜索。

MXF素材文件交换格式深入研究

MXF素材文件交换格式深入研究

     【摘要】DCI规定数字电影需采用MXF封装音视频等节目素材内容。

为了深入理解MXF基础原理，本文研究了MXF素材文件交换格式，详细介绍了MXF文件的物理结构和逻辑结构，并介绍了MXF中如头部元数据、索引表、操作模式、字节对齐等重要概念。

     【关键字】MXF分区索引表随机索引包头部元数据操作模式KAG

     前言

　　根据DCI规范，数字电影数据包（DigitalCinemaPackage，DCP）中音视频等素材数据采用素材文件交换格式（MaterialExchangeFormat，MXF）进行封装［1］。

素材文件交换格式主要用于音视频素材的交换。

音视频节目通常是由在时间线上同步的流式音视频素材组成的，为了交换和存储的方便，需要将这些素材用数据文件的形式进行表示，基于此目的，SMPTE377M标准定义了素材文件交换格式（MXF）［2］。

　　由于MXF技术是数字电影技术中的一项重要技术，有必要深入理解MXF的基础原理。

MXF文件的基础单元KLV结构及装载节目内容的通用容器已经在《KLV编码协议及通用容器——MXF基础原理详解之一》文中进行了介绍，在此基础之上，本文将详细介绍MXF文件的物理结构和逻辑结构，并深入研究MXF中如头部元数据、索引表、操作模式、字节对齐等重要概念。

     1、MXF文件的物理结构（码流结构）

　　MXF文件根据所含内容可分为3个部分：

文件头（FileHeader）、文件体（FileBody）和文件尾（FileFooter）。

包含素材数据（EssenceData）的素材容器（EssenceContainer）全都存放于文件体（FileBody）中。

在文件体中可含1个或多个素材容器。

文件头是对整个MXF文件的综合描述，包括对文件体内的素材及其容器以及素材之间的同步和播放关系等的描述和控制。

文件尾是MXF文件的终止部分，可包含索引表、控制信息和元数据。

这种分类方法将控制信息及元数据与素材内容区分开，而文件头通常比较小，单独分析其中的参数，就可了解MXF文件中所含节目内容的各项特征。

简单的MXF文件基本结构如图1所示。

图1简单MXF文件的数据结构

　　若MXF文件中有多个素材容器，需将各个素材容器进行分隔。

另外，为了随机索引、访问及文件的部分存储、恢复的方便，有时需将素材容器分割成不同的小块。

这些小块在内容上逻辑连续，但是物理存放位置上不一定连续。

　　为此，可将MXF文件划分成多个分区（partition），共有三类分区：

头部分区（HeaderPartition）、主体分区（BodyPartition）和尾部分区（FooterPartition）。

1个MXF文件可含1个头部分区、0个或多个主体分区、0个或1个尾部分区。

头部分区是在MXF文件中唯一必须要出现的分区。

　　每个分区都是由分区包（partitionpack）开头，紧随其后可能有头部元数据（HeaderMetadata）、1个索引表（IndexTable）的部分或全部、1个素材容器的部分或全部。

分区包是1个KLV包，说明分区包本身的信息及整个分区的信息，包括分区类型、该分区在文件中的位置，以及所包含的头部元数据、索引表、素材容器、操作模式（OperationalPattern）等信息。

其中操作模式限定文件的复杂程度。

　　在头部分区内必须包含头部元数据，在尾部分区内不得包含素材容器，从尾部分区开始表明MXF文件内没有素材内容。

在头部分区之前，有的MXF文件可能会有Runin部分用于伪装MXF文件为别的文件类型。

尾部分区之后，可能会有随机索引包（RandomIndexPack，RIP）用于对各个分区的索引。

除Runin部分外，MXF文件是由一系列KLV包组成的。

　　各分区的结构如图2所示。

图2各个分区（partition）的结构

图3含两个素材容器的MXF文件

　　1个MXF文件中可含有1个或多个素材容器，并可分割成多个小块，分别存放于除尾部分区外的头部分区或主体分区内，每个素材容器都有1个唯一标识符BodySID。

每个素材容器又可创建相应的索引表，每个索引表也有相应的唯一标识符IndexSID，索引表也可分割成小块存放。

在素材容器元数据（EssenceContainerData）中，将素材容器的BodySID和相应索引表的IndexSID相互关联起来。

图3所示即为含有两个素材容器及相应索引表的MXF文件，其中素材容器1还被分割成a、b两个部分，分别存放于头部分区和1个主体分区内，另外2个主体分区，1个仅存放了素材容器1的b部分的索引表，1个存放了素材容器2。

     2、索引表和随机索引包

　　每个素材容器都可创建一个相应的索引表，用于加速定位时间线上的每一个编辑单元中的每一个元素，比如视频元素、音频元素。

索引表的功能是将每一个编辑单元中元素的时间偏移，转换为所在素材容器中的字节偏移。

索引表可位于MXF文件的任意分区内，可集中放在某个分区内，也可分散放在多个分区内。

由于索引表中每个元素的字节偏移是相对素材容器起始位置的字节偏移，因此索引表放置位置的改变，并不影响其中元素偏移值的改变。

有了索引表，就可以随机访问任意编辑单元的素材内容，便于任意图像帧素材内容的删减、插入、修改及播放处理。

　　在1个素材容器的每个内容包（CP）中，最多可能会有5个数据项，其中包括系统数据项、图像数据项、声音数据项、字幕或辅助数据项、复合数据项。

每个数据项最多可能会有127个元素，每个元素可能是恒定码率编码（CBE），也可能是可变码率编码（VBE）。

　　因此，为了准确定位每个素材元素，索引表分为3个层次进行索引：

索引入口（IndexEntries）、片段偏移（SliceOffsets）和元素入口（DeltaEntries）。

索引表索引的层次结构如图4所示。

图4索引表索引的层次结构

　　索引入口（IndexEntries）表示素材容器中每个编辑单元的起始位置，每个索引入口都有其相对于素材容器起始位置的偏移量（StreamOffset）。

　　片段偏移（SliceOffsets）是用于标识可变码率编码（VBE）的。

只有存在VBE元素时，才会有片段。

每个片段（Slice）以0个或多个CBE元素开始，以1个VBE元素结束。

在码流中，用片段偏移量（SliceOffset）表示每个片段相对于所在编辑单元的起始位置的字节偏移量。

　　元素入口（DeltaEntry）是用于定位每一个元素的，每个被索引到的元素都有一个元素入口。

在码流中，用元素偏移量（ElementDelta）表示每个元素相对于所在片段（Slice）的起始位置的偏移量。

　　一般情况下，每一个元素在素材容器中的偏移量是以上三个量相加，即编辑单元偏移量（StreamOffset）+片段偏移量（SliceOffset）+元素偏移量（ElementDelta）。

但对于MPEG这类带有后向预测的压缩标准，压缩后码流中的图像顺序与播放顺序可能会不一致，这样就会涉及到每帧的时序问题。

在以上三个量相加之前，应将播放顺序转换为图像在码流中的顺序。

　　由上可知，索引表中只能提供每个元素相对于素材容器起始位置的字节偏移量，因此，要在MXF文件中定位每个元素，还需要首先定位每个素材容器的起始位置。

　　随机索引包（RandomIndexPack，RIP）中提供了每个分区相对于MXF文件开头的字节偏移量及每个分区内所含素材容器的标识符（BodySID）。

因此，可根据RIP，首先找到含素材容器的分区，然后找到素材容器的起始位置，再根据相应的索引表查找每个元素。

     3、头部元数据（HeaderMetadata）的基本结构

图5头部元数据结构

　　MXF文件中的头部元数据主要分为两类：

结构元数据（structuralmetadata）和描述元数据（descriptivemetadata）。

结构元数据主要用于将文件的各个部分结合起来，定义文件的基本结构、描述并控制各种类型的素材及其在时间线上的相互关系。

描述元数据描述MXF文件中除结构元数据之外的信息，比如对场景的描述，采用插入机制嵌入MXF文件中。

　　头部元数据的基本结构如图5所示。

首先从主包（PrimerPack）开始，紧随的是序言集（PrefaceSet），然后是各种元数据集（MetadataSet），最后可能会有用于字节对齐的填充KLV项（KLVFILLItem）。

每个元数据集中所含数据项目都很多，为了节省字节开销，其数据项基本都采用KLV编码中的局部集（LocalSet）编码，一般采用2字节的局部标签（LocalTag）替代各个数据项的16字节的ULKey，长度部分一般采用2个字节来表示。

这些局部标签只是在MXF文件相应的分区内有效，MXF文件的外部设备必须通过相应的映射文件，才能确定它们的具体含义。

主包（PrimerPack）的作用就是提供局部标签与16字节的ULKey的映射关系。

序言集的作用相当于一篇文章的摘要，能够简要地告诉解码器整个MXF文件中所含的素材的复杂程度、类型以及MXF文件的组织及复杂程度，解码器可以据此预判自己是否有能力处理该MXF文件。

各种元数据集描述了MXF文件所含素材及其容器的各种特征信息、各种素材在时间上的相互关系及同步播放关系。

　　由于头部元数据具有描述、控制各种素材的重要作用，因此，头部元数据除在头部分区内出现外，可能还会在主体分区和尾部分区内出现，以便部分存储或恢复MXF文件。

     4、分区/MXF文件的状态

　　有的MXF文件是边录制边生成的，在刚录制的时候，头部元数据有些参数可能还不清楚，比如总共有多少帧图像等等，这些参数只有在文件生成完毕的时候才知道。

因此，每个分区根据完成参数的情况，可以分为不同的状态：

开放（open）或者封闭（closed），完善（complete）或不完善（incomplete）。

　　开放是指分区内的信息是正确的但可能会有缺失，不到最后完成文件时是不知道的。

比如，录制设备在开始制作MXF文件时，原以为只有1个图像轨迹和1个音频轨迹，可是在录制过程中发现，另外还有一个声音轨迹，则这个声音轨迹的信息在开放的头部元数据中就没有描述。

封闭是指分区内的元数据信息已经是最终版本，该有的信息都已经有了。

所有封闭分区内的元数据的信息都应该是一样的。

因此，尾部分区中的头部元数据应为封闭的。

完善是指头部元数据中必须或者最好出现的属性在文件中都有，且都正确；非完善是指头部元数据最好出现的属性缺失。

　　当MXF文件中至少有1个分区含有封闭且完善的头部元数据时，该MXF文件就被称为“封闭且完善”的MXF文件。

     5、MXF文件的逻辑结构

　　如前所述，从物理结构即码流结构来看，MXF文件可分为文件头、文件体、文件尾，也可分为头部分区、主体分区、尾部分区、随机索引包，每个分区除分区包（partitionpack）外，可含头部元数据、索引表、素材容器等。

　　另外，还可从逻辑角度分类MXF文件结构。

MXF文件的逻辑结构是由MXF文件中的头部元数据而不是字节码流定义的。

元数据在字节上是一个紧邻一个存放的，但是元数据之间通过引用关系，形成了具有一定层次结构的逻辑模型。

图6头部元数据包（HeaderMetadataPackage）

　　MXF文件的逻辑模型是一种基于对象的数据结构，主要由头部元数据中的结构元数据定义。

结构元数据主要分为两类，一类是与时间特性有关的结构元数据包（StructuralMetadataPackage），一类是与素材或素材容器的特征参数相关的描述符（Descriptors）。

每个结构元数据包（StructuralMetadataPackage）由1个或多个轨迹（Track）组成；每个轨迹是一段具有起始时间点、编辑速率的时间线，由1个具有一定持续时间的序列（Sequence）组成；每个序列又由1个或多个源片段（SourceClip）组成。

包（Package）、轨迹（Track）、序列（Sequence）、源片段（SourceClip）通过UUID的相互引用及包含，而形成如图6所示的逻辑模型。

　　结构元数据包（StructuralMetadataPackage）根据用途不同，又可分为素材包（MaterialPackage）、顶层文件包（TopLevelFilePackage）和低层源包（LowerLevelSourcePackage）。

顶层文件包通常为文件体中存储的数据，或者文件体中所含音视频等流媒体的输入时间线，并与相应的素材容器相关联。

顶层文件包中的每一个轨迹分别对应内容容器中不同的类型，并有相应的描述符描述素材的特征信息，如像素、采样率、画幅比、声道数、比特数等。

素材包通常为文件的输出时间线，确定在播放或使用时文件中哪个内容容器中的哪些内容被播放，以及这些播放内容如何同步。

素材包中的源片段通过UUID引用，链接到顶层文件包的某个轨迹。

而素材容器元数据（EssenceContainerData）中，又通过顶层文件包的UUID，将顶层文件包和具体的素材容器及相应的索引表相互关联起来。

低层源包则主要包含文件如何创建、存储介质等信息。

素材包、顶层文件包、低层源包、素材容器等之间的逻辑关系，如图6所示。

图7复杂MXF文件的物理结构

图8复杂MXF文件的逻辑结构

　　图7和图8所示为一个较为复杂的MXF文件［3］。

该文件是由DV拍摄的，具有立体声道，并在后期制作过程中又加入了2个声道。

DV拍摄的图像和2个声道放置于一个素材容器中，后期加入的2个声道放置于另一个素材容器中。

这两个素材容器分别存放于不同的分区中，其生成的MXF文件的物理视图如图7所示，其逻辑视图如图8所示。

在逻辑视图中可看到作为输出时间线的素材包与作为输入时间线的顶层文件包中的链接关系。

     6、操作模式

　　在不同的应用中，MXF文件的结构和复杂程度不一样。

为了最大化MXF文件的互操作性，MXF采用操作模式（OperationalPattern）来限定文件的复杂程度。

操作模式从两个维度来定义文件的复杂度，如图9所示。

图9操作模式的维度

　　一个维度是项目复杂度（ItemComplexity），这个维度主要是说明在输出时间线上所含的源片段的个数及其与输出时间线的关系。

这个维度分为3个等级：

单个项目（SingleItem）、播放列表项目（PlaylistItem）和编辑项目（EditItem）。

每个素材文件包即输出时间线上只有一个片段（SingleMaterialPackageSourceClip），且其持续时间与顶层文件包中的一致时，其复杂等级为单个项目（SingleItem）；若输出时间线上有多个连续播放的片段，且每个片段的持续时间与相应的顶层文件包的一致，则其复杂等级为播放列表项目（PlaylistItem）；若输出时间线上有多个连续播放的片段，且每个片段的持续时间只为某个顶层文件包的某一部分，则其复杂等级为编辑项目（EditItem）。

　　另一个维度是包的复杂度（PackageComplexity）。

这个维度也分为3个等级：

单包（SinglePackage）、群包（GangedPackage）和轮替包（AlternatePackage）。

单包（SinglePackage）是指MXF文件中只有1个素材包，且素材包在输出时间线上每个时间点上只访问一个顶层文件包。

群包（GangedPackage）是指MXF文件中只有1个素材包，但素材包在输出时间线上每个时间点上可访问一个或多个顶层文件包。

轮替包（AlternatePackage）是指MXF文件中有2个或以上素材包，每个素材包在同一时间点上可访问1个或多个顶层文件包，比如，不同的素材包可为不同的语言版本。

     7、KAG

　　整个MXF文件除Runin部分外，全由一个一个的KLV包组成。

在有的应用中，为了方便存储或传输，有时希望某些KLV与某个字节边界对齐，这时可插入空的KLV填充项目（FillItem）来达到目的。

每个分区都可将某些KLV元素与KLV对齐格（KLVAlignmentGrid，KAG）进行对齐。

KAG定义了对齐线之间的字节数。

当KAG的值为“0”时，表明未定义对齐格尺寸；为“1”时，表明没有对齐格，即不用进行字节对齐；为“2~1048576”之间时，表明需要按相应的数值进行字节对齐。

KLV填充项目可能出现的地方如图2所示。

     小结

　　DCI规范规定数字电影需采用MXF进行封装打包。

为了深入理解MXF基础原理，本文详细介绍了MXF文件的物理结构和逻辑结构，另外还介绍了MXF文件中涉及的索引表、头部元数据、操作模式等重要概念。