个标准之间的关系，然后分别介绍这三个标准的具体内容。
SMPET 377M定义的MXF文件主要包括文件头、文件体、文件尾3个部分，其中每个部分又是由SMPTE 336M所定义的一系列的KLV包组成，而文件体所携带的音视频素材信息装在SMPTE 379M所定义的通用容器中。因此，在介绍MXF文件格式之前，需要首先介绍KLV编码协议及装载素材（essence）的通用容器（general container，GC）。这三个标准的关系如表1所示。
表1 377M定义的MXF文件结构及与336M、379M标准的关系表
三、KLV编码协议介绍
SMPTE 336M标准定义了数据的交换协议——KLV协议。该协议与具体的应用或传输方式无关。
1、KLV编码协议概述
KLV协议编码的数据由3个部分组成：键值（Key）、长度（Length）、数值（Value）。键值是数据的标识符，长度表示数据的长度，数值表示数据本身。处理经过KLV编码的数据的设备如果无法识别某些数据的键值，则可根据长度值忽略相应长度的数值，继续处理下一个KLV包，因此在数据交换应用中具有很强的灵活性。
其中键值（K）是根据SMPTE 298M标准定义的通用标签（universal label，UL），由16字节组成，采用基本编码规则（basic encoding rules，BER）编码。这16个字节分别定义了数据所属的标准、结构、版本、具体数据含义及数据类型等等，是数值(V)部分数据项的唯一标识。这些UL是在相应的SMPTE标准中注册过的。
对于长度(L)字段的编码，也是采用BER编码，分为短型（shortform）和长型（longform）两种形式。短型的长度字段只有一个字节，该字节的bit8为0，bit7~bit1表示数值部分的字节长度。长型的长度（L）字段由多个字节组成，第一个字节的bit8为1，bit7~bit1表示长度（L）字段中其余字节数，后续字节的值表示数值（V）部分的字节个数。一般数值（V）部分的长度小于128字节的用短型表示，大于128字节的用长型表示。比如，L=38，以短型BER编码为：00100110；L=201，以长型BER编码为：10000001 11001001。
2、KLV编码的数据类型
键值（K）的第5字节定义KLV协议编码的数据类型，共有4种数据类型：词典（dictionaries）（0x01）、集/包（sets/packs）（0x02）、包装器/容器（wrappers/containers）（0x03）、标签（labels）（0x04）。 词典所定义的数据是单个数据项。
集/包定义的是多个经过KLV编码的单个数据项的组合。每一个集就是一个KLV包，这个KLV包的数值（V）部分又由多个单个数据项或者集/包组成，这称之为KLV递归；每一个包（pack）也是一个KLV包，其数值（V）部分只能由多个单个数据项组成，不能再包含别的集/包，即在包（pack）中不允许KLV递归。S336M标准对集（set）中的KLV递归层数没有，但是S377M标准所定义的MXF文件中KLV递归，如果实在需要递归的，通过引用来替代，以此降低MXF文件的复杂程度。
包装器/容器定义的也是多个经过KLV编码的单个数据项的组合，与集/包类似，但有不同：1）所携带的数据与集/包不同。包装器/容器内主要是音视频素材数据，而集/包所携带的数据主要是描述或说明音视频素材及其关系的元数据。2)其KLV结构不同。如上所述，每一个集/包就是一个KLV包，即总体结构只是1个KLV包；而每一个包装器/容器可由一个KLV包也可由多个KLV包组成。
标签定义的数据是标签数据，这种数据的UL key就能说明该数据的含义，无需数值（V）部分，因此也无需长度（L）字段，通常用于说明wrapper/container/set的某个方面。
3、4种数据类型的KLV编码
这4种数据类型的编码均遵循基本的KLV编码结构，词典中数据项的编码即是全结构的KLV编码。标签的KLV结构中没有L、V字段。包装器/容器数据由一个或多个KLV包组成，其具体的KLV编码规则，见SMPTE 379M等容器规范标准。
对于集/包的KLV编码，为了节省开销，可根据数据的特性简化或省略键值（K）、长度（L）部分。根据省略或简化的程度可分为5种类型：通用集（universal sets）、全局集（global sets）、局部集（local sets）、可变长度包（variablelength packs）、固定长度包（fixedlength packs）。这5种类型的KLV编码字节开销逐渐递减。这5种类型的KLV编码中，每一种集/包本身就是一个全KLV结构，其中key是16字节，且在SMPTE标准中注册过，并且第5字节是0x02。第6字节对于上述5种编码结构的默认值分别是0x01，0x02，0x03，0x04，0x05。长度（L）是短型或长型的BER编码，只是对于数值（V）部分中的具体数据项的KLV编码有所不同。 通用集中的每个数据项都采用全KLV结构编码。
全局集中的所有数据共享键值（K）中的公共信息，用16字节数据的后面8个节来表示每个数据的全局标签，以替代UL key，从而节省字节开销，从全局标签可直接恢复出UL key。
在局部集中，集（set）本身用一个全结构的KLV编码，但是集（set）的数值（V）部分中的具体数据项的KLV编码采用局部标签（local tag）（通常为1或2个字节）来替代该数据项的UL key（16字节）。在这种数据结构中，需要另外有文件来提供局部标签与UL key的映射关系。
可变长度包与局部集类似，但是数值（V）中的具体数据项没有局部标签，只有长度（L）、数值（V）字段。由于没有局部标签，所以需要有相应的映射文件来定义数据项的顺序。 固定长度包比可变长度包更加精简。固定长度包中数值（V）部分的具体数据项的字节长度都固定，因此没有长度（L）字段。这种结构中，具体数据项的编码只有数值（V）部分，没有键值（K）、长度（L）部分，需要有另外的文件或标准来定义数值（V）部分数据项的顺序，以及这些数据的固定长度。 4、KLV编码在MXF文件中的具体应用
除MXF文件最开头可能会有的RunIn（用于伪装文件类型）部分外，整个MXF文件都是由一系列的KLV包组成的。其中长度（L）部分，在MXF文件中一般采用4个字节的长型方法表示，并且规定其字节数最多不超过9个字节。RunIn部分最多不超过65536个字节。
MXF文件中这4种数据类型的应用。
图2 固定长度包的KLV编码结构
图3 可变长度包的KLV编码结构
图4 局部集的KLV编码结构
在MXF文件中，词典、集/包（sets/packs）、包装器/容器、标签这四种数据类型都得到了应用，其中标签主要用于描述素材容器、操作模式、描述元数据机制等信息。音视频等素材信息装载于容器（containers）内。用于字节对齐填充的KLV包是词典类型。集/包数据类型在MXF文件中的应用很多，其中比较常用的结构为固定长度包、可变长度包、局部集。这3种KLV结构分别如图2、图3、图4所示。比如MXF文件中的分区包、主包（Primer Pack）、随机索引包（random index pack，RIP）等采用的是固定长度包结构。而MXF文件中的结构元数据集（structural metadata set）、索引表等采用的是局部集的结构。 四、通用容器
SMPTE 379M标准定义了通用容器（general container，GC）的格式。这个GC正是SMPTE 336M中定义的词典、集/包、包装器/容器、标签这4种数据类型中的第3种，主要用于存放SMPTE 377M标准所定义的MXF文件中文件体（file body）中的基本素材（essence）数据（音频数据、视频数据、字幕数据、辅助数据），方便流式音视频素材的交换。
通用容器（GC）是流式（streamable）数据容器，通过将不同类型的基本素材和元数据（metadata）用基于流式的元数据（streambased metadata）进行数据交织，形成时间上同步的数据流，保证音、视频素材能够连续解码播放。通用容器的数据类型由MXF文件的操作模式UL限定。 1、通用容器结构
每个GC由1个或多个内容包（content package，CP)组成，而每个CP由最多5个数据项（item）组成，每个数据项（item）最多由127个KLV包，即最多127个元素（element）组成。这5个数据项（item）分别是：系统数据项（system item）、图像数据项（picture item）、声音（sound item）、数据（data item）、复合数据项（compound item）。系统数据项主要是为CP服务的，可能包含4方面信息的元数据元素(metadata element)：CP操作模式相关的元数据元素、与整个CP相关的元数据元素、与素材元素（essence element）相关的元数据元素、与控制相关的元数据元素。图像/声音/数据（Picture/sound/data item）分别包含与图像、声音、字幕或辅助数据元素及相应的元数据元素。复合数据项（compound item）包含的是上述数据组成的不可分割的组合数据。每个CP中具体包含哪些数据项（item），由具体应用来决定。每个数据项在1个CP中只
能出现1次，但是每个数据项可由多个元素（element）组成。在1个CP内，如果有系统数据项，则还可包含其它任意数据项，否则只能有1个元素。因为如果没有系统数据项，则没有识别第1个数据项或元素的机制，因此最好只有1个元素。值得注意的是，1个CP定义了1个持续时间（duration）的内容，即CP内每个元素的持续时间都一样。1个GC里可有多个CP，每个CP内的元素的个数和顺序都一样。GC的结构、CP的结构及其与数据项、元素的关系如图5、图6所示。
图5 GC结构
图6 CP的结构
2、素材到通用容器的映射方法
素材数据映射到GC中有两种形式：一种是基于帧（framebased）的映射，一种是基于片段（clipbased）的映射。
在基于帧的映射方式下，1个GC内有1个或多个CP，每个CP所含内容为1帧/场（frame/field ）的内容，这个时间单元由CP内的主素材的采样单元决定，比如为视频帧、视频场或者音频帧（比如192个声音采样块），或者其他能反映主素材的其他采样单元。此时，如果1个GC内只有1个CP，则该GC表示1个持续时间（视频为主素材时的单帧或单场）的内容。基于帧的GC映射示意图如图7所示。
在基于片段（clip）的GC映射中，1个GC中只能有1个CP，每个CP的持续时间为1个或多个帧/场。其映射示意图如图8所示。
这两种映射的区别在于1个CP里允许所含主素材的帧/场个数不同，基于帧的GC映射中1个CP只能有1个主素材帧/场，而基于片段的GC映射中1个CP中可含1个或多个主素材帧/场。
同时，对于前者而言，1个GC内可有1个或多个CP，而后者只能有1个CP。在上述结构中，每个元素的持续时间都相同，同步的元素组合到1个CP内。CP内的每个元素都用一个KLV包表示，遵循SMPTE 336M标准和SMPTE 377M标准的规定。
图7 基于帧的GC映射
图8 基于片段的GC映射
3、应用于数字电影的码流映射
在数字电影中，声音和图像码流采用的是基于帧的映射方法。对于JPEG2000视频或音频文件来说，1个CP中只有1个图像元素或1个音频元素，其持续时间为1帧。这里的“帧”是以图像为基准的，若图像帧率为24fps，音频采样率为48kHz，则1个音频CP中的数值（V）部分则含有2000个音频采样的数据。
而数字电影的字幕若采用MXF封装，则字幕文件到通用容器的映射采用的是基于片段（clipwrapped）的映射方法。 五、小结
DCI规范规定数字电影需采用MXF进行封装打包。为了深入理解MXF基础原理，本文介绍了MXF文件的基础单元KLV编码结构和MXF文件装载节目内容的通用容器，并研究了KLV编码在MXF文件中的具体应用及数字电影码流到通用容器的映射方法。
参考文献
［1］Digital Cinema System Specification，Version 1.2 March 07, 2008，Digital Cinema Initiatives, LLC.
［2］MXF File Format Specification Normative (SMPTE 377M).
［3］Essence Containers Normative (e.g, the MXF Generic Container is SMPTE 379M).
［4］Data Encoding Protocol using KeyLengthValue，SMPTE 336M2001. ［5］Material Exchange Format (MXF) Engineering Guideline (Informative)，EG 412004.
作者 中国电影科学技术研究所 李海洲 白云祥