IMFExtendedDRMTypeSupport：：IsTypeSupportedEx 方法 (mfmediaengine.h)
查询指定的密钥系统是否支持指定的内容类型。
语法
HRESULT IsTypeSupportedEx(
[in] BSTR type,
[in] BSTR keySystem,
[out] MF_MEDIA_ENGINE_CANPLAY *pAnswer
);
参数
[in] type
一个 BSTR ，标识要查询其支持的功能。 此参数接受 RFC 2045 Content-Type 字符串以指定媒体类型和子类型标识符，并接受 RFC 6381 编解码器标识符作为所需编解码器。 这些基字符串与 HTML5 HTMLMediaElement canPlayType 方法中使用的字符串一致。 RFC 2045 允许附加的自定义参数作为“;<parameter>=<name>[=<value>] [，<name>[=<value>]”。 RFC 2045 兼容分析程序必须忽略这些参数（如果未识别）。 对于功能查询， 是命名功能。
实现要求始终存在 RFC 2045 媒体类型和子类型标识符，例如“video/mp4”和 RFC 6381 编解码器参数 codec=“<video codec>[，<audio 编解码器>]”，以提供有效的查询结果。
请注意，术语内容类型和类型在历史上是众所周知的 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 Content-Type 媒体类型和子类型标识符。 它还必须具有 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 子系统查询。
- 可以使用或不使用解码、显示 1 或显示 2 子系统查询来执行 (HDCP) 查询的输出保护子系统，但受约束 #3 和 #4 的限制。
该 General: Efficiency 查询可以与任何其他子系统查询组合使用。
返回的结果是所有单个功能查询的逻辑 AND，并进行了以下说明：A 可能 结果仅允许来自输出保护子系统，并且仅允许暂时执行。 此 可能 优先于所有其他功能查询的 AND 的 可能 结果，直到 可能 随时间推移解析为 “可能 ”或 “不支持”。 可能解析的当前时间限制为 10 秒。
下表列出了支持的单个功能查询，按视频子系统进行组织：
| 项 | 视频子系统 | 功能名称 | 功能值 | 说明 | 此子系统是必需的 |
|---|---|---|---|---|---|
| 1a | 解码 | decode-res-x | 非负数（以像素为单位） | 视频解码器是否支持 X 轴中的此最大分辨率？ | Y |
| 1b | 解码 | decode-res-y | 非负数（以像素为单位） | 视频解码器是否在 Y 轴中支持此最大分辨率？ | Y |
| 1c | 解码 | decode-bitrate | 正数（以千比特/秒为单位 (Kbps) | 视频解码器是否支持此最大比特率？ | Y |
| 1 天 | 解码 | 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 | 无论是否存在 OS 解码器，DXVA 硬件加速是否可用？ | N |
| 1g | 解码 | decoder-software-acceleration ** | 1 或没有值为 true | OS 解码器是否能够解码流？ | N |
| 1h | 解码 | 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 |
| 2D | 显示 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 限制 | 是否所有已启用相交的显示器至少支持请求保护级别？ | Y |
| 5 | 常规：效率** | 效率设置 | 0 (off = 无限制) ,1 (on = 限制分辨率（当使用电池电源时) | 用户是否希望电池使用时间、流式传输开销和/或下载速度优先于最高分辨率？**** | Y |
| 6a | 解密 | encryption-type | “cenc”或“cbcs”，具有可选的“-clearlead”后缀。 | 使用指定的编解码器/密钥系统进行解密是否支持此加密类型？ 如果未指定值，则使用默认值“cenc”。 从 Windows 内部版本 22621 开始，支持后缀“-clearlead”。 将“-clearlead”追加到加密类型值后，还请求支持在加密内容的开头使用清除内容。 在内容开头清除内容可加快呈现第一帧的时间。 如果将“-clearlead”添加到加密类型，则将检查所请求编解码器的版本号。 AV1 和 VP9 编解码器将检查主要版本 2，HEVC 将检查 v2.0.53421 或更高版本。 | N |
| 6b | 解密 | encryption-iv-size | 8 或 16 | 此初始化向量 (IV) 大小 (字节) 是否支持使用指定的编解码器/密钥系统进行解密？ 如果未指定值，则使用默认值 8。 | N |
*仅在 Windows 10 版本 1607 和更新的 OS 版本上受支持
**仅在 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，图形适配器可以选择使用 HDCP 2.2，即使尚未设置 HDCP 2.2 类型 1 限制。 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 卸载。 但是，H.264 DXVA 在所有 Windows 终结点中非常常见。
软件 DRM 解码查询的一个功能限制是未评估解码 bpc。 Windows 不支持 H.264 10 位解码，但 具有 decode-bpc=10 的查询将成功。
特征查询结果反映了子系统的最大理论功能。 GPU 中的其他活动或不同的电源状态可能会降低实际功能。
硬件 DRM 查询示例
下面显示了硬件 DRM 和 HDCP 2.2 类型 1 限制的 4K 10 位 HEVC 标准动态范围 (SDR) 内容的最常见用法：
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 建立。
下面显示了硬件 DRM 和 HDCP 2.2 类型 1 限制的 4K 10 位 HEVC 高动态范围 (HDR) 内容的最常见用法：
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。
下面显示了没有 2.2 类型 1 限制的硬件 DRM 和 HDCP 的 1080p 8 位 H.264 SDR 内容的最常见用法：
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 |