IMFExtendedDRMTypeSupport：：IsTypeSupportedEx 方法 (mfmediaengine.h)
查詢指定的索引鍵系統是否支援指定的內容類型。
語法
HRESULT IsTypeSupportedEx(
[in] BSTR type,
[in] BSTR keySystem,
[out] MF_MEDIA_ENGINE_CANPLAY *pAnswer
);
參數
[in] type
BSTR，識別查詢支援的功能。 此參數接受 RFC 2045 內容類型字串來指定媒體類型和子類型識別碼，並針對所需的編解碼器指定 RFC 6381 編解碼器識別碼。 這些基底字串與 HTML5 HTMLMediaElement canPlayType 方法中使用的字串一致。 RFC 2045 允許以 “;<parameter>=<name>[=<value>] [，<name>[=<value>]“。 如果無法辨識，RFC 2045 相容剖析器必須忽略這些參數。 針對功能查詢，會命名為feature。
實作需要 RFC 2045 媒體類型和子類型標識碼，例如 “video/mp4”，以及 RFC 6381 編解碼器參數 codec=“<video codec[，<audio codec>>]”，才能提供有效的查詢結果。
請注意，字詞內容類型和類型在過去已知為MIME類型。
[in] keySystem
BSTR，識別 PlayReady 命名空間以檢查查詢，並指定硬體或軟體保護。 針對硬體查詢使用 「com.microsoft.playready.recommendation.3000」， (PlayReady 必須支持硬體卸除) 、“com.microsoft.playready.recommendation.2000” 明確查詢軟體保護支援，以及 “com.microsoft.playready.recommendation) (”。
[out] pAnswer
來自 MF_MEDIA_ENGINE_CANPLAY 列舉的值，指出可能支援、可能支援或不支持查詢的功能。
傳回值
成功時S_OK。
備註
類型輸入參數必須存在 RFC 6381 內容類型媒體類型和子類型識別碼。 它也必須有 RFC 2045 Codecs 參數位符串存在。 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秒。
下表列出支持的個別功能查詢，並依影片子系統組織：
| 項目 | 視訊子系統 | 功能名稱 | 功能值 | Description | 此子系統的必要專案 |
|---|---|---|---|---|---|
| 1a | 解碼 | decode-res-x | 以像素為單位的非負數 | 視訊譯碼器是否支援 X 軸的這個最大解析度？ | 是 |
| 1b | 解碼 | decode-res-y | 以像素為單位的非負數 | 視訊譯碼器是否支援Y軸的這個最大解析度？ | 是 |
| 1c | 解碼 | 譯碼比特率 | 每秒 kbps (Kbps) 的正數 | 視訊譯碼器是否支援此最大比特率？ | 是 |
| 1d | 解碼 | decode-fps | 24、25、29.97、30、50、59.94 或 60 | 已譯碼的視訊是否支援每秒的最大畫面格數， (FPS) 值？ | 是 |
| 1e | 解碼 | decode-bpc (decode-bpp 已被取代) | 0、8、10 或 12 | 視訊譯碼器是否可以取用這個每個圖元的色彩深度？ | 是 |
| 1f | 解碼 | decoder-hardware-acceleration** | 1 或沒有值為 true | 不論操作系統譯碼器是否存在，DXVA 硬體加速是否可用？ | 否 |
| 1g | 解碼 | decoder-software-acceleration ** | 1 或沒有值為 true | OS 譯碼器是否能夠譯碼數據流？ | 否 |
| 1h | 解碼 | decoder-software-requires-hardware** | 1 或沒有值為 true | OS 譯碼器的功能是否需要 DXVA 硬體加速存在？ | 否 |
| 2a | 顯示 1 | display-res-x | 以像素為單位的非負數 | 至少一個交集** 顯示器是否支援 X 軸中的這個解析度？ | 是 |
| 2b | 顯示 1 | display-res-y | 以像素為單位的非負數 | 至少一個交集*** 顯示器是否支援Y軸中的這個解析度？ | 是 |
| 2c | 顯示 1 | display-refreshrate | 24、25、29.97、30、50、59.94 或 60 | Windows) 是否至少瞭解要求的重新整理速率，設定 (顯示？ | 否 |
| 2d | 顯示 1 | display-bpc (display-bpp 已被取代) | 8 或 10 | 所有與≥必要解析度的交集顯示器是否至少瞭解此色彩深度？ | 否 |
| 3 | 顯示 2* | hdr | 1 (支援) | 目標是否支援高動態範圍 (HDR) 轉譯 | Y |
| 4 | 輸出保護 | hdcp | 0 (關閉) ,1 (開啟，不含 HDCP 2.2 類型 1 限制) ,2 (開啟 HDCP 2.2 類型 1 限制 | 啟用的所有交集是否至少支援要求保護層級？ | 是 |
| 5 | 一般：效率** | 效率設定 | 0 (off = 沒有限制) ,1 (on = 在電池電源時限制解析) | 使用者是否想要使用電池使用時間、串流額外負荷和/或下載速度，以達到最高解析度？**** | 是 |
| 6a | 解密 | encryption-type | “cenc” 或 “cbcs”，具有選擇性的 “-clearlead” 後綴。 | 此加密類型是否支援使用指定的編解碼器/金鑰系統進行解密？ 如果未指定 value，則會使用預設值 「cenc」。 從 Windows 組建 22621 開始，支持後綴 “-clearlead”。 將 「-clearlead」 附加至加密類型值時，也會要求在加密內容開頭使用清除內容的支援。 清除內容開頭的內容可加快呈現第一個畫面的時間。 如果 「-clearlead」 新增至加密類型，則會檢查所要求編解碼器的版本號碼。 AV1 和 VP9 編解碼器將會檢查主要版本 2，且 HEVC 將會檢查 v2.0.53421 或更新版本。 | 否 |
| 6b | 解密 | encryption-iv-size | 8 或 16 | 這個初始化向量 (IV) 大小 (位元組) 是否支援使用指定的編解碼器/金鑰系統進行解密？ 如果未指定 value，則會使用預設值 8。 | 否 |
*僅支援 Windows 10 版本 1607 和較新的作業系統版本
**僅支援 Windows 10 版本 1709 和較新的作業系統版本
*** 交集演算法為：
- 尋找應用程式使用者介面視訊用戶端區域具有圖元的所有顯示位置。
- 尋找從步驟 1 驅動顯示器的所有圖形配接器。 針對硬體DRM查詢，此一組適配卡只會篩選為具有硬體DRM支援的適配卡。
- 尋找連接到圖形配接器的所有顯示器， (步驟 2 的) 。
**** 內容提供者必須選擇此原則開啟時要使用的解析限制。 建議使用 1080p 限制，但可以使用 720p。 請注意，此原則的輸入來自 Windows 10 1709 版中新增的 [影片設定] 使用者介面頁面。
專案 1a 和 1b 和 2a 和 2b 的配對會計算為 (要求的 x >= 實際交集集最大值 x) AND (要求 y = 實際交集集最大值 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) 錯誤的回應應該是隱藏使用者的錯誤、重新查詢，以及針對任何變更的功能繼續適當的內容版本。 實際上，這可做為「hotplug」 防震時間的延伸。
當 H.264 實作允許軟體譯碼或 DirectX 視訊加速 (DXVA) GPU 卸除時，軟體 DRM 譯碼功能查詢可能會模棱兩可。 不過，H.264 DXVA 在所有 Windows 端點中非常常見。
軟體DRM譯碼查詢的功能限制是不會評估譯碼 bpc。 Windows 不支援 H.264 10 位譯碼，但具有 的 decode-bpc=10 查詢將會成功。
功能查詢結果反映子系統的最大理論功能。 GPU 中的其他活動或不同的電源狀態可能會降低實際功能。
硬體DRM查詢範例
以下顯示 4K 10 位 HEVC Standard Dynamic Range (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 安全性處理器的輸送量功能所管制。 display-res-x 如果提供者想要將 4K 數據流推送至 3200 x 1800、3000 x 2000 或 2560 x 1440 顯示，則 和 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”’);
規格需求
| 標頭 | mfmediaengine.h |