ProtectionCapabilities.IsTypeSupported(String, String) 方法
定義
重要
部分資訊涉及發行前產品,在發行之前可能會有大幅修改。 Microsoft 對此處提供的資訊,不做任何明確或隱含的瑕疵擔保。
查詢DRM功能的視訊譯碼、顯示和輸出保護子系統的功能。
警告
建議此方法只與 Windows 10 版本 1607 或更新版本的作業系統搭配使用,即使舊版 Windows 10 上仍存在此方法。
public:
virtual ProtectionCapabilityResult IsTypeSupported(Platform::String ^ type, Platform::String ^ keySystem) = IsTypeSupported;
ProtectionCapabilityResult IsTypeSupported(winrt::hstring const& type, winrt::hstring const& keySystem);
public ProtectionCapabilityResult IsTypeSupported(string type, string keySystem);
function isTypeSupported(type, keySystem)
Public Function IsTypeSupported (type As String, keySystem As String) As ProtectionCapabilityResult
參數
- type
-
String
Platform::String
winrt::hstring
字串,識別查詢支援的功能。 此參數接受 RFC 2045 內容類型字串來指定媒體類型和子類型識別碼,以及所需的編解碼器的 RFC 6381 編解碼器識別碼。 這些基底字串與 HTML5 HTMLMediaElementcanPlayType 方法中使用的字串一致。 RFC 2045 允許以 ";<parameter>=<name>[=<value>] [,<name>[=<value>]"
形式作為修飾詞的其他自定義參數。 如果無法辨識,RFC 2045 相容剖析器必須忽略這些參數。 針對功能查詢,<parameter>
名為 功能。
實作需要 RFC 2045 媒體類型和子類型識別碼,例如“video/mp4”,以及 RFC 6381 編解碼器參數 codec=”<video codec>[,<audio codec>]”
,才能提供有效的查詢結果。
請注意,字詞內容類型和類型在歷史上是眾所周知的,MIME 類型。
- keySystem
-
String
Platform::String
winrt::hstring
字串,識別要檢查查詢的 PlayReady 命名空間,並指定硬體或軟體保護。 針對硬體查詢使用 「com.microsoft.playready.recommendation.3000」 (PlayReady 必須支持硬體卸除)、“com.microsoft.playready.recommendation.2000” 明確查詢軟體保護支援,以及一般查詢的 “com.microsoft.playready.recommendation”。
傳回
值,指出查詢的功能是否可能受到支援、可能支援或不受支援。
備註
類型 輸入參數必須有 RFC 6381 內容類型媒體類型和子類型識別碼存在。 它也必須有 RFC 2045 編解碼器參數位符串存在。 MPEG-4 是此 API 唯一支援的容器。 H.264 (avc1) 和 HEVC (hvc1, hev1) 是唯一提供支援答案的視頻編解碼器。 MPEG-4 (mp4a)、MPEG-1 第 3 層 (mp3)、Dolby Digital (ac-3) 和 Dolby Digital Plus (ec-3) 是唯一提供支援答案的音頻編解碼器。 支援的字串包括:
video/mp4;codecs=”avc1,<audio codec>”
video/mp4;codecs=”hvc1, <audio codec>”
video/mp4;codecs=”hev1, <audio codec>”
從 Windows 10 版本 1709 開始,也支援下列各項:
Video/mp4;codecs=”vp9,<audio codec>”
Video/mp4;codecs=”vp09,<audio codec>”
查詢字串的功能部分會附加至使用分號分隔符的上述字串。 基礎圖形驅動程式和硬體會對如何查詢功能施加限制。 針對視訊子系統,適用下列需求:
- 單一呼叫中每個子系統只能使用一個功能名稱加上值的查詢
- 譯碼子系統查詢可以在沒有顯示 1、顯示 2 或輸出保護查詢的情況下執行
- Display 1 子系統查詢需要有譯碼子系統查詢
- Display 2 子系統查詢需要譯碼子系統查詢,但不需要 Display 1 子系統查詢。
- 輸出保護子系統 (HDCP) 查詢可以搭配或不使用譯碼、顯示 1 或 Display 2 子系統查詢來執行,但受限於條件約束 #3 和 #4。
General: Efficiency
查詢可以與任何其他子系統查詢結合。
傳回的結果是所有個別功能查詢的邏輯 AND,其中包含下列釐清:可能 結果只允許來自輸出保護子系統,而且只能暫時使用。 這個 也許 優先於其他所有功能查詢的 AND 所產生的 可能 結果,直到 也許 會隨著時間解析為 可能 或 不支援。 可能 解析的目前時間限製為10秒。
下表列出視訊子系統組織的支持的個別功能查詢:
專案 | 視訊子系統 | 功能名稱 | 功能值 | 描述 | 此子系統的必要專案 |
---|---|---|---|---|---|
1a | 解碼 | decode-res-x | 以像素為單位的非負數 | 視訊譯碼器是否支援 X 軸中的這個最大解析度? | Y |
1b | 解碼 | decode-res-y | 以像素為單位的非負數 | 視訊譯碼器是否支援Y軸中的這個最大解析度? | Y |
1c | 解碼 | 譯碼比特率 | 每秒千位的正數 (Kbps) | 影片譯碼器是否支援此最大比特率? | Y |
1d | 解碼 | decode-fps | 24、25、29.97、30、50、59.94 或 60 | 視訊譯碼是否支援每秒最大畫面數 (FPS) 值? | Y |
1e | 解碼 | decode-bpc (decode-bpp 已被取代) | 0、8、10 或 12 | 視訊譯碼器是否可以取用這個每圖元的色彩深度? | Y |
1f | 解碼 | decoder-hardware-acceleration** | 1 或沒有值為 true | 不論操作系統譯碼器是否存在,DXVA 硬體加速是否可用? | N |
1g | 解碼 | decoder-software-acceleration ** | 1 或沒有值為 true | OS 譯碼器是否能夠譯碼數據流? | N |
1 小時 | 解碼 | decoder-software-requires-hardware** | 1 或沒有值為 true | OS 譯碼器的功能是否需要 DXVA 硬體加速存在? | N |
2a | 顯示 1 | display-res-x | 以像素為單位的非負數 | 至少一個交集** 顯示器是否支援 X 軸中的這個解析度? | Y |
2b | 顯示 1 | display-res-y | 以像素為單位的非負數 | 至少一個交集*** 顯示器是否支援Y軸中的這個解析度? | Y |
2c | 顯示 1 | display-refreshrate | 24、25、29.97、30、50、59.94 或 60 | 顯示器是否已設定為至少要求重新整理速率,如 Windows 所瞭解? | N |
二 維和 | 顯示 1 | display-bpc (display-bpp 已被取代) | 8 或 10 | 所有與≥需要解析度的交集顯示器是否至少能實現此色彩深度? | N |
3 | 顯示 2* | hdr | 1 (支援) | 目標是否支援高動態範圍 (HDR) 轉譯 | Y |
4 | 輸出保護 | hdcp | 0 (關閉),1 (不含 HDCP 2.2 類型 1 限制), 2 (開啟與 HDCP 2.2 類型 1 限制 | 所有已啟用交集的顯示是否至少支援要求保護層級? | Y |
5 | 一般:效率** | 效率設定 | 0 (關閉 = 沒有限制),1 (on = 在電池電源時限制解析度) | 使用者是否想要使用電池使用時間、串流額外負荷和/或下載速度,而偏好使用最高解析度?**** | Y |
6a | 解密 | encryption-type | “cenc” 或 “cbcs” | 此加密類型是否支援使用指定的編解碼器/金鑰系統進行解密? 如果未指定 value,則會使用預設值 「cenc」。 | N |
6b | 解密 | encryption-iv-size | 8 或 16 | 這個初始化向量 (IV) 大小 (以位元組為單位) 是否支援使用指定的編解碼器/金鑰系統進行解密? 如果未指定 value,則會使用預設值 8。 | N |
* 僅支援 Windows 10 版本 1607 和更新版本的作業系統版本
** 僅支援 Windows 10 版本 1709 和更新版本的作業系統版本
*** 交集演算法為:
- 尋找所有顯示應用程式使用者介面視訊用戶端區域具有圖元的位置。
- 尋找從步驟 1 驅動顯示器的所有圖形適配卡。 針對硬體DRM查詢,此組適配卡只會篩選為具有硬體DRM支援的適配卡。
- 尋找連接到步驟 2 之圖形適配卡的所有顯示器。
**** 此原則開啟時,內容提供者必須選擇要使用的解析度限制。 建議使用 1080p 限制,但可以使用 720p。 請注意,此原則的輸入來自 Windows 10 版本 1709 中新增的影片設定使用者介面頁面。
專案 1a 和 1b 和 2a 和 2b 的配對會計算為 (要求的 x >= 實際交集最大值 x) AND (要求 y >= 實際交集最大值 y),修改直向顯示會視需要交換 x 和 y 來正規化為橫向。
hdcp 查詢 (專案 4) 具有計算成本高昂的第一個叫用成本。 HDCP 必須在要求層級開啟,才能探查要求層級是否符合使用中顯示拓撲。 可能 結果,因為 HDCP 是以異步方式評估,且最多需要數秒的 HDCP 2.2,但查詢以最少封鎖同步,要求呼叫端重複使用查詢,直到結果完成為 可能 或 不支援。 在查詢中變更要求的 HDCP 層級,但仍處於「可能」狀態時,可能會產生無效的回應。 也許 逾時大約是 10 秒。
強烈建議不要每隔 250 毫秒多次叫用 hdcp 查詢,因為基礎計算成本。 500 毫秒是慣用的最小值。 快取會執行,以將此成本降到最低,但在輪詢時,任何顯示拓撲變更都會使快取失效。
作為實作詳細數據,即使尚未設定 HDCP 2.2 類型 1 限制,圖形適配卡還是可以選擇使用 HDCP 2.2。 HDCP 2.2 可能需要比 HDCP 1.x 更久的時間才能參與。 對目前世代電視的觀察顯示最多 8 秒的時間,而 HDCP 1.x 裝置的觀察時間約為 1 秒,包括重複器。 因此,在應用程式啟動時或輸出拓撲變更之後,第一個 hdcp=1
查詢需要等候最多 8 秒,以及此最壞情況的邊界。 使用 10 秒作為最大等候時間,建議在使用者最不預期的情況下選取標題時執行應用程式啟動查詢,例如在初始 UI 上。 如果沒有發生拓撲變更,則所有進一步的 hdcp 查詢都會是次秒。 如果內容與查詢具有相同的 HDCP 輸出需求,快取將會在播放開始時再次執行多秒等候。
在輸出拓撲變更上,高解析度電視與監視器通常需要幾秒鐘的時間才能穩定桌面。 變更,特別是減少輸出保護層級,通常會因為設計而造成硬體DRM的作用中播放失敗。 在這裡,對 MF_POLICY_UNSUPPORTED(0xC00D7159)錯誤的反應應該是隱藏使用者的錯誤、重新查詢,以及繼續使用適當的內容版本來取得任何變更的功能。 實際上,這可作為“熱插機”穩定時間的延伸。
軟體DRM譯碼功能查詢在效能上可能模棱兩可,因為H.264實作允許軟體譯碼或 DirectX 視訊加速 (DXVA) GPU 卸除。 不過,在所有 Windows 端點中,H.264 DXVA 非常常見。
軟體DRM譯碼查詢的功能限制是不會評估譯碼-bpc。 Windows 不支援 H.264 10 位譯碼,但具有 decode-bpc=10
的查詢將會成功。
功能查詢結果反映子系統的最大理論功能。 GPU 或不同電源狀態中的其他活動可能會降低實際功能。
硬體DRM查詢範例
以下顯示 4K 10 位 HEVC 標準動態範圍 (SDR) 內容與硬體 DRM 和 HDCP 2.2 類型 1 限制最常見的用法:
IsTypeSupported(‘com.microsoft.playready.recommendation.3000’,’video/mp4;codecs=”hvc1,mp4a”;features=”decode-res-x=3840,decode-res-y=2160,decode-bitrate=20000,decode-fps=30,decode-bpc=10,display-res-x=3840,display-res-y=2160,display-bpc=8,hdcp=2”’);
其中 mp4a
可取代為 mp3
、ac-3
或 ec-3
。 根據內容提供者的編碼方式,可調整譯碼比特率。
decode-fps
可能會設定為 60 而非 30,但可能會受到硬體 DRM 安全性處理器的輸送量功能所管制。 例如,如果提供者想要將 4K 數據流推送至 3200 x 1800、3000 x 2000 或 2560 x 1440 顯示,則 display-res-x
和 display-res-y
值可能會設定為低於完整 4K。
由於譯碼查詢結果不預期會動態變更,在 [可能] 中,連續輪詢 hdcp=2
,而在 [可能] 中,可以使用較短的形式做為小型優化
IsTypeSupported(‘com.microsoft.playready.recommendation.3000’,’video/mp4;codecs=”hvc1,mp4a”;features=”hdcp=2”’);
當然,此優化不會攔截動態監視器解析度變更,但這類變更可能會中斷HDCP的建立。
以下顯示 4K 10 位 HEVC 高動態範圍 (HDR) 內容與硬體 DRM 和 HDCP 2.2 類型 1 限制最常見的用法:
IsTypeSupported(‘com.microsoft.playready.recommendation.3000’,’video/mp4;codecs=”hvc1,mp4a”;features=”decode-res-x=3840,decode-res-y=2160,decode-bitrate=20000,decode-fps=30,decode-bpc=10,display-res-x=3840,display-res-y=2160,display-bpc=8,hdr=1,hdcp=2”’);
注意:針對 Windows 10 版本 1607,hdr=1
指出具有 DXGI_COLOR_SPACE_YCBCR_FULL_G22_LEFT_P2020 或 DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 或 DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020 的 10 位 MPO 支援,或僅開發 HighColor 登錄機碼存在且已設定: HKLM\SOFTWARE\Microsoft\Windows\DWM key HighColor
為 DWORD 值 1。
以下顯示 1080p 8 位 H.264 SDR 內容與硬體 DRM 和 HDCP 沒有 2.2 類型 1 限制的最常見用法:
IsTypeSupported(‘com.microsoft.playready.recommendation.3000’,’video/mp4;codecs=”avc1,mp4a”;features=”decode-res-x=1920,decode-res-y=1080,decode-bitrate=10000,decode-fps=30,decode-bpc=8,display-res-x=1920,display-res-y=1080,display-bpc=8,hdcp=1”’);