ProtectionCapabilities.IsTypeSupported(String, String) Méthode

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

Retours

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 :

1. 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
2. Une requête de sous-système de décodage peut être effectuée sans requête Display 1, Display 2 ou Output Protection
3. 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
4. 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.
5. 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 :

^* 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 :

1. Recherchez tous les affichages où la région du client vidéo de l’interface utilisateur de l’application comporte des pixels.
2. 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.
3. 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 :

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

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