【技术文章】
| 素材交换格式 | |
| J·威尔金森 | |
| 本文作者J. Wilkinson先生，英国Sony BPE R&D成员。原文刊登于《IBC 2000论文集》，版权为IBC所有。 | |
| 1999年中，Pro-MPEG论坛开始积极讨论业界对一种通用文件格式的要求，该格式用于文件服务器之间的节目数据交换。该话题提出很多次后，各种用于DV和MPEG传送的流式接口的发展，给了它新的动力。它们为压缩视频码流的传送提供了标准化的方法，并认定在盘基服务器之间的节目文件交换领域无同等的情况。为了给节目素材的交换提供一种标准化的文件格式，该论坛目前正在同AAF协会一道，合作开发素材交换格式(MXF)。该文件格式通过综合元数据的支持，直接将流数据映射到某个包括包头在内的文件结构里。该文件格式的设计目的是方便通过SDTI和其它流式接口操作，从而为传统流式技术和新型网络技术之间提供连续性。 一 MXF格式概览 无论是信号接口，还是可撤除式存储媒体，该规范只定义了交换点的MXF文件结构。 MXF文件是按照SMPTE 336M(目前为试行版)，基于SMPTE KLV编码的。SMPTE 336M可使当前的操作具有高度灵活性，使未来MXF的实施具有可扩展性。所有MXF文件都含有模板标识符，以识别已编码的元数据的复杂程度，以及对文件主体部分的实质容器和压缩类型的标识。这些模板对最佳化设计的设备复杂性的开发来说，是至关重要的。 MXF文件结构遵循一个共同的主题，即许多文件都具有以下基本部分： (1)文件头：提供文件的总体信息，包括操作模板。最小文件头的第一部分必须与所有模板一致。文件头包括了依循先进创作格式(AAF)、可通过AAF解码器阅读的元数据。 (2)文件体：提供交织的实质部分。在需要一个以上的实质流以确保实现多流特性，例如从不完全传送中恢复时，以及只剪切编辑等场合，才需要交织。 (3)文件尾：使文件终止。 MXF文档以多部分文档的形式创建，每一部分均可向SMPTE提交，以便在适当的时候标准化。 1. 文件传送和流传送 为了找出流传送和文件传送之间的差异，我们将各自的主要特点归纳如下： a. 文件传送 可利用可拆卸式文件媒体完成；使用基于包的网络互联，通常已经确认；通常按照预定的起始和结尾，以单个单元(或以一组已知的片断)的形式进行传送；一般不与外部时钟同步(在传送时)；通常为点到点，或者多点数量有限的点到多点形式；通常以随机或在内存中广泛分布的字节偏移的形式读取实质分量。 b. 流传送 可利用可拆卸式流式媒体完成；使用数据流式互联，通常没有确认；可扩充，没有预定的头和尾；流通常与某一时钟同步或异步，并具有一个明确的最小/最大传送率；一般为点对多点或广播；通常以顺序字节位置的形式读取实质数据。 典型视频文件传送的问题之一是，很多服务器在文件关闭之前支持播出(亦即从某一仍在写入的文件的已写入部分读取数据)。这样一来，前述差别就模糊了。 2. MXF主体容器 MXF文件的主体内容由一个或多个可流化的实质分量组成，这些分量通过有限的时间跨度(典型为1个帧)进行交织。 MXF包装规范没有定义每个单独的主体规范，仅仅定义了适应主体的容器必须满足的约束条件，以使其成为一个可以接受的MXF主体“插件”。之所以定义这些约束条件，是为了保证所有MXF文件，满足在用户要求中提出的有关准则。这些准则归纳如下：必须使用公开注册的密钥，通过KLV编码封装实质分量；必须通过有限的时间跨度(典型为1个帧)，提供对实质分量的交织；作为标准，必须满足SMPTE准则(见SMPTE管理细则)；必须作为一种开放式规范进行标准化，最好通过正规的SMPTE预定过程。 目前已为MPEG-2 4:2:2 P@ML (CP-Container文件)和消费类DV(包括其专业类版本DVCAM)定义了主体容器文件。在写作本文之时，用于DVCPRO的一种容器文件正在开发中；而另一种基于MPEG节目流(PS)的主体容器可能在不久的将来开发。 3. 元数据分类 MXF的主要目标是，同附带的有关素材主体的元数据信息一起，交换节目素材。由于它用于描述MXF文件内的一个主体片段，这部分提供了一些元数据的潜在概念。 图1所示的是MXF主体模型，以及用于描述主体各部分的不同条款的定义：在主体的持续时间内，由所有轨道组成的整个主体包含了节目内容。头部元数据包含了描述主体的总体内容和单个节目片段的元数据组的结构。 主体可大致划分为轨道和剪辑，这里的剪辑可能一个是轨道剪辑或一个素材剪辑，其中后者是扩展到一个以上轨道的剪辑。 场景只能通过时间线轨道来定义，但要参照所有轨道上的素材。场景的元数据具有一个任意时间线，可用来描述某一特定帧的单个场景事件。它还可以用来描述可能重叠的元数据。 4. 主体的表达 主体素材可以看作以下任意一种通用形式： (1)简单表达：节目素材表现为一个完备的单一项目，主体表现为一个实体。 (2)分段表达：节目素材表现为一些拼接的片段。每个节目片段中，除了有整个节目的元数据外，可能还具有自己的元数据。 (3)简单编辑表达：主体由两个或更多按表达顺序排列的、包含于主体中的剪辑的拼接组成。头部元数据描述简单的视音频对接编辑。为了减小可听到的“喀呖”声，音频轨道可能需要一些交叉衰减或者淡入/淡出操作。任何数据实质轨道可能需要特殊的处理，以便在结合点对数据实质作清晰的划分。在汇编之前，主体内容会是一连串可播放的源剪辑。 (4)特技表达：主体由两个或以上源剪辑的拼接组成。这些剪辑不一定要按时间序列出现，而是可以按任意顺序出现。头部元数据为包括叠加的渐变、划像等在内的视音频实质分量方面的复杂编辑提供指导。在汇编之前，主体内容虽然不一定是线性顺序，但应该是一连串可播放的源剪辑。另外，主体可能包含很多层可用于覆盖特技等场合的素材。 对制作完备的节目的交换来说，前两种表达很容易定义。第三种在播出之前所需操作非常少，并可用于所支持设备之间的节目交换。 第四种需要实质性处理，以创建一个适合播出的输出。因此，除了有限的几种情况，即要么渲染时间不重要(特技制作可脱机进行)，要么已经知道可以提供实时操作所需的高速处理效能，否则第四种表达并非总是适用于节目交换的。目前，MXF文件还没有考虑第四种表达。 二 MXF包装规范 1. 总体数据结构 MXF字节流的总体结构定义为如图2所示的一串文件头、主体和尾。它也可能包含一个可选的索引表——用以快速查找文件主体部分的帧位置。 注意，图中各个单项的大小并不代表数据项的真实长度——典型情况下，文件主体占整个文件大小的99%以上。 2. KLV编码顺序 MXF文件通过一串如下定义的KLV编码的数据包进行定义： (1)始终从一文件头部开始，它的构成依次为一个前同步和一个头部元数据组，其后还可能有一个索引表数据组。其中前同步包括一个固定起始字节序列，其后是一个前同步数据包。(2)一串一个或更多的主体容器KLV包。(3)始终终止于某一个文件尾部，该文件尾是一个后同步(定义为一个后同步数据包)，并可能位于一个索引表数据组之后。 这样，MXF文件的开始，是由其后紧随着前同步 KLV数据包的一个8字节起始指示的。 MXF文件的结束唯一通过后同步KLV数据包指示。在起始和终止KLV包之间，可是是任何数目的其它KLV包。特别是，KLV包的数目很依赖于位于文件主体的节目素材的长度。对于文件主体，每一个可编辑的内容单位以其自身的KLV包进行编码(典型持续时间为一个帧)。 3. KLV编码规则 注意，今后，MXF规范随时可能会增加内容。在忽略不被认可的经KLV编码的数据项或组的同时，MXF解码器仍应能分析任何增强语法和提取可认可的部分。 不管密钥值是否被认可，MXF解码规则始终遵循KLV语法。不被认可的密钥具有解码器无法确定的数值，因此应该过滤掉。然而，为了方便用户诊断，解码器可能有选择地指示这些不被认可的密钥。 4. 头部元数据 头部元数据是一些用以描述主体内容、并经KLV编码的元数据组的集合。KLV编码局限于3层，以使长度值编码所需的运算次数最小。数据结构如图3所示。 头部元数据由一串元数据组组成。这些元数据组(也称为对象)和与它们相关的元数据项(也称为对象属性)是从AAF规范选择的一个子组。所有元数据项在SMPTE元数据字典中进行定义。 5. 强弱参照 提供参照，旨在允许某一组中的元数据与另一组连系起来，以便提供一个逻辑性的数据结构。 每个元数据组被编码和标识为一个KLV数据组，并由一个依次包括了所有经KLV编码的元数据项的取值组成。注意，任何数据组的第一项是用于该数据组的唯一标识符(UID)。 在具有强参照UID值的一个数据组，与以相同UID值为首项的另一个数据组之间，任何经KLV编码的数据组的“强参照”都是一一对应的关系。MXF文件使用顺序组布局，意味着参照数据组希望被参照的数据组能够立即依次跟随。由于这是一个强参照组，只有参照数据组才可以进行该连接。 “弱参照”使用弱参照UID链接数据组，但是任何弱参照的数据组可能被一个以上的其它数据组所参照。这样，弱参照数据组是具有UID的独立组，可以参照的数据组为零或更多。虽然希望弱参照数据组能早期置入流内，以便解码器在解码过程中较早地解决弱参照问题，弱参照数据组是可以定位于数据流内任何位置的。 图4所示的是一串经KLV编码的元数据组(对象)和使用强和弱参照以连接相关组的例子。 虽然图2显示的是文件开始时的头部元数据，但是它可以在整个文件主体部分随意重复。头部元数据的重复是在逐个应用的基础上定义的。此类应用，在将一个MXF文件作为一个流通过单向无线通路或陆地线路及在磁带中进行传送的场合。作如此重复的目的，是在文件可能被中断或者解码器在传送途中接收数据的场合，支持关键元数据的恢复。 6. 索引表 索引表是一个备选的元数据组，可用来定位单个视频实质帧，以及相关的音频和数据实质。索引文件可置于紧靠主体之前，或者紧靠主体之后，或者随意分布于主体。 索引表可在文件从一输入流进行创建的过程中“即时”创建，理论上可置于正在录制的文件的结尾。实际上，可将其放置于文件服务器系统的任何位置，只要存储方便即可。在一个完整文件的传送过程中，索引表放在MXF文件的头部。 对每帧以固定字节数定义的主体容器规范来说，索引表并非必需，因此是否将其包含于MXF文件中是任选的，并取决于MXF模板。 7. MXF模板 MXF文件的复杂性可以建造得非常高，特别是头部元数据包。为了简化解码，定义了一些特定的模板，以便约束头部元数据定义的复杂度。 三 总结 Pro-MPEG论坛和AAF协会开发的MXF文件满足节目交换文件格式方面的关键准则。这些准则包括：通过一个为实现最大互操作性和扩展性而设计的普通包装，存取应用作为文件的交织实质容器流；与压缩格式无关的包装，允许元数据通过译码保存为不同压缩格式，或者从不同压缩格式予以保存；支持随机存取和部分文件传送，例如无须传送整个文件，可以移动某一赛事或者新闻事件中的高潮场面；支持传送中存取，例如在传送完成前开始播放或编辑某一文件；支持版本更新所需的剪切编辑；库和归档应用方面的交换格式适用性。 不同的广播应用具有不同的元数据要求。例如，编辑需要的元数据同分配或归档需要的元数据远不相同。为此，使用模板来为每一个应用规定一组封装于该文件包装的、最小要求的、备选的元数据。就绪的模板，可能还要规定有关视/音频实质和视/音频实质容器的约束条件。 除了文件交换格式和应用专用的模板外，还存在着很多须讨论的网络问题，其中包括多广播、通过IP网络的流式广播，以及其它有关网络协议和服务质量的问题。最终目标是为广播业者接入压缩和非压缩系统的手段，并确保众多制造商提供的设备允许成功地交换文件。 |
|
| 来源：《世界广播电视》 | |