共用方式為

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 編解碼器參數位符串存在。 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. 譯碼子系統查詢可以在沒有顯示 1、顯示 2 或輸出保護查詢的情況下執行
  3. Display 1 子系統查詢需要有譯碼子系統查詢
  4. Display 2 子系統查詢需要譯碼子系統查詢，但不需要 Display 1 子系統查詢。
  5. 輸出保護子系統 （HDCP） 查詢可以搭配或不使用譯碼、顯示 1 或 Display 2 子系統查詢來執行，但受限於條件約束 #3 和 #4。

查詢 General: Efficiency 可以與任何其他子系統查詢結合。

傳回的結果是所有個別功能查詢的邏輯 AND，其中釐清了下列事項： 也許 結果只允許來自輸出保護子系統，而且只暫時允許。 這也許優先於所有其他功能查詢的 AND 結果，直到「可能」解析為「可能」或「不支援」為止。 可能解析的目前時間限製為10秒。

下表列出視訊子系統組織的支持的個別功能查詢：

項目 視訊子系統 功能名稱 特徵值 說明 此子系統的必需事項
1a 解碼 decode-res-x 以像素為單位的非負數 視訊譯碼器是否支援 X 軸中的這個最大解析度？ 是
1b 解碼 decode-res-y 以像素為單位的非負數 視訊譯碼器是否支援Y軸中的這個最大解析度？ 是
1c 解碼 解碼比特率 每秒千位的正數 （Kbps） 影片譯碼器是否支援此最大比特率？ 是
1天 解碼 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 硬體加速是否可用？ 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 軸中至少有一個交集** 顯示器支援這個解析度嗎？ 是
2b 顯示 1 display-res-y 以像素為單位的非負數 至少一個交集*** 顯示器是否支援Y軸中的這個解析度？ 是
2c 顯示 1 顯示更新率 24、25、29.97、30、50、59.94 或 60 顯示器的設定是否已達到 Windows 所要求的最低更新頻率？ N
二維 顯示 1 display-bpc（display-bpp 已被淘汰） 8 或 10 所有與≥需要解析度的交集顯示器是否至少能實現此色彩深度？ N
3 顯示 2* hdr 1 （支援） 目標是否支援高動態範圍 （HDR） 轉譯 是
4 輸出保護 hdcp 0 （關閉），1 （開啟且不含 HDCP 2.2 類型 1 限制），2 （開啟且含有 HDCP 2.2 類型 1 限制） 所有已啟用互相交錯的顯示器是否至少支援請求保護層級？ 是
5 一般：效率** 效率設定 0 （關閉 = 沒有限制），1 （on = 在電池電源時限制解析度） 使用者是否想要使用電池使用時間、串流額外負荷和/或下載速度，而偏好使用最高解析度？**** 是
6a 解密 加密類型 “cenc” 或 “cbcs”，具有選擇性的 “-clearlead” 後綴。 此加密類型是否支援使用指定的編解碼器/金鑰系統進行解密？ 如果未指定 value，則會使用預設值 「cenc」。 從 Windows 11 組建 22621 和 Windows 10 組建 19045.5796 或更新版本開始，支持後綴 “-clearlead”。 當 「-clearlead」 附加至加密類型值時，也會要求在加密內容開頭使用清除內容的支援。 在內容開頭清除內容可加快呈現第一個畫面的時間。 如果 「-clearlead」 新增至加密類型，則會檢查所要求編解碼器的版本號碼。 AV1 和 VP9 編解碼器將會檢查主要版本 2，且 HEVC 將會檢查 v2.0.53421 或更高版本。 N
6b 解密 encryption-iv-size 8 或 16 這個初始化向量 （IV） 大小 （以位元組為單位） 是否支援使用指定的編解碼器/金鑰系統進行解密？ 如果未指定 value，則會使用預設值 8。 N

* 僅支援 Windows 10 版本 1607 和更新版本的 OS 版本

** 僅支援 Windows 10 版本 1709 和更新版本的 OS 版本

*** 交集演算法為：

  1. 尋找所有具有應用程式使用者介面視訊客戶端區域像素的顯示器。
  2. 尋找從步驟 1 驅動顯示器的所有圖形適配卡。 針對硬體DRM查詢，此組適配卡只會篩選為具有硬體DRM支援的適配卡。
  3. 找出所有連接到步驟 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 安全性處理器的輸送量功能所管制。 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

另請參閱

MF_MEDIA_ENGINE_CANPLAY