标准:数字电影打包(声音和图像轨迹文件)

  Rov      2016-08-13   

1:范围

      GY/T 293的本部分规定了采用素材交换格式(MXF)的发行的数字电影内容的声音和图像轨迹文件格式的一般特性。本部分定义了在网络或存储媒体的信号接口进行数据交换的数据结构,但未定义兼容设备或特定基本数据编码映射的内部存储格式。

本部分是用于数字电影的应用规范,基于SMPTE 390M(OP-ATOM)标准制定,并满足将数字电影内容发行到放映场所的需求。

本部分适用于数字电影打包。

2:规范性引用文件

      下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。

  • SMPTE 330M-2004 电视——唯一素材标识符(Television — Unique material identifier (UMID))
  • SMPTE 377M-2004 电视——素材交换格式—文件格式规范(Television — Material exchange format (MXF) — File format specification)
  • SMPTE 379M-2004 电视——素材交换格式—MXF通用容器(Television — Material exchange format (MXF) — MXF generic container)
  • SMPTE 390M-2004 电视——素材交换格式—专用“原子”操作模式(单一项的简化表示)( Television — Material exchange format (MXF)-Specialized operational pattern "Atom" (Simplifies representation of a single item))
  • SMPTE RP 224 SMPTE标签注册(SMPTE labels registry)
  • IETF RFC 2046(1996年11月),多用途互联网邮件扩充协议(MIME) 第二部分:媒体类型(Internet engineering task force (IETF) RFC 2046 (November 1996), Multipurpose internet mail extensions (MIME), Part two: Media types)

3:概述

      数字电影声音和图像轨迹文件是一个有索引且可以随机访问的MXF容器,容器内只含单一基本数据轨迹的单一片段。数字电影声音和图像轨迹文件不应包含交织的、复用的、多场景或多格式的基本数据。

      本部分在应用SMPTE 377M(MXF)和SMPTE 390M(OP-ATOM)时有所限制, 这些限制归为以下四个类别:

    1. 模式(SMPTE 390M OP-ATOM的限制版);
    2. 基本数据(符合SMPTE 379M的基本数据容器的要求);
    3. 头部元数据(严格符合SMPTE 377M);
    4. 描述性元数据(基本数据的部分集合)。

      本部分不是针对特定基本数据类型轨迹文件的完整规范,它可与基本数据映射标准、基本数据限制标准以及可选加密容器标准相结合,以形成一个完整的规范。这些标准及其组合超出本部分的范围。

4:模式限制

  • 4.1 总则
  •       数字电影声音和图像轨迹文件应采用MXF文件格式(符合SMPTE 377M)以及特定的操作模式(符合SMPTE 390M OP-ATOM)。除非特别规定,轨迹文件应符合SMPTE 377M、SMPTE 390M、SMPTE 379M(通用容器)及其参考文献,尤其是SMPTE 336M(KLV)的规范性条款。
  •       MXF规范涉及到的术语和缩略语的完整术语表在SMPTE 377M中给出。读者若不熟悉MXF,则强烈推荐阅读该文件中的“缩略语、术语和数据类型定义”章条。资料性附录NA.1 给出了部分缩略语和术语定义。
  •       请实施者注意,虽然轨迹文件宜仅包含标准许可的结构,但是,SMPTE 377M要求解码器能够处理无法识别的KLV包,更多信息见SMPTE 377M中“KLV编码的暗数据”章条。
  • 4.2 基准(Baseline)操作模式
  •       根据SMPTE 390M,每个轨迹文件应含有一个代表整个轨迹文件的顶层文件包和一个素材包。素材包不应该用于播放,但可用于表示轨迹中用于再现的那部分轨迹的偏移量和时长。SMPTE 390M附录A举例说明了如何使用操作模式为专用原子操作模式(OP-Atom)的MXF文件,包括素材包轨迹、顶层文件包轨迹和任意低层源包轨迹的使用。
  • 4.3 附加限制
    • 4.3.1 容器
    •       轨迹文件应采用SMPTE 379M定义的MXF通用容器(GC),基本数据的映射应采用GC基于帧的映射。声音和图像的基本数据映射应由相关的映射文件定义。
    • 4.3.2 交织
    •       轨迹文件的MXF通用容器中应该只有一种基本数据类型。轨迹文件中的基本数据既不应该是不同种类的本素材的交错,也不应该是不同种类基本数据之间的复用。
    • 4.3.3 系统项
    •       轨迹文件不使用通用容器(GC)中的系统项。
    • 4.3.4 时间码轨迹
    •       轨迹文件不使用基本数据容器中的时间码轨迹。然而,合成时间码存放于头部元数据中(见6.2)。
    • 4.3.5 分区
    •       轨迹文件应有三个分区:头部分区、主体分区和尾部分区。闭合且完整的头部元数据应放于头部分区内,基本数据容器应放于单个主体分区内,索引表片段应放于尾部分区内,见4.3.6。声音和其他基本数据分区的时长宜尽可能与相关图像基本数据分区的时长一致。
    •       轨迹文件最后部分应为遵循SMPTE 377M定义的随机索引包(RIP)。
    • 4.3.6 索引表
    •       轨迹文件应包含SMPTE 377M定义的标准MXF索引表。索引表应分割为一个或多个索引表片段。
    •       注:由于受索引片段空间限制,大的可变比特率(VBR)的文件可能会要求有多个索引表片段,详情见SMPTE 377M。
    •       每个索引片段都应放在尾部分区内。
    • 4.3.7 KAG尺寸
    •       轨迹文件应采用默认的KLV对齐格,其大小为1。见SMPTE 377M 5.4.1“KLV对齐格”。
    • 4.3.8 基本数据类型
    •       一个轨迹文件内,同种类(图像或声音)的所有基本数据容器应为相同的基本数据类型,比如都为JPEG2000压缩,基本数据类型由基本数据描述符的相应属性定义。
    • 4.3.8.1 编辑速率
    •       一个轨迹文件内所有基本数据应有相同的编辑速率。
    • 4.3.9 加密
    •       轨迹文件可包含经过加密处理的基本数据容器。基本数据容器应能标识基本数据是经过加密的。但加密过程的定义不属于本部分的范围。
    • 4.3.10 KLV填充
    •       轨迹文件可采用SMPTE 377M定义的 KLV填充项。
  • 4.4 标签
  •       轨迹文件应由SMPTE RP 224定义的注册标签进行标记,以便识别每个分区包和每个序集内的基本数据容器和操作模式。基本数据容器标签还应出现在文件描述符中。操作模式标签应根据SMPTE 390M的规定设置。由于轨迹文件内素材包只有一个片段(见4.2),操作模式标签的第14个字节的第0比特位始终为0,该字节第1比特位的值取决于素材包内基本数据轨迹的数量。

5:基本数据限制

轨迹文件支持广泛的音视频基本数据结构,比如支持与压缩方式无关的音视频基本数据。下述限制与所用的具体的基本数据结构无关。

  • 5.1 图像
    • 5.1.1 总则
    •       轨迹文件与压缩方式无关。
    •       图像轨迹文件的基本数据容器的每个内容包应包含一个MXF通用容器图像项,每个MXF通用图像项内又只包含一个通用容器(GC)图像元素。
    • 5.1.2 图像参数
    •       轨迹文件内所有帧应有相同的图像结构。
    • 5.1.3 图像封装
    •       图像基本数据应采用基于帧的映射方式编码到KLV包内并进行相应索引。
  • 5.2 声音
    • 5.2.1 总则
    •       轨迹文件与声音格式无关。
    •       声音轨迹文件的基本数据容器的每个内容包应包含一个MXF通用声音项,每个MXF通用容器声音项目内又只包含一个通用容器(GC)声音元素。
    • 5.2.2 声音取样
    •       声音轨迹文件内所有取样应具有相同的取样率和比特深度。
    • 5.2.3 声音封装
    •       声音基本数据应采用基于帧的映射方式编码到KLV包内并进行相应索引。若声道为多声道(比如,16声道的影院格式),多个声道宜以取样级进行封装,否则以能从一个单独轨迹文件同步播放的方式进行编码。

6:头部元数据限制

  • 6.1 总则
  •       轨迹文件的MXF头部元数据应遵循SMPTE 377M,并应受SMPTE 390M限制。轨迹文件应闭合且完整。
  •       头部元数据应只出现在头部分区内。其他分区内不应有头部元数据的副本。
  • 6.2 时间码
  •       时间码信息应出现在符合SMPTE 390M(OP-ATOM)规范的轨迹文件中。时间码信息只用于信息参考而不被轨迹文件使用。
  • 6.2.1 总则
  •       轨迹文件应含有由时间码片段表示的合成时间,时间码片段是从指定起始点开始连续增加的数字。轨迹文件不应包含时间码流数据分区。
  •       注:由于以上明确规定不应使用时间码轨迹,因此,根据本部分,起始点的实际值对于正确运行并不重要,基本数据源中或当地操作实践中若没有指定该值,则习惯采用默认起始时间01:00:00:00。
  • 6.2.2 素材包时间码
  •       轨迹文件内素材包的时间码应由单个连续的片段组成。
  • 6.2.3 顶层文件包时间码
  •       轨迹文件内文件包的时间码应由单个连续的片段组成,其起始时间应与任何已知历史源包一致,或为合理的默认值(见6.2.1的注)。
  • 6.2.4 源包时间码
  •       若有历史源包,轨迹文件内每个历史源包的时间码应由单个连续片段组成,其起始时间与更早的源包的一致或者与如果知道的导入母版的一致,或者为合理默认值(见6.2.1的注)。
  • 6.3 轨迹文件标识
  •       数字电影包采用通用唯一标识符(UUID)链接资产。轨迹文件的身份应由其唯一的顶层文件包的包唯一标识符标识(以下简称为“包唯一标识符”)。
  • 6.3.1 包唯一标识符创建方法
  •       包唯一标识符应符合SMPTE 330M中唯一素材标识符(UMID)的规定,具有一个素材序号UUID,一个素材序号生成方法UUID/UL。包唯一标识符还应遵循以下限制:
      1. UMID中UL部分的第11个字节应为0fh(不确定素材类型);
      2. UMID中UL部分的第12个字节应为20h(UUID/UL素材序号生成方法及未定义的实例序号生成方法);
      3. 3个字节的实例序号均为0(零)。
  •       根据本条生成的包唯一标识符的头16个字节为:060a2b34h 01010105h 01010f20h 13000000h。
  • 6.3.2 UUID标识比较
  •       若将轨迹文件的标识与已知UUID相比较,应将已知UUID与包唯一标识符的素材序号部分(第17~32字节)相比较。

7:描述性元数据限制

      在SMPTE EG 42中阐述了描述性元数据方案(DMS)框架的一般原则。描述性元数据(DM)是可选的,如果存在,则应存放在轨迹文件中的静态描述元数据(DM)轨迹上的DM片段中(见 SMPTE 377M规定的有关内容)。具有DM的轨迹文件,在其序集中应有一个DM标签,以标识轨迹文件所采用的每个DM机制。

8:其它限制和定义

  • 8.1 文件名和资产标识
  •       文件内资产的标识应由文件内顶层文件包的包唯一标识符(见6.3.1的规定)确定,而不应由文件名或任何其他外部指定的文件标识符、指针或链接确定。
  • 8.2 同步
  •       两个或以上具有相同或不同基本数据类型的轨迹文件的同步方法不属于本部分的范围。轨迹文件中除MXF头部元数据外不应包含同步信息。

9:多用途网际邮件扩充协议类型

      在采用MIME类型标识符标示文件格式时,应采用MIME类型“application/mxf”标明文件符合本部分(见IETF RFC 2046)。

声明:影聚合仅提供信息展示和存储服务,文章均来自网络和个人,内容仅代表作者本人观点,不代表本站观点。部分内容由AI智能生成,请谨慎参考。如内容如有侵权,请联系cm@rov8.com,我们将第一时间处理。

评论(0)

等待你的第一个评论哦...

影片推荐