DY∕T 2.5-2020 数字电影打包 第5部分：打包列表.pdf

ICS 35.040；37.060.99 N40 DY 中 华 人 民 共 和 国 电 影 行 业 标 准 DY/T 2.52020 数字电影打包 第 5 部分：打包列表 Digital cinema (D-cinema) packaging - Part 5: Packing list （ISO 264298:2009,Digital cinema (D-cinema) packaging - Part 8:Packing List,MOD） 2020 - 09 - 22 发布 2020 - 09 - 30 实施 国家电影局 发 布 DY/T 2.52020 I 目 次 前言 . III 引言 . IV 1 范围 . 1 2 规范性引用文件 . 1 3 缩略语 . 1 4 概述 . 2 4.1 打包列表定义 . 2 4.2 XML 语言的使用 . 3 5 打包列表结构 . 3 5.1 打包列表编码方式 . 3 5.2 Id 元素 . 4 5.3 AnnotationText 元素（可选） . 4 5.4 IconId 元素（可选） . 5 5.5 IssueDate 元素 . 5 5.6 Issuer 元素 . 5 5.7 Creator 元素 . 5 5.8 GroupId 元素（可选） . 5 5.9 AssetList 元素 . 5 5.10 Signer 元素（可选） . 5 5.11 Signature 元素（可选） . 5 6 资产结构 . 6 6.1 资产说明 . 6 6.2 Id 元素 . 7 6.3 AnnotationText 元素（可选） . 7 6.4 Hash 元素 . 7 6.5 Size 元素 . 7 6.6 Type 元素 . 8 6.7 OriginalFileName 元素（可选） . 8 7 XML 模式 . 8 7.1 本章 XML 模式说明 . 8 7.2 打包列表 . 8 7.3 资产 . 9 7.4 混合类型 . 9 附录 A（资料性附录） 本部分与 ISO 264298:2009 相比的章条编号对照情况 . 10 DY/T 2.52020 II 附录 B（资料性附录） XML 图例 . 12 附录 C（资料性附录） 实例 . 15 参考文献 . 16 DY/T 2.52020 III 前 言 数字电影打包标准已经或计划发布如下部分： GY/T 293.12015数字电影打包 第1部分：声音和图像轨迹文件； GY/T 293.22015数字电影打包 第2部分：MXF JPEG2000应用； DY/T 2.32020数字电影打包 第3部分：MXF轨迹文件基本数据加密； DY/T 2.42020数字电影打包 第4部分：合成播放列表； DY/T 2.52020数字电影打包 第5部分：打包列表； DY/T 2.62020数字电影打包 第6部分：资产映射和文件分割； DY/T 2.72020数字电影打包 第7部分：立体图像轨迹文件。 本部分是数字电影打包的第 5 部分。 本部分按照GB/T 1.12009给出的规则起草。 本部分使用重新起草法修改采用ISO 26429-8:2009数字电影打包 第8部分：打包列表。 为符合GB/T 1.12009的编写规则，本部分与ISO 26429-8:2009相比在结构上有较多调整，附录A列出了本部分与ISO 26429-8:2009章条编号变化对照一览表。 本部分作了以下编辑性修改： 为与现有标准系列保持一致，将本部分名称改为数字电影打包 第5部分：打包列表； 删除了第2章“一致性符号（Conformance Notation）”； 增加了附录A（资料性附录）“本部分与ISO 26429-8:2009相比的结构变化情况”； 删除了资料性附录ZZ。 本部分由国家电影局提出并归口。 本部分起草单位：中国电影科学技术研究所。 本部分主要起草人：王萃、方捷新、张雪、刘达。 DY/T 2.52020 IV 引 言 本文件的发布机构提请注意，声明符合本文件时，可能涉及到相关专利使用。 本文件的发布机构对于该专利的真实性、有效性和范围无任何立场。 该专利持有人已向国际标准化组织（ISO）保证，愿意同任何申请人在合理非歧视条款和条件下，就专利授权许可进行谈判。该专利持有者的声明已在国际标准化组织（ISO）备案。相关信息可通过以下联系方式获得： 专利持有人姓名：Eastman Kodak Company Intellectual Property Transactions。 地址：343 State Street Rochester, NY 14650 USA。 请注意除上述专利外， 本文件的某些内容仍可能涉及专利。 本文件的发布机构不承担识别这些专利的责任。 DY/T 2.52020 1 数字电影打包 第 5 部分：打包列表 1 范围 数字电影打包标准的本部分规定了在数字电影应用中用于交换的打包列表的数据格式。 打包列表所描述的完整发行包的电子和物理形式不属于本部分的范围。 本部分适用于数字电影打包。 2 规范性引用文件 下列文件对于本文件的应用必不可少。凡是标注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 W3C 2004 可扩展标记语言 （XML） 1.0 （第三版）（World Wide Web Consortium (W3C) (2004, February 4). eXtensible Markup Language (XML) 1.0 （Third Edition） ） W3C 2004 XML 模式第 1 部分：结构（第二版） （World Wide Web Consortium (W3C) (2004, October 28). XML Schema Part 1: Structures （Second Edition） ） W3C 2004 XML 模式第 2 部分： 数据类型 （第二版）（World Wide Web Consortium (W3C) (2004, October 28). XML Schema Part 2: Datatypes（Second Edition） ） W3C 2004 XML签名语法和处理（World Wide Web Consortium (W3C) (2002, February 12). XML-Signature Syntax and Processing） ETF 2001 RFC3174 互联网工程任务组 美国安全散列算法1（SHA-1）（Internet Engineering Task Force (IETF) (2001, September). RFC 3174 US Secure Hash Algorithm 1 (SHA-1)） IETF 1996 RFC2045 多用途互联网邮件扩展协议(MIME) 第1部分:互联网消息体格式（Internet Engineering Task Force (IETF) RFC2045 (November 1996) Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies） IETF 1996 RFC2046 多用途互联网邮件扩展协议(MIME) 第2部分:媒体类型 （Internet Engineering Task Torce (IETF) RFC 2046 (November 1996), Multipurpose Internet Mail Extensions (MIME), Part two: Media Types） IETF 1996 RFC2396 统一资源标识符（URI）：通用语法（Internet Engineering Task Force (IETF) (1996, November). RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax） IETF 2005 RFC4122 通用唯一标识符(UUID) URN命名空间 （Internet Engineering Task Force (IETF) (2005, July). RFC 4122 A Universally Unique Identifier (UUID) URN Namespace） IETF 2001 RFC4051 附加的XML安全性统一资源标识符(URIs)（Internet Engineering Task Force (IETF) (2001, April) RFC 4051 Additional XML Security Uniform Resource Identifiers (URIs)） 3 缩略语 下列缩略语适用于本文件。 IETF：互联网工程任务组（Internet Engineering Task Force） DY/T 2.52020 2 MIME：多用途互联网邮件扩展协议（Multipurpose Internet Mail Extensions） PKL：打包列表（Packing List） RFC：评议请求（Request For Comments） SHA-1：安全散列算法1（Secure Hash Algorithm 1） URI：统一资源标识符（Uniform Resource Identifier） UUID：通用唯一标识符（Universally Unique Identifier） XML：可扩展标记语言（Extensible Markup Language） 4 概述 4.1 打包列表定义 打包列表规定了发行包的内容。发行包应包括一个打包列表、若干合成播放列表资产、基本数据资产以及组成发行包的其他资产。 打包列表中有一个定义发行包的元素列表和一个引用发行包所有资产的列表。列表内含有唯一标识包内每个资产的Id。 完整发行包的结构如图1所示，包含一个预告片和一个单个分本正片。 图1 典型发行包示例 不完整打包列表的结构如图2所示，其中包含了一个即将被传送到影院的替换“分本”。例如在正片制作完成后，需要对片尾字幕信息进行更改，此时就会创建该类打包列表。注意此类不完整发行包包含图像、声音与字幕轨迹文件以及一个引用以上文件与原发行包文件的合成播放列表。图2所示的示例包与图1所示的示例包不相关。 DY/T 2.52020 3 图2 典型不完整发行包示例 4.2 XML 语言使用 本部分定义的结构按照XML 1.0规定的可扩展标记语言表示，并按XML模式 第1部分：结构规定的XML模式和XML模式 第2部分：数据类型规定的数据类型来定义。本部分应与一个唯一的XML命名空间名称（该名称符合XML 1.0标准中关于命名空间的规定）相关联，该命名空间名称应为字符串“http:/www.smpte-ra.org/schemas/429-8/2007/PKL”。该命名空间名称表达了结构和语义的版本信息，同时作为传统版本号字段。 表1例举了本部分所用XML命名空间名称， 命名空间名称以统一资源标识符 （URI） 数值 （见RFC 2396）表示。 表1 XML 命名空间 限定符 URI pkl http:/www.smpte-ra.org/schemas/429-8/2007/PKL xs http:/www.w3.org/2001/XMLSchema ds http:/www.w3.org/2000/09/xmldsig# 表1列出的URI为规范性取值。 表1和本部分其他地方所用的命名空间限定符不是规范性取值。 因此，在实例文档中他们可被任意符合XML命名空间的前缀替代。换句话说，实施方案应考虑到与表1中URI值关联的任意符合XML命名空间的前缀值。 本部分采用的来源于其他模式的数据类型将被附加适宜的命名空间限定符（例如：xs:dateTime）。有关这些类型的更多信息请见XML模式 第2部分：数据类型与XML签名语法与处理。 对于包含单个PackingList元素作为其根的文件， 其MIME类型按IETF RFC 2046规定应为 “text/xml” 。 5 打包列表结构 5.1 打包列表编码方式 打包列表应被编码为一个XML文档（见XML 1.0）。顶层元素应被指定为PackingList，如图3所示。 DY/T 2.52020 4 图3 打包列表结构，虚线表示可选元素（XML 图例见附录 B） 5.2 Id 元素 Id元素唯一标识打包列表。每个唯一的打包列表应拥有不同的Id，以简单地区分不同的打包列表。Id元素取值类型为urn:UUID（见RFC 4122）。 5.3 AnnotationText 元素（可选） DY/T 2.52020 5 AnnotationText元素应为自由格式且可读的释文,用于描述发行包。 这仅是给用户的一种显示提示。可选的language属性是一个xs:language语言代码，表明元素内容的语言。如果language属性不存在，则应使用默认值en。 5.4 IconId 元素（可选） IconId元素唯一标识包含一个说明打包列表的图标图片的外部图像资源。打包列表可使用图标表示，例如采用相关内容的一帧来表示。IconId元素取值类型为urn:uuid（见IETF RFC 4122）。UUID值与实际图像资源的映射不属于本部分范围。 5.5 IssueDate 元素 IssueDate元素指明了打包列表发布的日期和时间。IssueDate应被编码为一个xs:dateTime值。 5.6 Issuer 元素 Issuer元素应为自由格式且可读的释文， 用于描述创建打包列表的个人或公司。 这仅是给用户的一种显示提示。可选的language属性是一个xs:language语言代码，表明元素内容的语言。如果language属性不存在，则应使用默认值en。 5.7 Creator 元素 Creator元素应为自由格式且可读的释文， 用于描述创建打包列表的个人、 机构或系统 （硬件/软件） 。这仅是给用户的一种显示提示。可选的language属性是一个xs:language语言代码，表明元素内容的语言。如果language属性不存在，则应使用默认值en。 5.8 GroupId 元素（可选） GroupId元素用于建立包与包之间的关联。当该元素存在时，应包括一个urn:uuid值（见IETF RFC 4122）。该元素应向接收者表明此包可与包含相同GroupId值的其他任意包以资产管理目的相关联。关联的确切意义不属于本部分范围，但总的来说，一个没有GroupId元素的打包列表应包含一个完整的资产集合（即：资产间没有无效引用）。拥有相匹配的GroupId元素的两个或多个打包列表应包含相关联的资产（如：通过引用相关联）。 5.9 AssetList 元素 AssetList元素由包含于发行包中的Asset元素列表组成。Asset元素结构见本部分第6章。Asset元素在列表中的顺序并不重要。 5.10 Signer 元素（可选） Signer元素唯一标识实体，因而唯一标识对打包列表进行数字签名的公钥/私钥对。它应是XML签名语法与处理中定义的KeyInfoType类型的一个实例。如果Signer元素存在，则Signature元素也应存在。 如果按XML签名语法与处理的规定使用X.509证书，则Signer元素应包含一个X509Data元素，并且该元素包含一个X509IssuerSerial元素，以唯一地标识用于对打包列表进行签名的证书。 5.11 Signature 元素（可选） Signature元素应包含一个用于认证打包列表的数字签名。 如果Signature元素存在， 则Signer元素（见5.10）也应存在。Signature元素应是按照XML签名语法与处理规定定义的ds:Signature元素的DY/T 2.52020 6 一个实例。 数字签名应被封装于打包列表中， 并作用于整个打包列表。 封装好的签名附加于被签名文档。签名由Signer元素所标识的签名者使用其私钥生成。 标准的Signature元素具有高度灵活的结构，应用广泛。就应用于打包列表来说，它应满足以下限制条件: KeyInfo 元素应存在，且应包含签名者的整个证书链； Object 元素不应存在，且 Reference 元素的 URI 属性应设为“”（空字符串），因为签名被封装于打包列表中； Reference 元素应包含单个 DigestMethod 元素，其算法属性设为 URI 值“http:/www.w3.org/2000/09/xmldsig#sha1”； Reference 元素应包含单个 Transform 元素，其 Algorithm 属性设为 URI 值“http:/www.w3.org/2000/09/xmldsig#enveloped-signature”； CanonicalizationMethod 应设为 URI 值“http:/www.w3.org/TR/2001/REC-xml-c14n-20010315”； SignatureMethod 应设为 URI 值“http:/www.w3.org/2001/04/xmldsig-more#rsa-sha256”（见 IETF RFC 4051）。 如果按XML签名语法与处理的规定使用X.509证书，则整个证书链应作为一个X509Data元素序列包含于KeyInfo元素中。每个X509Data元素都应与证书链中的一个证书相对应，且应包含一个X509IssuerSerial元素和一个X509Certificate元素。 6 资产结构 6.1 资产说明 打包列表包含一个资产列表。资产是一组数据，如基本数据或元数据的集合。任意类型的数据都可被称为一个资产。每个资产都应采用如图4所示的资产元素进行描述。详细的类型信息见第7章的XML模式声明。 DY/T 2.52020 7 图4 资产结构，虚线表示可选元素 6.2 Id 元素 Id元素唯一标识资产，取值类型urn:UUID（见RFC 4122），在可能的情况下Id应能从资产中提取出来。UUID的分配由资产创建者完成。UUID值与实际资产资源的映射不属于本部分范围。 6.3 AnnotationText 元素（可选） AnnotationText元素如存在，应为自由格式且可读、与资产相关的释文。这仅是给用户的一种显示提示。可选的language属性是一个xs:language语言代码，表明元素内容的语言。如果language属性不存在，则应使用默认值en。示例如图5所示。 The Jazz Singer Swedish Package The Jazz Singer new reel 5 with outtakes - Swedish Package 图5 AnnotationText 元素示例 6.4 Hash 元素 Hash元素应为以Base64 （见RFC 2045） 编码形式表示的有关资产的SHA-1消息摘要。 SHA-1由RFC 3174定义。消息摘要被用于资产的完整性校验。 6.5 Size 元素 DY/T 2.52020 8 Size元素包含资产的大小。资产大小采用整数字节表示，且被编码为xs:positiveInteger。 6.6 Type 元素 Type元素描述了资产文件的MIME类型。 它既是给用户的一种显示提示， 同时也是用于内容接收处理的机器可解释信息。 MIME类型按RFC2045和RFC2046规定定义。 Type参数应包含表2示例中的任意有效MIME类型字符串。与其他数字电影打包结构相关的MIME类型字符串由相应的规范性文件定义。 表2 资产类型示例 类型 描述 Text/xml An XML file (Compositon playlist, subtitle track file,) application/mxf An MXF track file (picture or sound) 6.7 OriginalFileName 元素（可选） OriginalFileName元素包含了打包列表在创建时包含资产的文件名称。 该元素的取值不受限于任何特定格式，仅是给用户的一种显示提示。 7 XML 模式 7.1 本章 XML 模式说明 本章所述XML模式文件采用机读语言规范性定义打包列表的结构。尽管本模式的目的是忠实表示本部分第4章到第6章规定的结构，但可能会发生定义冲突。若发生定义冲突，应以本部分的规范性表述为准。XML模式如图6所示。打包列表XML结构实例见附录C。 图6 XML 模式 7.2 打包列表 打包列表XML模式如图7所示。 图7 打包列表 XML 模式 DY/T 2.52020 9 图 7 打包列表 XML 模式（续） 7.3 资产 资产XML模式如图8所示。 图8 资产 XML 模式 7.4 混合类型 覆盖简单类型与复杂类型的混合类型XML模式如图9所示。 图9 混合类型 XML 模式 DY/T 2.52020 10 A A 附 录 A （资料性附录） 本部分与 ISO 26429-8:2009 相比的章条编号对照情况 本部分与ISO 26429-8:2009相比章条编号变化对照情况见表A.1。 表A.1 本部分与 ISO 26429-8:2009 的章条编号对照情况 本部分章条编号 对应 ISO 标准章条编号 前言 - 引言 引言 1 1 2 2 3 3 4 4 4.1 4 的第一至三段 4.2 4.1 5.1 5 的第一段 5.2 5.1 5.3 5.2 5.4 5.3 5.5 5.4 5.6 5.5 5.7 5.6 5.8 5.7 5.9 5.8 5.10 5.9 5.11 5.10 6.1 6 的第一段 6.2 6.1 6.3 6.2 6.4 6.3 6.5 6.4 6.6 6.5 6.7 6.6 7.1 7 的第一段 7.2 7.1 7.3 7.2 7.4 7.3 DY/T 2.52020 11 附录 A 附录 B Annex B 附录 C Annex A 参考文献 Annex C ANNEX ZZ DY/T 2.52020 12 附 录 B （资料性附录） XML 图例 B.1 概述 下面提供了描述XML结构的示意图中所用的符号图例。 B.2 元素符号 B.2.1 概述 本部分前面给出的结构设计图中，只画出了元素，属性是不可见的。元素的基数（0.1、精确的1、0.n、1.n）是用元素的边界来标明。可选元素用虚线画出，必要元素用实线画出。最大出现次数大于1的元素用双边界来标明。 可选元素 必要的单个元素 必要的重复元素 最小出现次数 = 0 最小出现次数 = 1 最小出现次数 = 1 最大出现次数 = 1 最大出现次数 = 1 最大出现次数 = 无限定 元素的内容模型在元素框的左边和右边用符号来表示。 元素框的左边符号表明元素包含的是一个简单类型（文本、数字、日期等），或一个复杂类型（其他元素）。元素框的右边符号表明它是否包含子元素。 简单内容 复杂内容 带有子元素的复杂内容 无元素内容 （简单类型、 仅属性， 或空白元素） B.2.2 示例 可选的无子元素的单个元素。最小出现次数 = 0，最大出现次数 = 1，内容 = 复杂。 同上，但带子元素。右边的“加号”表明存在一个或多个未显示的子元素。 强制性单个元素。最小出现次数 = 1，最大出现次数 = 1，内容 = 复杂，无子元素（即：这表明是一个空元素）。元素下面的灰色文本显示与元素相关的xml-schema注释。 DY/T 2.52020 13 包含子元素的强制性多重元素（内容 = 复杂）。该元素必须出现至少一次（最小出现次数 = 1），可按要求经常出现（最大出现次数 = 无限定）。 包含简单内容（例如文本）或复杂混合内容（例如带xhtml标记的文本）的强制性单个元素。最小出现次数 = 1，最大出现次数 = 1，类型 = xsd:string（举例），内容 = 简单。左上角的三条线用于表示文本内容和数字内容。 B.3 模型符号（“合成器”） 一个元素序列。元素必须精确按照结构图中的顺序出现。 元素的一个选择。在这个位置上只可出现选中的单个元素。 “全部”模型，其中元素的顺序是不固定的。 B.4 类型 如果一个元素引用一个复杂的全局类型，该类型用一个边框来显示。 简单类型的类型名称显示为： B.5 模型组和引用 DY/T 2.52020 14 一个元素组是一个带有一个或多个元素的命名容器。该组元素可在模型中的多个位置上重复使用。模型组在实例文件中是不可见的。 模型组的使用一直很谨慎， 因为它们与面向对象编程语言的特点不符（除非它们支持多重继承）。 有关阅读模型组示意图的重要注释:如果模型组符号是以简单的线条（即不是用虚线）绘制的，这意味着模型组中的元素不是必要的。组的可选择性取决于模型组中所包含元素的可选性。(模型组可设置成可选，例如在某些情况下将一个带有必要元素的模型组设为可选,但从未这样使用。) “any”组是一种特殊的模型组。这是结构中未定义元素的一个占位符。“any”元素规定结构可以被扩展的位置。在“any”关键字之后，元素所来自的命名空间被定义，例如“#other”规定扩展元素可来自任何除当前结构命名空间以外的命名空间。 “Element references” 是通过左下角的一个连接箭头来指示的。 它们类似于在结构中引用模型组，但不是改善模型组，它们直接引用一个全局元素。于是，全局元素可以在多个地方被重复使用。 DY/T 2.52020 15 附 录 C （资料性附录） 实例 以下是一个有效的打包列表结构实例。该实例不能被实际使用，仅用于提供信息。为了表述清晰，已省略可选的Signature和Signer元素。 urn:uuid:c287765c-0db2-427c-9903-2d65e459c648 2005-11-02T16:39:22-00:00 D-Cinema Distribution Co. Package Tool 1.0 urn:uuid:ad03e262-820b-4bf6-9646-d64eed451c92 Jazz Singer Reel #1 Picture VtRLivH5riIVeJaaSlvJF1KW5VI= 15739456732 application/x-smpte.mxf urn:uuid:bdbad39f-4967-45aa-8dd5-4b12f866e598 Jazz Singer Reel #1 Sound yH8lL/gA3y6Fnykmy+9Qmsp59g4= 4232864301 application/x-smpte.mxf urn:uuid:82ba97a0-b6fc-49af-9cfe-e090f4e4f524 Jazz Singer Composition List oloZQKdmLbtuVhTr8GuQYlQdcD0= 5258 text/xml 图 C.1 打包列表实例 DY/T 2.52020 16 参 考 文 献 1 World Wide Web Consortium (W3C)RDDLResource Directory Description Language J. Border and T. Bray 2002. http:/www.rddl.org/ 2 World Wide Web Consortium (W3C)Namespaces in XML, http:/www.w3.org/TR/REC-xml-names/ 3 World Wide Web Consortium (W3C)QA Framework: Specification Guidelines, Formal Languages, http:/www.w3.org/TR/2004/WD-qaframe-spec-20041122/ 4 World Wide Web Consortium (W3C) XML Schema Primer, http:/www.w3.org/ http:/www.iana.org/assignments/media-types 5 SMPTE 429-3-2006 D-Cinema PackagingSound and Picture Track File 6 SMPTE 429-7-2006 D-Cinema PackagingComposition Playlist _