本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # SPEKE API v2 - 加密合約加密合約會根據軌跡特性，定義哪些內容金鑰正在保護指定串流集中的追蹤。雖然是建議的業界最佳實務，但在串流集中對不同音軌使用多個內容金鑰並非強制性，但建議使用 - 至少兩個不同的內容金鑰，一個用於音訊音軌，另一個用於視訊音軌。可以使用單一內容金鑰來加密多個軌道，但需要在加密程式傳送至金鑰提供者的 CPIX 文件中明確發出訊號。一般而言，加密程式一律準確描述需要多少內容金鑰，以及如何利用這些金鑰來加密各種媒體軌。 **原則** 加密合約位於 CPIX 文件的 ``區段。在本節中， `` 區段中定義的每個內容金鑰對應至特定``元素，其中應包含： + 可以參考一或多個子元件的`ContentKeyUsageRule@intendedTrackType`屬性，如果使用多個子元件，則以「＋」符號分隔。的值`ContentKeyUsageRule@intendedTrackType`在加密合約中應是唯一的，不能用於多個`ContentKeyUsageRule`元素。 + 一或多個 `` 或 `` 子元素，取決於`ContentKeyUsageRule@intendedTrackType`屬性的值。管理此關係的規則如下： + 當串流集的所有音訊和視訊軌都需要使用唯一的內容金鑰保護時，`'ALL'`必須使用字串做為`ContentKeyUsageRule@intendedTrackType`屬性值。範例 1 顯示這類使用案例。在這種情況下，應同時包含不含任何屬性的 ``和``子元素。`` 和/或 `` 元素的任何其他組合在此特定內容中無效。 + 對於所有其他使用案例，可以自由定義`ContentKeyUsageRule@intendedTrackType`屬性的值，且 ``和``子元素的數量必須對應至透過 '\+' 符號彙總的子元件數量。當`ContentKeyUsageRule@intendedTrackType`屬性值中存在單一子元件時，範例 2/3/4/5/6/7/9/10 會說明此需求。範例 8 會在使用多個子元件時加以說明：由具有不同屬性值的兩個不同``子元素`ContentKeyUsageRule@intendedTrackType="SD+HD"`描述，而由具有不同屬性值的三個不同``子元素`ContentKeyUsageRule@intendedTrackType="HDR+HFR+UHD"`描述。 **篩選條件** CPIX 定義多個篩選元素和屬性，但 SPEKE 僅支援其中一部分。下表摘要說明這些差異： | CPIX 篩選條件類型 | 整體 SPEKE 支援 | SPEKE 支援的篩選條件屬性 | SPEKE 不支援篩選條件屬性 | | --- | --- | --- | --- | | | 是 | minPixels、maxPixels、hdr、minFps、maxFps （選用屬性） | wcg | | | 是 | minChannels、maxChannels （選用屬性） | | | | 是 | periodId （必要屬性） | | | | 否 | N/A | N/A | | | 否 | N/A | N/A | 根據 VideoFilter 的 CPIX 規格，【minPixels， maxPixels】是兩個維度中的所有包含範圍，而 (minFps， maxFps】僅包含 maxFps 維度。對於 AudioFilter，【minChannels， maxChannels】是兩個維度中的包含範圍。 **有問題的情況** 在某些情況下，加密合約中提供的資訊可能是部分、不明確或錯誤。在這些情況下，加密程式和金鑰提供者的行為必須適當，並保證對內容提供適當的保護。下表顯示在這些情況下的建議行為： | 在這種情況下 | 加密程式應該/應... | 金鑰提供者應該/應... | | --- | --- | --- | | 沒有規則適用於串流集中的一或多個音軌（請參閱下面的範例 3) | 加密程式應查看其組態 (CPIX 承載外部），並確認相關軌道不需要加密。如果不是預期，加密程式應該擲回錯誤並停止處理。 | *不相關：金鑰提供者不了解串流集結構。* | | 多個規則重疊，並建議多個內容金鑰來加密特定軌道 | 加密程式應該按照文件的順序套用最後一個成功評估的 ContentKeyUsageRule。 | *不相關：金鑰提供者不了解串流集結構。* | | 加密合約會在單一 SPEKE 請求/回應週期中變更 | 加密程式應引發例外狀況並停止處理，因為金鑰提供者不負責定義加密合約。 | 為避免這種情況發生，金鑰提供者不得修改 SPEKE 請求的 CPIX 承載中收到的加密合約。 | | 格式錯誤的加密合約：intendedTrackType/Filters 基數限制例外狀況、不支援的篩選條件或屬性 | 加密程式應引發例外狀況、停止處理，且不會將 SPEKE 請求傳送至金鑰提供者，因為這很可能會導致內容保護錯誤，或使某些軌跡未受保護。 | 金鑰提供者應引發例外狀況，並傳回「格式化加密合約」錯誤。 | | 格式良好的加密合約，但違反 DRM 安全層級限制：例如，請求單一內容金鑰來保護音訊音軌和 UHD 視訊音軌 | 如果加密程式了解 DRM 安全層級限制，應該引發例外狀況、停止處理，而且不會將 SPEKE 請求傳送給金鑰提供者，因為這很可能會導致內容保護錯誤。 | 金鑰提供者應引發例外狀況，並傳回「不支援請求的 CPIX 加密合約」錯誤。 | | 缺少加密合約 | 加密程式不應傳送不包含任何 VideoFilter 或 AudioFilter 元素的 CPIX 文件。 | 金鑰提供者應引發例外狀況，並傳回「缺少 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：一個內容金鑰用於所有影片音軌、多個內容金鑰用於立體聲，以及兩種類型的多聲道音軌* ``` ```