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

Requêtes des fonctionnalités de décodage vidéo, d’affichage et de sous-systèmes de protection de sortie pour les fonctionnalités DRM.

Avertissement

Il est recommandé d’utiliser cette méthode uniquement avec Windows 10, version 1607 ou 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 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 HTML5 HTMLMediaElementcanPlayType. RFC 2045 permet d’ajouter des paramètres personnalisés en tant que modificateurs sous la forme de ";<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, <parameter> 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 le paramètre de codec RFC 6381 codec=”<video codec>[,<audio codec>]” toujours 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.

keySystem: String
Platform::String

winrt::hstring

Chaîne identifiant l’espace de noms PlayReady pour vérifier la requête, 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).

Retours

ProtectionCapabilityResult

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

Remarques

Le type paramètre d’entrée 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 requête General: Efficiency 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 Peut-être résultat n’est autorisé qu’à partir du sous-système de protection de sortie, et uniquement temporairement. Cette Peut-être est prioritaire sur un probablement résultat de l’AND de toutes les autres requêtes de fonctionnalités, jusqu’à ce que le Peut-être se résout au fil du temps pour probablement ou non pris en charge. La limite de temps actuelle pour Peut-être à résoudre 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 :

Article	Sous-système vidéo	Nom de la fonctionnalité	Valeur de la fonctionnalité	Description	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 ?	Y
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 ?	Y
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 binaire maximal ?	Y
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) ?	Y
1e	Décoder	decode-bpc (décodage-bpp est déconseillé)	0, 8, 10 ou 12	Le décodeur vidéo peut-il consommer cette profondeur de couleur par pixel ?	Y
1f	Décoder	decoder-hardware-acceleration^**	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écoder	decoder-software-acceleration ^**	1 ou aucune valeur comme true	Un décodeur de système d’exploitation est-il capable de décoder le flux ?	N
1h	Décoder	decoder-software-requires-hardware^**	1 ou aucune valeur comme true	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^** croisé prend-il en charge cette résolution dans l’axe X ?	Y
2b	Affichage 1	display-res-y	Nombre non négatif en pixels	L’affichage d’au moins un^*** croisé prend-il en charge cette résolution dans l’axe Y ?	Y
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 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	Afficher 2^*	Hdr	1 (pris en charge)	La cible prend-elle en charge le rendu HDR (High Dynamic Range)	Y
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 ?	Y
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 ?^****	Y
6a	Décryptage	type de chiffrement	« 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 de « cenc » est utilisée.	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érielle, cet ensemble d’adaptateurs est filtré uniquement sur ces adaptateurs disposant d’une prise en charge drm matérielle.
Recherchez tous les affichages connectés à la ou les cartes graphiques 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 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 (x >demandé = nombre maximal d’intersections réelles x) AND (demandé y >= nombre réel d’intersections maximale y), avec une modification 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 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 Peut-être résultat en raison de l’évaluation asynchrone du HDCP et de prendre jusqu’à plusieurs secondes avec HDCP 2.2, mais la requête étant synchrone avec un blocage minimal, exige 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 Peut-être délai d’expiration 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 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 requête hdcp=1 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 de 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 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é 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 et les valeurs de display-res-y peuvent être définies inférieures à 4 Ko complètes si le fournisseur souhaite envoyer (push) des flux 4K à 3200 x 1800, 3000 x 2000 ou 2560 x 1440 affiche, par exemple.

Comme les résultats de la requête décodage ne sont pas censés changer dynamiquement, l’interrogation successive pour hdcp=2 tandis que dans Peut-être peut-être 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 10 bits du MPO 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 uniquement de développement est présente et a été définie : HKLM\SOFTWARE\Microsoft\Windows\DWM key HighColor comme 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”’);

S’applique à

Voir aussi

ProtectionCapabilityResult

Partager via