Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26429-8：数字影院打包清单标准解读
深入解析数字影院打包清单（PKL） XML 清单格式、资产枚举、SHA-1 完整性验证与数字签名
一、打包清单概述与分发包模型
ISO 26429-8（SMPTE 429-8）规定了数字影院应用的打包清单（PKL）数据格式。打包清单是一个 XML 文档，枚举了数字影院分发包中的所有资产，包括合成播放列表、片断轨道文件和辅助内容。PKL 作为 DCP 的清单文件，提供了包内容的完整清单。一个分发包包含一个打包清单以及所有引用的资产。PKL 支持完整包（包含所有必要资产）和部分包（包含替换或补充资产以补充先前交付的包）。这种灵活性对于实际的分发工作流至关重要，因为内容修正、本地化版本和更新后的广告必须增量交付，而无需重新发布整个包。PKL 也是摄取系统的主要发现文档——通过首先解析 PKL，影院管理系统立即知道给定放映所需的完整资产清单，并可以在开始摄取过程之前验证可用性。在多厅影院环境中，PKL 还可以根据资产列表中的 CPL 引用将内容自动路由到正确的影厅。
一个关键的架构洞见在于：PKL 将资产标识与资产位置解耦。PKL 通过其 UUID 标识符列出资产，并提供完整性元数据（SHA-1 哈希值、大小），而实际的文件路径映射由资产映射（ISO 26429-9）处理。这种分层方法意味着 PKL 无论底层存储介质如何都保持有效，无论是硬盘驱动器、SSD、USB 闪存驱动器还是网络附加存储。这种解耦是 DCP 模型在各种放映系统之间可移植性的基础。
二、XML 结构与资产描述
PackingList 元素使用命名空间 http://www.smpte-ra.org/schemas/429-8/2007/PKL，包含标识信息（Id）、元数据（AnnotationText、Issuer、Creator）以及关键的 AssetList。每个 Asset 元素包含 Id（原始资产的 UUID）、Hash（Base64 编码的 SHA-1 摘要）、Size（字节数）、Type（MIME 类型）和可选的 OriginalFileName。Hash 元素对于摄取过程中的完整性验证至关重要——接收系统计算每个资产文件的 SHA-1 哈希值，并与 PKL 中的 Hash 值进行比较，检测传输过程中的任何损坏或篡改。SHA-1 哈希值对整个资产文件内容进行计算，包括 MXF 头、元数据和片断数据，提供从母版制作到放映的端到端完整性保证。PKL 还支持 Encrypted 元素，这是一个布尔标志，指示资产文件是否加密，允许摄取系统在处理之前预先分配解密资源。这种预分配能力对于需要按特定顺序处理多个资产的大规模摄取操作尤为重要，可以在严格的时间约束下高效完成。
| 资产类型 | MIME 类型 | 说明 |
|---|---|---|
| 合成播放列表 | text/xml | 定义播放顺序的 XML 文件（CPL） |
| 画面轨道文件 | application/x-smpte.mxf | 包含 JPEG 2000 编码画面片断的 MXF 文件 |
| 声音轨道文件 | application/x-smpte.mxf | 包含未压缩或 AES-3 音频片断的 MXF 文件 |
| 字幕轨道文件 | text/xml | 包含时间同步字幕数据的 XML 文件 |
PKL 支持使用 GroupId 关联相关包。这对于部分更新尤为重要——例如，发行商可以发送一个含有更正片尾字幕的替换本片卷。GroupId 允许影院管理系统（TMS）识别新包与先前交付的包相关，并相应地处理资产解析。如果没有 GroupId，每次部分更新都需要发送完整的包，这将大大增加微小更正和更新的分发成本。
三、数字签名与安全性
与 CPL 类似，打包清单支持使用 RSA-SHA256 和 X.509 证书链的封装式 XML 数字签名。Signature 元素对整个打包清单进行认证，整个证书链携带在 KeyInfo 元素中。签名约束与 CPL 一致：SHA-1 摘要、封装式签名转换、规范化 XML（xml-c14n）和 RSA-SHA256 签名方法。这种签名确保资产清单在包创建后不会被篡改，提供了从内容创作者到放映商的信任链。PKL 签名验证是 TMS 在摄取期间执行的第一个验证步骤之一——无效或缺失的签名会导致立即拒绝，阻止不受信任的内容进入影院播放环境。签名覆盖 PKL 中的每个资产条目，确保对资产列表的任何修改（添加、删除或修改条目）都能在签名验证时被立即检测到。
从工程工作流的角度来看，PKL 实现了自动化的摄取流水线。TMS 可以解析 PKL、验证签名、通过 SHA-1 哈希检查资产完整性，并在开始摄取过程之前验证所有引用的资产是否存在。任何差异都会导致立即拒绝，并附带清晰的诊断信息。这种自动化对于大型多厅影院运营至关重要，因为每天可能需要在多个影厅摄取数十个 DCP。
四、常见问题
问：一个分发包可以包含多个合成的资产吗？
答：可以，单个 DCP（及其 PKL）可以包含多个合成的资产，但典型用例是每个包一个合成。PKL AssetList 列出所有资产，无论它们属于哪个合成。
答：可以，单个 DCP（及其 PKL）可以包含多个合成的资产，但典型用例是每个包一个合成。PKL AssetList 列出所有资产，无论它们属于哪个合成。
问：PKL 如何处理部分更新？
答：部分包使用 GroupId 元素与先前交付的包关联。例如，如果故事片的片尾字幕需要更正，可以分发仅包含替换本片卷和新 CPL 的部分 DCP。接收端 TMS 使用 GroupId 将新包与原始包链接并解析资产引用。
答：部分包使用 GroupId 元素与先前交付的包关联。例如，如果故事片的片尾字幕需要更正，可以分发仅包含替换本片卷和新 CPL 的部分 DCP。接收端 TMS 使用 GroupId 将新包与原始包链接并解析资产引用。
问：如果资产的 SHA-1 哈希值不匹配会发生什么？
答：摄取过程应拒绝该资产并报告不匹配。这表示传输过程中的数据损坏或存储介质错误。发行商必须重新交付受影响的资产。这是数字影院分发链中的主要完整性检查。
答：摄取过程应拒绝该资产并报告不匹配。这表示传输过程中的数据损坏或存储介质错误。发行商必须重新交付受影响的资产。这是数字影院分发链中的主要完整性检查。
问：OriginalFileName 元素是否可靠用于资产标识？
答：不可靠。OriginalFileName 严格用于信息目的（”为用户提供显示指南”）。权威的资产标识符是 Id 元素中的 UUID。系统绝不能依赖文件名进行资产标识或匹配。
答：不可靠。OriginalFileName 严格用于信息目的（”为用户提供显示指南”）。权威的资产标识符是 Id 元素中的 UUID。系统绝不能依赖文件名进行资产标识或匹配。
