ProtectionCapabilities.IsTypeSupported(String, String) Méthode

Référence

Définition

Espace de noms:: Windows.Media.Protection

Important

Certaines informations portent sur la préversion du produit qui est susceptible d’être en grande partie modifiée avant sa publication. Microsoft exclut toute garantie, expresse ou implicite, concernant les informations fournies ici.

Modifier

Interroge les fonctionnalités de décodage vidéo, d’affichage et de protection de la sortie pour les fonctionnalités DRM.

Avertissement

Il est recommandé d’utiliser cette méthode uniquement avec Windows 10, la version 1607 ou la version plus récente du système d’exploitation, même si elle est présente sur les versions antérieures de 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

Paramètres

type: String
Platform::String

winrt::hstring

Chaîne identifiant les fonctionnalités pour lesquelles la prise en charge est interrogée. Ce paramètre accepte les chaînes de type de contenu RFC 2045 pour spécifier les identificateurs de type de média et de sous-type, ainsi que 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 HTML5 HTMLMediaElementcanPlayType . RFC 2045 autorise des paramètres personnalisés supplémentaires en tant que modificateurs sous la forme de ";<parameter>=<name>[=<value>] [,<name>[=<value>]". Les analyseurs compatibles RFC 2045 doivent ignorer ces paramètres s’ils ne sont pas reconnus. Pour les requêtes de fonctionnalité, <parameter> est nommé fonctionnalité.

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

Notez que les termes type et type de contenu sont historiquement connus sous le nom de type MIME.

keySystem: String
Platform::String

winrt::hstring

Chaîne identifiant l’espace de noms PlayReady sur lequel case activée requête, 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.recommendation » pour les requêtes générales (doit répondre à la prise en charge de la protection logicielle pour garantir la compatibilité descendante).

Retours

ProtectionCapabilityResult

Valeur indiquant si les fonctionnalités interrogées sont probablement prises en charge, sont éventuellement prises en charge ou ne sont pas prises en charge.

Remarques

Le paramètre d’entrée de type doit avoir des identificateurs de sous-type de média et de sous-type RFC 6381 Content-Type. La chaîne de paramètre codecs RFC 2045 doit également être 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 qui fournissent 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 qui fournissent 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 la 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 de points-virgules. 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 conditions suivantes s’appliquent :

Une seule requête de noms de caractéristiques plus des 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 la présence d’une requête de sous-système Décodage
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 Subsystem) peut être effectuée avec ou sans une requête de sous-système Decode, Display 1 ou Display 2, sous réserve des contraintes 3 et #4.

La General: Efficiency requête peut être combinée avec n’importe quelle autre requête de sous-système.

Le résultat retourné est le AND logique de toutes les requêtes de fonctionnalités individuelles, avec la précision suivante : un résultat Peut-être est autorisé uniquement à partir du sous-système de protection de sortie, et uniquement temporairement. Ce peut être prioritaire par rapport à un résultat probable de l’ET de toutes les autres requêtes de fonctionnalités, jusqu’à ce que peut être résolu au fil du temps en probablement ou non pris en charge. La limite de temps actuelle pour la résolution de Peut-être 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é	Description	Obligatoire pour ce sous-système
1a	Décodage	décodage-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écodage	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écodage	débit de décodage	Nombre positif en kilobits par seconde (Kbit/s)	Le décodeur vidéo prend-il en charge ce débit maximal ?	O
1d	Décodage	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écodage	decode-bpc (decode-bpp est déconseillé)	0, 8, 10 ou 12	Le décodeur vidéo peut-il consommer cette profondeur de couleur par pixel ?	O
1f	Décodage	décodeur-accélération matérielle^**	1 ou aucune valeur comme true	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écodage	décodeur-software-acceleration ^**	1 ou aucune valeur comme true	Un décodeur de système d’exploitation présent est-il capable de décoder le flux ?	N
1h	Décodage	decoder-software-requires-hardware^**	1 ou aucune valeur comme true	Les fonctionnalités du décodeur de système d’exploitation nécessitent-elles la présence d’une accélération matérielle DXVA ?	N
2a	Afficher 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	Afficher 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 qu’il est compris par Windows) pour au moins la fréquence d’actualisation demandée ?	N
2d	Affichage 1	display-bpc (display-bpp est déconseillé)	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 HDR (High Dynamic Range)	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 activés entre les intersections 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 = limite de résolution lorsque la batterie est alimentée)	L’utilisateur souhaite-t-il une autonomie de la batterie, une surcharge de streaming et/ou une vitesse de téléchargement de préférence pour la résolution la plus élevée ?^****	O
6a	Déchiffrement	encryption-type	« cenc » ou « cbcs »	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 « cenc » est utilisée.	N
6b	Déchiffrement	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/système de clés spécifié ? Si la valeur n’est pas spécifiée, la valeur par défaut 8 est utilisée.	N

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

^**Pris en charge uniquement 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 toutes les cartes graphiques qui pilotent les affichages de l’étape 1. Pour une requête DRM matérielle, cet ensemble d’adaptateurs est filtré uniquement pour les adaptateurs ayant une prise en charge de la gestion des droits numériques (DRM) matériel.
Recherchez tous les affichages connectés aux cartes graphiques à partir de l’étape 2.

^**** Il appartient au fournisseur de contenu de choisir la limite de résolution à utiliser lorsque cette stratégie est activée. Une limite de 1 080p est recommandée, mais 720p peut être utilisé. Notez que l’entrée pour cette stratégie provient de la page d’interface utilisateur 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 >= jeu d’intersections réel maximum x) AND (demandé y >= jeu d’intersection réel maximum y), avec une modification indiquant que l’affichage portrait est normalisé en paysage en permutant x et y si nécessaire.

La requête hdcp (élément 4) a un coût de premier appel coûteux en calcul. HDCP doit être activé au niveau demandé pour déterminer si le niveau demandé peut être satisfait avec la topologie d’affichage active. Le résultat Peut-être dû au fait que HDCP est évalué de manière asynchrone et prend jusqu’à 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 soit finalisé comme probablement ou non pris en charge. La modification du niveau HDCP demandé dans une requête alors qu’elle est toujours à l’état Peut-être entraîne probablement une réponse non valide. Le délai d’expiration De peut-être est 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 la topologie d’affichage lors de l’interrogation invalide la mise en cache.

En tant que détail d’implémentation, les cartes 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. L’engagement de HDCP 2.2 peut prendre beaucoup plus de temps que HDCP 1.x. Les observations sur les téléviseurs de génération actuelle affichent des durées allant 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 un changement de topologie de sortie nécessite d’attendre jusqu’à 8 secondes plus la marge pour ce pire cas. En utilisant 10 secondes comme attente maximale, il est recommandé d’exécuter la requête de démarrage de l’application lorsque l’utilisateur est le moins supposé 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 seront en moins de seconde. Si le contenu a la même exigence de sortie HDCP que la requête , la mise en cache eljminate l’attente de plusieurs secondes qui se produit à nouveau au démarrage de la lecture.

Lors d’un changement de 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, du niveau de protection de la sortie entraîne généralement l’échec de la lecture active avec drm matériel par conception. Ici, une réaction à une erreur de MF_POLICY_UNSUPPORTED (0xC00D7159) doit être de masquer l’erreur à l’utilisateur, de faire une nouvelle requête et de reprendre avec une version de contenu appropriée pour toutes les fonctionnalités modifiées. En effet, 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 DirectX Video Acceleration (DXVA). Toutefois, H.264 DXVA est très commun sur tous les points de terminaison Windows.

Une limitation fonctionnelle avec les requêtes de décodage DRM logicielles est que le decode-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 réussit.

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

Exemples de requêtes DRM matérielles

Voici l’utilisation la plus courante pour le contenu HEVC Standard Dynamic Range (SDR) 4K 10 bits avec la restriction 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é par mp3, 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 les valeurs et display-res-y peuvent être inférieures à 4 Ko complètes si le fournisseur souhaite envoyer (push) des flux 4K à 3200 x 1800, 3 000 x 2000 ou 2560 x 1440 affichages, par exemple.

Étant donné que les résultats de la requête de décodage ne sont pas censés changer dynamiquement, les interrogations successives pendant hdcp=2 que dans Peut-être peuvent 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 risque de perturber l’établissement du HDCP en cours.

L’exemple suivant montre l’utilisation la plus courante du contenu 4K 10 bits HEVC High Dynamic Range (HDR) avec drm matériel et la restriction HDCP 2.2 Type 1 :

Remarque : Pour Windows 10, version 1607, hdr=1 indique que la prise en charge de 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.

Voici l’utilisation la plus courante du contenu SDR H.264 8 bits 1080p avec drm matériel et HDCP sans restriction de type 1 2.2 :

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

S’applique à

Voir aussi

ProtectionCapabilityResult

Partager via