本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # SPEKE API v2 - 加密合约加密合约根据轨道特征定义使用哪些内容密钥来保护给定流集中的哪些轨道。建议将多个内容密钥用于流集中的不同轨道，但这并不是强制性，而是建议的行业最佳实践 - 至少使用两个不同的内容密钥，一个用于音频轨道，一个用于视频轨道。使用单个内容密钥加密多个轨道是可能的，但需要在加密程序发送给密钥提供程序的 CPIX 文档中明确发出信号。一般而言，加密程序总是准确描述需要多少内容密钥以及如何利用它们来加密各种媒体轨道。 **原则** 加密合约位于 CPIX 文档的 `` 部分。在此部分中，`` 部分中定义的每个内容密钥都对应一个特定的 `` 元素，其中应包括： + 可以引用一个或多个子组件的 `ContentKeyUsageRule@intendedTrackType` 属性，如果使用多个子组件，则用“\+”符号分隔。`ContentKeyUsageRule@intendedTrackType` 的值在加密合约中应是唯一的，并且不能用于多个 `ContentKeyUsageRule` 元素。 + 一个或多个 `` 或 `` 子元素，具体取决于 `ContentKeyUsageRule@intendedTrackType` 属性的值。管理这种关系的规则如下： + 当需要使用唯一的内容密钥保护流集中的所有音频和视频轨道时，必须使用字符串 `'ALL'` 作为 `ContentKeyUsageRule@intendedTrackType` 属性值。示例 1 显示这样的使用案例。在这种情况下，应包括没有任何属性的 `` 和 `` 子元素。在此特定上下文中，任何其他`` and/or ``元素组合均无效。 + 对于所有其他使用案例，可以自由定义 `ContentKeyUsageRule@intendedTrackType` 属性的值，并且 `` 和 `` 子元素的数量必须与通过“\+”符号聚合的子组件数量相对应。示例 2/3/4/5/6/7/9/10 说明了当 `ContentKeyUsageRule@intendedTrackType` 属性值中存在单个子组件时的这一要求。示例 8 说明了使用多个子组件的情况：`ContentKeyUsageRule@intendedTrackType="SD+HD"` 由两个具有不同属性值的不同 `` 子元素描述，`ContentKeyUsageRule@intendedTrackType="HDR+HFR+UHD"` 由三个具有不同属性值的不同 `` 子元素描述。 **筛选条件** CPIX 定义了多个筛选元素和属性，但是 SPEKE 仅支持其中的一个子集。下表对这些不同情况进行了汇总： | CPIX 筛选条件类型 | 整体 SPEKE 支持 | SPEKE 支持的筛选条件属性 | SPEKE 不支持的筛选条件属性 | | --- | --- | --- | --- | | VideoFilter | 是 | minPixels、maxPixels、hdr、minFps、maxFps（可选属性） | wcg | | AudioFilter | 是 | minChannels、maxChannels（可选属性） | | | KeyPeriodFilter | 是 | periodId（强制属性） | | | BitrateFilter | 否 | 不适用 | 不适用 | | LabelFilter | 否 | 不适用 | 不适用 | 根据CPIX的规范 VideoFilter，[minPixels，maxPixels] 是两个维度的全包范围，而（minFPs，maxFPS）仅包含在maxFPS维度上。因为 AudioFilter，[minChannels，MaxChannels] 在两个维度上都是一个包含范围。 **问题情况** 在某些情况下，加密合约中提供的信息可能不完整、含糊不清或存在错误。在这些情况下，加密程序和密钥提供程序必须采取适当的行为并保证对内容的适当保护。下表列出了在这些情况下的建议行为： | 在这种情况下 | 加密器... should/shall | 密钥提供商 should/shall ... | | --- | --- | --- | | 没有规则适用于流集中的一个或多个轨道（参见下面的示例 3） | 加密程序应查看其配置（CPIX 负载外部），并验证相关轨道是否不需要加密。如果不是预期情况，则加密程序应引发错误并停止处理。 | *不相关：密钥提供程序不了解流集结构。* | | 多个规则重叠并建议使用多个内容密钥来加密特定轨道 | 加密器应按文档顺序应用最后一次 ContentKeyUsageRule 成功评估的结果。 | *不相关：密钥提供程序不了解流集结构。* | | 加密合约在单个 SPEKE request/response 周期内发生变化 | 加密程序应引发异常并停止处理，因为密钥提供程序不负责定义加密合约。 | 为了防止这种情况发生，密钥提供程序不得修改在 SPEKE 请求的 CPIX 负载中收到的加密合约。 | | 格式错误的加密合约： intendedTrackType/Filters 基数约束异常、不支持的过滤器或属性 | 加密器程序引发异常，停止处理，并且不向密钥提供程序发送 SPEKE 请求，因为这很可能会导致错误的内容保护或使某些轨道不受保护。 | 密钥提供程序应引发异常并返回“格式错误的加密合约”错误。 | | 格式良好的加密合约，但违反了 DRM 安全级别的约束：例如，要求使用单个内容密钥来保护音频轨道和超高清视频轨道 | 如果加密程序了解 DRM 安全级别约束，则应引发异常，停止处理，不向密钥提供程序发送 SPEKE 请求，因为这很可能会导致错误的内容保护。 | 密钥提供程序应引发异常并返回“不支持请求的 CPIX 加密合约”错误。 | | 缺少加密合约 | 加密器不得发送不包含任何或 VideoFilter 元素的CPIX文档。 AudioFilter | 密钥提供程序应引发异常并返回“缺少 CPIX 加密合约”错误。 | **加密合约示例** *示例 1：所有音频和视频轨道都使用一个内容密钥* ``` ``` *示例 2：一个内容密钥用于所有视频轨道，一个内容密钥用于所有音频轨道* ``` ``` *示例 3：一个内容密钥用于所有视频轨道和未加密的音频轨道* ``` ``` *示例 4：多个内容密钥用于不同的视频轨道（SD/HD），一个内容密钥用于所有音频轨道* ``` ``` *示例 5：多个内容键用于不同的视频轨道 (SD/HD/UHD)，一个内容键用于所有音轨* ``` ``` *示例 6：多个内容键用于不同的视频轨道 (SD/HD/UHD1/UHD2)，一个内容键用于所有音轨* ``` ``` *示例 7：不同的视频轨道有多个内容键 (SD/HD1/HD2/UHD1/UHD2)，一个内容键用于所有音轨* ``` ``` *示例 8：多个内容密钥用于不同的视频轨道（基于多个属性类型），一个内容密钥用于所有音频轨道* ``` ``` *示例 9：一个内容密钥用于所有视频轨道，多个内容密钥用于立体声和多声道音频轨道* ``` ``` *示例 10：一个内容密钥用于所有视频轨道，多个内容密钥用于立体声和两种类型的多声道音频轨道* ``` ```