Partager via

Méthode IMFExtendedDRMTypeSupport ::IsTypeSupportedEx (mfmediaengine.h)

  • Article

Demande 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 Content-Type 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 HTMLMediaElement canPlayType. RFC 2045 autorise des paramètres personnalisés supplémentaires en tant que modificateurs sous la forme « ;<parameter>=<name>[=<value>] [,<name>[=<value>] ». Les analyseurs conformes À la RFC 2045 doivent ignorer ces paramètres s’ils ne sont pas reconnus. Pour les requêtes de fonctionnalité, est nommé fonctionnalité.

L’implémentation nécessite que le type de média et les identificateurs de sous-type RFC 2045, par exemple « video/mp4 », et le paramètre de codec RFC 6381 codec="<codec> vidéo[,<codec> audio] » 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.

[in] keySystem

BSTR identifiant l’espace de noms PlayReady à case activée interroger, 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 du 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).

[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 ne sont pas prises en charge.

Valeur retournée

S_OK sur le succès.

Remarques

Le paramètre d’entrée de type doit avoir des identificateurs de média et de sous-type de contenu RFC 6381. 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 point-virgule. Le pilote graphique et le matériel sous-jacents 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 caractéristiques 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 la présence d’une requête de sous-système Decode
  4. Une requête de sous-système Display 2 nécessite une requête de sous-système Decode, mais ne nécessite pas de requête de sous-système Display 1.
  5. 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 d’autres requêtes de sous-système.

Le résultat retourné est le AND logique de toutes les requêtes de fonctionnalité individuelles, avec la précision suivante : Un résultat Peut-être est autorisé uniquement à partir du sous-système de protection de sortie, et seulement temporairement. Ceci est peut-être prioritaire sur un résultat probable de l’AND de toutes les autres requêtes de fonctionnalité, jusqu’à ce que peut être résolu au fil du temps en 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 :

Élément Sous-système vidéo Nom de la fonctionnalité Valeur de fonctionnalité Description Obligatoire pour ce sous-système
1a Décodage decode-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 decode-res-y Nombre non négatif en pixels Le décodeur vidéo prend-il en charge cette résolution maximale sur l’axe Y ? O
1c Décodage decode-bitrate Nombre positif en kilobits par seconde (Kbits/s) Le décodeur vidéo prend-il en charge cette vitesse de transmission maximale ? O
1d Décodage decode-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 de système d’exploitation présent ? N
1g Décodage 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é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 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 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 », avec le suffixe « -clearlead » facultatif. 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. À compter de Windows Build 22621, 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 en clair au tout 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 principale 2, et HEVC sera vérifié pour la version 2.0.53421 ou ultérieure. 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 :

  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 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.
  3. 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 pour le contenu 4K 10 bits HEVC High Dynamic Range (HDR) avec drm matériel et la restriction 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,hdr=1,hdcp=2”’);

Remarque : Pour Windows 10, la 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 1.

L’exemple suivant montre 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”’);

Configuration requise

   
En-tête mfmediaengine.h

Voir aussi

MF_MEDIA_ENGINE_CANPLAY