IMFExtendedDRMTypeSupport ::IsTypeSupportedEx, méthode (mfmediaengine.h)

2025-05-21

Interroge si le type de contenu spécifié est pris en charge pour le système de clés spécifié.

Syntaxe

HRESULT IsTypeSupportedEx(
  [in]  BSTR                    type,
  [in]  BSTR                    keySystem,
  [out] MF_MEDIA_ENGINE_CANPLAY *pAnswer
);

Paramètres

[in] type

BSTR identifiant les fonctionnalités pour lesquelles la prise en charge est interrogée. Ce paramètre accepte les chaînes RFC 2045 Content-Type pour spécifier les identificateurs de type de média et de sous-type, et les identificateurs de codecs RFC 6381 pour les codecs requis. Ces chaînes de base sont cohérentes avec celles utilisées dans la méthode HTMLMediaElement canPlayType HTML5. RFC 2045 permet des paramètres supplémentaires personnalisés en tant que modificateurs sous la forme « ;<parameter>=<name>[=<value>] [,<name>[=<value>]". Les analyseurs conformes RFC 2045 doivent ignorer ces paramètres s’ils ne sont pas reconnus. Pour les requêtes de fonctionnalités, <le paramètre> est nommé fonctionnalité.

L’implémentation nécessite le type de média RFC 2045 et les identificateurs de sous-type, par exemple « video/mp4 » et RFC 6381 codec codec codec="<video codec>[,<codec> audio] » pour toujours être présents afin de fournir des résultats de requête valides.

Notez que le type de contenu et le type de termes sont bien connus historiquement comme type MIME.

[in] keySystem

BSTR identifiant l’espace de noms PlayReady pour vérifier la requête sur, en spécifiant la protection matérielle ou logicielle. Utilisez « com.microsoft.playready.recommendation.3000 » pour les requêtes matérielles (PlayReady doit prendre en charge le déchargement matériel), « com.microsoft.playready.recommendation.2000 » pour interroger explicitement la prise en charge de la protection logicielle et « com.microsoft.playready.recommandation » pour les requêtes générales (doit répondre à la prise en charge de la protection logicielle pour garantir la compatibilité descendante).

[out] pAnswer

Valeur de l’énumération MF_MEDIA_ENGINE_CANPLAY indiquant si les fonctionnalités interrogées sont probablement prises en charge, sont éventuellement prises en charge ou non prises en charge.

Valeur retournée

S_OK sur le succès.

Remarques

Le paramètre d’entrée de type doit avoir le type de média RFC 6381 Content-Type et les identificateurs de sous-type présents. Il doit également avoir la chaîne de paramètre Codecs RFC 2045 présente. MPEG-4 est le seul conteneur pris en charge pour cette API. H.264 (avc1) et HEVC (hvc1, hev1) sont les seuls codecs vidéo fournissant des réponses prises en charge. MPEG-4 (mp4a), MPEG-1 Layer 3 (mp3), Dolby Digital (ac-3) et Dolby Digital Plus (ec-3) sont les seuls codecs audio fournissant des réponses prises en charge. Les chaînes prises en charge sont les suivantes :

video/mp4;codecs=”avc1,<audio codec>”

video/mp4;codecs=”hvc1, <audio codec>”

video/mp4;codecs=”hev1, <audio codec>”

À compter de Windows 10 version 1709, les éléments suivants sont également pris en charge :

Video/mp4;codecs=”vp9,<audio codec>”

Video/mp4;codecs=”vp09,<audio codec>”

La partie caractéristiques de la chaîne de requête est ajoutée à l’une des chaînes ci-dessus à l’aide d’un délimiteur point-virgule. Le pilote graphique sous-jacent et le matériel imposent des contraintes sur la façon dont les fonctionnalités peuvent être interrogées. Pour les sous-systèmes vidéo, les exigences suivantes s’appliquent :

Une seule requête de noms de fonctionnalités et de valeurs peut être utilisée à partir de chacun des sous-systèmes dans un seul appel
Une requête de sous-système de décodage peut être effectuée sans requête Display 1, Display 2 ou Output Protection
Une requête de sous-système Display 1 nécessite qu’une requête de sous-système de décodage soit présente
Une requête de sous-système Display 2 nécessite une requête de sous-système de décodage, mais ne nécessite pas de requête de sous-système Display 1.
Une requête HDCP (Output Protection Sous-système) peut être effectuée avec ou sans décodage, affichage 1 ou requête de sous-système Display 2, sous réserve de contraintes #3 et #4.

La General: Efficiency requête peut être combinée à d’autres requêtes de sous-système.

Le résultat retourné est l’AND logique de toutes les requêtes de fonctionnalités individuelles, avec la clarification suivante : Un résultat peut-être est autorisé uniquement à partir du sous-système de protection de sortie, et uniquement temporairement. Cela est peut-être prioritaire par rapport à un résultat probable de l’AND de toutes les autres requêtes de fonctionnalités, jusqu’à ce que la solution peut être résolue au fil du temps pour probablement ounon prise en charge. La limite de temps actuelle pour peut-être être résolue est de 10 secondes.

Le tableau suivant répertorie les requêtes de fonctionnalités individuelles prises en charge, organisées par sous-système vidéo :

Élément	Sous-système vidéo	Nom de la fonctionnalité	Valeur de la fonctionnalité	Descriptif	Obligatoire pour ce sous-système
1a	Décoder	décoder-res-x	Nombre non négatif en pixels	Le décodeur vidéo prend-il en charge cette résolution maximale dans l’axe X ?	O
1b	Décoder	décodage-res-y	Nombre non négatif en pixels	Le décodeur vidéo prend-il en charge cette résolution maximale dans l’axe Y ?	O
1c	Décoder	decode-bitrate	Nombre positif en kilobits par seconde (Kbits/s)	Le décodeur vidéo prend-il en charge ce débit maximal?	O
1d	Décoder	décodage fps	24, 25, 29,97, 30, 50, 59,94 ou 60	La vidéo décodée prend-elle en charge cette valeur maximale d’images par seconde (FPS) ?	O
1e	Décoder	decode-bpc (decode-bpp est obsolète)	0, 8, 10 ou 12	Le décodeur vidéo peut-il consommer cette profondeur de couleur par pixel ?	O
1f	Décoder	decoder-hardware-acceleration^**	1 ou aucune valeur comme vrai	L’accélération matérielle DXVA est-elle disponible quel que soit le décodeur du système d’exploitation présent ?	N
1g	Décoder	decoder-software-acceleration ^**	1 ou aucune valeur comme vrai	Un décodeur de système d’exploitation est-il capable de décoder le flux ?	N
1 h	Décoder	decoder-software-requires-hardware^**	1 ou aucune valeur comme vrai	La fonctionnalité du décodeur du système d’exploitation nécessite-t-elle que l’accélération matérielle DXVA soit présente ?	N
2a	Affichage 1	display-res-x	Nombre non négatif en pixels	Au moins un affichage croisé^** prend-il en charge cette résolution dans l’axe X ?	O
2b	Affichage 1	display-res-y	Nombre non négatif en pixels	Au moins un affichage croisé^*** prend-il en charge cette résolution dans l’axe Y ?	O
2c	Affichage 1	display-refreshrate	24, 25, 29,97, 30, 50, 59,94 ou 60	L’affichage est-il configuré (tel que compris par Windows) pour au moins le taux d’actualisation demandé ?	N
2d	Affichage 1	display-bpc (display-bpp est obsolète)	8 ou 10	Tous les affichages croisés avec ≥ résolution requise réalisent-ils au moins cette profondeur de couleur ?	N
3	Affichage 2^*	HDR	1 (pris en charge)	La cible prend-elle en charge le rendu à plage dynamique élevée (HDR)	O
4	Protection de sortie	hdcp	0 (désactivé), 1 (activé sans restriction HDCP 2.2 Type 1), 2 (activé avec la restriction HDCP 2.2 Type 1	Tous les affichages croisés activés prennent-ils en charge au moins le niveau de protection des demandes ?	O
5	Général : Efficacité^**	paramètre d’efficacité	0 (désactivé = aucune restriction), 1 (on = résolution limite quand la batterie est activée)	L’utilisateur souhaite-t-il une durée de vie de batterie, une surcharge de diffusion en continu et/ou une vitesse de téléchargement en préférence pour la résolution la plus élevée ?^****	O
6a	Décryptage	type de chiffrement	« cenc » ou « cbcs », avec suffixe facultatif « -clearlead ».	Ce type de chiffrement est-il pris en charge pour le déchiffrement avec le codec /key-system spécifié ? Si la valeur n’est pas spécifiée, la valeur par défaut de « cenc » est utilisée. À compter de Windows 11 Build 22621 et Windows 10 Build 19045.5796 ou version ultérieure, le suffixe « -clearlead » est pris en charge. Lorsque « clearlead » est ajouté à la valeur de type de chiffrement, la prise en charge de l’utilisation du contenu clair au début du contenu chiffré est également demandée. Effacer le contenu au début du contenu accélère la présentation de la première image. Si « -clearlead » est ajouté au type de chiffrement, le numéro de version du codec demandé est vérifié. Les codecs AV1 et VP9 seront vérifiés pour la version majeure 2, et HEVC sera vérifié pour v2.0.53421 ou version ultérieure.	N
6b	Décryptage	encryption-iv-size	8 ou 16	Cette taille de vecteur d’initialisation (IV) (en octets) est-elle prise en charge pour le déchiffrement avec le codec /key-system spécifié ? Si la valeur n’est pas spécifiée, la valeur par défaut 8 est utilisée.	N

^* Uniquement pris en charge sur Windows 10, version 1607 et versions ultérieures du système d’exploitation

^** Uniquement pris en charge sur Windows 10, version 1709 et versions ultérieures du système d’exploitation

^*** L’algorithme d’intersection est :

Recherchez tous les affichages où la région du client vidéo de l’interface utilisateur de l’application comporte des pixels.
Recherchez tous les adaptateurs graphiques qui pilotent les affichages à l’étape 1. Pour une requête DRM matériel, cet ensemble d'adaptateurs est filtré pour ne retenir que les adaptateurs ayant une prise en charge DRM matériel.
Recherchez tous les écrans connectés à la (aux) carte(s) graphique(s) de l'étape 2.

^**** Il incombe au fournisseur de contenu de choisir la limite de résolution à utiliser lorsque cette stratégie est activée. Une limite de 1080p est recommandée, mais 720p peut être utilisée. Notez que l’entrée de cette politique provient de la page de l’interface utilisateur des paramètres vidéo ajoutée dans Windows 10, version 1709.

Les paires pour les éléments 1a et 1b et 2a et 2b sont chacune calculées en tant que (demandé x >= nombre maximal d’intersections réelles x) AND (demandé y >= nombre réel d’ensembles y), avec une modification que l’affichage portrait est normalisé au paysage en permutant x et y selon les besoins.

La requête hdcp (élément 4) a un coût d’appel coûteux de calcul pour la première fois. HDCP doit être activé au niveau demandé pour déterminer si le niveau demandé peut être respecté avec la topologie d’affichage active. Le résultat peut être dû à l’évaluation asynchrone de HDCP et à plusieurs secondes avec HDCP 2.2, mais la requête étant synchrone avec un blocage minimal, nécessite que l’appelant utilise la requête à plusieurs reprises jusqu’à ce que le résultat se termine comme probablement ou non pris en charge. La modification du niveau HDCP demandé dans une requête tout en restant dans l’état Peut-être entraînera probablement une réponse non valide. Le délai d’expiration peut être d’environ 10 secondes.

Il est fortement recommandé de ne pas appeler une requête hdcp plus souvent qu’une fois toutes les 250 millisecondes, en raison du coût de calcul sous-jacent. 500 millisecondes est le minimum préféré. La mise en cache est effectuée pour réduire ce coût, mais toute modification de topologie d’affichage lors de l’interrogation invalide la mise en cache.

Comme détail d’implémentation, les adaptateurs graphiques peuvent choisir d’utiliser HDCP 2.2 si tous les nœuds le prennent en charge, même si la restriction HDCP 2.2 Type 1 n’a pas été définie. HDCP 2.2 peut prendre beaucoup plus de temps que HDCP 1.x pour s’engager. Les observations sur les téléviseurs de génération actuelle affichent jusqu’à 8 secondes, contre environ 1 seconde pour les appareils HDCP 1.x, y compris les répéteurs. Par conséquent, une première hdcp=1 requête au démarrage de l’application ou après une modification de topologie de sortie nécessite d’attendre jusqu’à 8 secondes plus de marge pour ce pire cas. En utilisant 10 secondes comme attente maximale, il est recommandé d’effectuer la requête de démarrage de l’application lorsque l’utilisateur est le moins censé choisir un titre, par exemple sur une interface utilisateur initiale. Si aucune modification de topologie ne se produit, toutes les requêtes hdcp supplémentaires sont inférieures à la seconde. Si le contenu a la même exigence de sortie HDCP que la requête, la mise en cache eljmine l’attente à plusieurs secondes se produisant à nouveau au démarrage de la lecture.

Sur une topologie de sortie, les téléviseurs et les moniteurs haute résolution prennent souvent plusieurs secondes pour stabiliser le bureau. Une modification, et en particulier une réduction, au niveau de protection des sorties entraîne généralement l’échec de la lecture active avec la gestion des droits numériques matériels par défaut. Ici, une réaction à une erreur MF_POLICY_UNSUPPORTED (0xC00D7159 ) doit être de masquer l’erreur de l’utilisateur, de requery et de reprendre avec une version de contenu appropriée pour toutes les fonctionnalités modifiées. En fait, cela agit comme une extension du temps de stabilisation « hotplug ».

Les requêtes de fonctionnalités de décodage drm logicielles sont potentiellement ambiguës sur les performances, car l’implémentation H.264 permet le décodage logiciel ou le déchargement gpu DXVA (DirectX Video Acceleration). Toutefois, H.264 DXVA est très courant sur tous les points de terminaison Windows.

Une limitation fonctionnelle avec les requêtes de décodage DRM logicielles est que le décodage-bpc n’est pas évalué. Windows ne prend pas en charge le décodage H.264 10 bits, mais une requête avec decode-bpc=10 elle réussit.

Le résultat de la requête de fonctionnalité reflète les capacités théoriques maximales des sous-systèmes. D’autres activités dans le GPU ou différents états d’alimentation peuvent réduire la capacité réelle.

Exemples de requêtes DRM matérielles

Les éléments suivants illustrent l’utilisation la plus courante pour le contenu de plage dynamique standard HEVC 4K 10 bits avec la restriction DE DRM matérielle et HDCP 2.2 Type 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”’);

Où mp4a peut être remplacé mp3par , ac-3ou ec-3. Le débit de décodage peut être ajusté en fonction de l’encodage du fournisseur de contenu. decode-fps peut être défini sur 60 au lieu de 30, mais peut être contrôlé par la capacité de débit du processeur de sécurité DRM matériel. display-res-x et les display-res-y valeurs peuvent être définies à une valeur inférieure à 4 000 si le fournisseur souhaite envoyer (push) des flux 4K à 3200 x 1800, 3000 x 2000 ou 2560 x 1440 s’affiche, par exemple.

Comme les résultats de la requête de décodage ne sont pas censés changer dynamiquement, l’interrogation successive pendant hdcp=2 que dans Peut-être peut utiliser un formulaire plus court comme une petite optimisation

IsTypeSupported(‘com.microsoft.playready.recommendation.3000’,’video/mp4;codecs=”hvc1,mp4a”;features=”hdcp=2”’);

Bien sûr, cette optimisation n’intercepte pas un changement de résolution de moniteur dynamique, mais une telle modification perturberait probablement l’établissement HDCP en cours de toute façon.

Les éléments suivants illustrent l’utilisation la plus courante pour le contenu HAUTE plage dynamique HEVC (HDR) 4K 10 bits avec la restriction de type 2.2 de type 2 et HDCP 2.2 matérielle :

Remarque : Pour Windows 10, version 1607, hdr=1 indique que la prise en charge du protocole MPO 10 bits avec DXGI_COLOR_SPACE_YCBCR_FULL_G22_LEFT_P2020 ou DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 ou DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020 est présente, ou que la clé de Registre HighColor de développement uniquement est présente et a été définie comme HKLM\SOFTWARE\Microsoft\Windows\DWM key HighColor valeur DWORD de 1.

L’utilisation la plus courante pour le contenu SDR H.264 H.264 8 bits avec drm matériel et HDCP sans restriction 2.2 Type 1 est la suivante :

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”’);

Spécifications

Besoin	Valeur
En-tête	mfmediaengine.h

Voir aussi

MF_MEDIA_ENGINE_CANPLAY