IMFExtendedDRMTypeSupport::IsTypeSupportedEx-Methode (mfmediaengine.h)

2025-05-21

Fragt ab, ob der angegebene Inhaltstyp für das angegebene Schlüsselsystem unterstützt wird.

Syntax

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

Die Parameter

[in] type

Ein BSTR , der die Features identifiziert, für die unterstützung abgefragt wird. Dieser Parameter akzeptiert RFC 2045 Content-Type-Zeichenfolgen zum Angeben von Medientyp- und Untertypbezeichnern sowie RFC 6381 Codecs-IDs für die erforderlichen Codecs. Diese Basiszeichenfolgen entsprechen denen, die in der HTML5 HTMLMediaElement canPlayType-Methode verwendet werden. RFC 2045 ermöglicht zusätzliche, benutzerdefinierte Parameter als Modifizierer in Form von ";<parameter>=<name>[=<value>] [,<name>[=<value>]". RFC 2045-kompatible Parser müssen diese Parameter ignorieren, wenn sie nicht erkannt werden. Für die Featureabfragen <wird der Parameter> als Feature bezeichnet.

Die Implementierung erfordert die RFC 2045-Medientyp- und Untertyp-IDs, z. B. "video/mp4", und RFC 6381 codec parameter codec="<video codec>[,<audio codec>]", um immer vorhanden zu sein, um gültige Abfrageergebnisse bereitzustellen.

Beachten Sie, dass die Begriffe Inhaltstyp und Typ historisch als MIME-Typ bekannt sind.

[in] keySystem

Ein BSTR , der den PlayReady-Namespace identifiziert, um eine Abfrage zu überprüfen und Hardware- oder Softwareschutz anzugeben. Verwenden Sie "com.microsoft.playready.recommendation.3000" für Hardwareabfragen (PlayReady muss Unterstützung für das Hardware-Offload haben), "com.microsoft.playready.recommendation.2000" für explizite Abfragen für den Softwareschutzsupport und "com.microsoft.playready.empfehlung" für allgemeine Abfragen (muss für softwareschutzunterstützung antworten, um abwärtskompatibilität zu gewährleisten).

[out] pAnswer

Ein Wert aus der MF_MEDIA_ENGINE_CANPLAY-Aufzählung , der angibt, ob die abgefragten Funktionen wahrscheinlich unterstützt, möglicherweise unterstützt werden oder nicht unterstützt werden.

Rückgabewert

S_OK zum Erfolg.

Bemerkungen

Der Typeingabeparameter muss RFC 6381 Content-Type-Medientyp und Untertypbezeichner enthalten. Außerdem muss die RFC 2045 Codecs-Parameterzeichenfolge vorhanden sein. MPEG-4 ist der einzige Container, der für diese API unterstützt wird. H.264 (avc1) und HEVC (hvc1, hev1) sind die einzigen Videocodecs, die unterstützte Antworten bereitstellen. MPEG-4 (mp4a), MPEG-1 Layer 3 (mp3), Dolby Digital (ac-3) und Dolby Digital Plus (ec-3) sind die einzigen Audiocodecs, die unterstützte Antworten bereitstellen. Unterstützte Zeichenfolgen sind:

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

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

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

Ab Windows 10, Version 1709, werden auch Folgende unterstützt:

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

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

Der Featuresteil der Abfragezeichenfolge wird mithilfe eines Semikolontrennzeichens an eine der obigen Zeichenfolgen angefügt. Der zugrunde liegende Grafiktreiber und die Hardware erzwingen Einschränkungen, wie Features abgefragt werden können. Für die Videosubsysteme gelten die folgenden Anforderungen:

In einem einzigen Aufruf können nur eine Abfrage von Featurenamen und Werten verwendet werden.
Eine Decodierungs-Subsystemabfrage kann ohne Anzeige 1-, Anzeige 2- oder Ausgabeschutzabfrage ausgeführt werden.
Für eine Anzeige 1-Subsystemabfrage muss eine Decodierungs-Subsystemabfrage vorhanden sein.
Eine Display 2-Subsystemabfrage erfordert eine Decodierungs-Subsystemabfrage, erfordert jedoch keine Display 1-Subsystemabfrage.
Eine Ausgabeschutz-Subsystemabfrage (HDCP) kann mit oder ohne Decode, Display 1 oder Display 2-Subsystemabfrage ausgeführt werden, vorbehaltlich der Einschränkungen #3 und #4.

Die General: Efficiency Abfrage kann mit anderen Subsystemabfragen kombiniert werden.

Das zurückgegebene Ergebnis ist das logische AND aller einzelnen Featureabfragen mit der folgenden Klarstellung: Ein Vielleicht-Ergebnis ist nur vom Ausgabeschutz-Subsystem und nur vorübergehend zulässig. Dies hat vielleicht Vorrang vor einem Wahrscheinlichen Ergebnis aus dem AND aller anderen Featureabfragen, bis die "Vielleicht " im Laufe der Zeit auf "Wahrscheinlich " oder "Nicht unterstützt" aufgelöst wird. Das aktuelle Zeitlimit für "Möglicherweise auflösen" beträgt 10 Sekunden.

In der folgenden Tabelle sind die unterstützten einzelnen Featureabfragen aufgeführt, die nach Videosubsystem organisiert sind:

Gegenstand	Videountersystem	Featurename	Featurewert	BESCHREIBUNG	Obligatorisch für dieses Subsystem
1a	Entschlüsseln	decode-res-x	Nicht negative Zahl in Pixeln	Unterstützt der Videodecoder diese maximale Auflösung auf der X-Achse?	Ja
1b	Entschlüsseln	decode-res-y	Nicht negative Zahl in Pixeln	Unterstützt der Videodecoder diese maximale Auflösung auf der Y-Achse?	Ja
1c	Entschlüsseln	Decodierungsbitrate	Positive Zahl in Kilobits pro Sekunde (KBit/s)	Unterstützt der Videodecoder diese maximale Bitrate?	Ja
1d	Entschlüsseln	decode-fps	24, 25, 29.97, 30, 50, 59.94 oder 60	Unterstützt das Video decodiert diesen maximalen Frames pro Sekunde (FPS)-Wert?	Ja
1e	Entschlüsseln	decode-bpc (decode-bpp ist veraltet)	0, 8, 10 oder 12	Kann der Videodecoder diese Farbtiefe pro Pixel nutzen?	Ja
1f	Entschlüsseln	Decoder-Hardwarebeschleunigung^**	1 oder kein Wert als wahr	Ist DIE DXVA-Hardwarebeschleunigung unabhängig davon verfügbar, ob ein Betriebssystemdecoder vorhanden ist?	N
1g	Entschlüsseln	Decoder-Softwarebeschleunigung ^**	1 oder kein Wert als wahr	Ist ein Betriebssystemdecoder vorhanden, der den Datenstrom decodieren kann?	N
1h	Entschlüsseln	decoder-software-requires-hardware^**	1 oder kein Wert als wahr	Erfordert die Funktionalität des Betriebssystemdecoders, dass die DXVA-Hardwarebeschleunigung vorhanden ist?	N
2a	Anzeige 1	display-res-x	Nicht negative Zahl in Pixeln	Unterstützt mindestens eine überschneidende^** Anzeige diese Auflösung in der X-Achse?	Ja
2b	Anzeige 1	display-res-y	Nicht negative Zahl in Pixeln	Unterstützt mindestens eine überschneidende^*** Anzeige diese Auflösung in der Y-Achse?	Ja
2c	Anzeige 1	Anzeigeaktualisierung	24, 25, 29.97, 30, 50, 59.94 oder 60	Ist die Anzeige (wie von Windows verstanden) für mindestens die angeforderte Aktualisierungsrate konfiguriert?	N
2d	Anzeige 1	display-bpc (display-bpp ist veraltet)	8 oder 10	Erkennen alle überschneidende Displays mit ≥ erforderliche Auflösung mindestens diese Farbtiefe?	N
3	Anzeige 2^*	Hdr	1 (unterstützt)	Unterstützt das Ziel das Hdr-Rendering (High Dynamic Range)	Ja
4	Ausgabeschutz	hdcp	0 (aus), 1 (ohne HDCP 2.2 Typ 1-Einschränkung), 2 (aktiviert mit HDCP 2.2 Typ 1-Einschränkung	Unterstützen alle intersectingfähigen Anzeigeanzeigen mindestens die Anforderungsschutzstufe?	Ja
5	Allgemein: Effizienz^**	Effizienzeinstellung	0 (off = no restriction), 1 (on = limit resolution when on battery power)	Soll der Benutzer die Akkulaufzeit, den Streaming-Aufwand und/oder die Downloadgeschwindigkeit vor der höchsten Auflösung verwenden?^****	Ja
6a	Entschlüsselung	Verschlüsselungstyp	"cenc" oder "cbcs", mit optionalem "-clearlead"-Suffix.	Wird dieser Verschlüsselungstyp für die Entschlüsselung mit dem angegebenen Codec/Key-System unterstützt? Wenn der Wert nicht angegeben ist, wird der Standardwert "cenc" verwendet. Ab Windows 11 Build 22621 und Windows 10 Build 19045.5796 oder höher wird das Suffix "-clearlead" unterstützt. Wenn "-clearlead" an den Verschlüsselungstypwert angefügt wird, wird auch unterstützung für die Verwendung von klaren Inhalten am Anfang verschlüsselter Inhalte angefordert. Das Löschen von Inhalten am Anfang des Inhalts beschleunigt die Zeit zum Darstellen des ersten Frames. Wenn "-clearlead" dem Verschlüsselungstyp hinzugefügt wird, wird die Versionsnummer des angeforderten Codecs überprüft. Die Codecs AV1 und VP9 werden auf Die Hauptversion 2 überprüft, und HEVC wird auf v2.0.53421 oder höher überprüft.	N
6b	Entschlüsselung	encryption-iv-size	8 oder 16	Wird diese Initialisierungsvektorgröße (IV) (in Bytes) für die Entschlüsselung mit dem angegebenen Codec /Key-System unterstützt? Wenn der Wert nicht angegeben ist, wird der Standardwert 8 verwendet.	N

^* Nur unter Windows 10, Version 1607 und neueren Betriebssystemversionen unterstützt

^** Nur unter Windows 10, Version 1709 und neueren Betriebssystemversionen unterstützt

^*** Der Schnittmengenalgorithmus lautet:

Hier finden Sie alle Anzeigen, in denen der Videoclientbereich der Anwendungsoberfläche Pixel aufweist.
Suchen Sie alle Grafikkarten, die die Displays aus Schritt 1 steuern. Bei einer Hardware-DRM-Abfrage wird dieser Satz von Adaptern nur auf die Adapter gefiltert, die Hardware-DRM-Unterstützung haben.
Suchen Sie alle anzeigen, die mit den Grafikkarten aus Schritt 2 verbunden sind.

^**** Es liegt bei dem Inhaltsanbieter, den Auflösungsgrenzwert auszuwählen, der verwendet werden soll, wenn diese Richtlinie aktiviert ist. Es wird ein Grenzwert von 1080p empfohlen, aber 720p kann verwendet werden. Beachten Sie, dass die Eingabe für diese Richtlinie von der Seite "Videoeinstellungen" stammt, die in Windows 10, Version 1709, hinzugefügt wurde.

Die Paare für Die Elemente 1a und 1b und 2a und 2b werden jeweils als (angefordert x >= tatsächliche Schnittmenge maximum x) UND (angefordert y >= tatsächliche Schnittmenge maximal y) mit einer Änderung berechnet, die hochformatiert wird, indem x und y bei Bedarf ausgetauscht werden.

Die hdcp-Abfrage (Element 4) hat eine rechenintensive erste Aufrufkosten. HDCP muss auf der angeforderten Ebene aktiviert sein, um zu prüfen, ob die angeforderte Ebene mit der aktiven Anzeigetopologie erfüllt werden kann. Das Vielleicht-Ergebnis , dass HDCP asynchron ausgewertet wird und bis zu mehrere Sekunden mit HDCP 2.2 dauert, aber die Abfrage synchron mit minimalem Blockieren ist, erfordert, dass der Aufrufer die Abfrage wiederholt verwendet, bis das Ergebnis als wahrscheinlich oder nicht unterstützt abgeschlossen wird. Das Ändern der angeforderten HDCP-Ebene in einer Abfrage, während sie sich noch im Zustand "Vielleicht" befindet, führt wahrscheinlich zu einer ungültigen Antwort. Das "Vielleicht "-Timeout beträgt etwa 10 Sekunden.

Es wird dringend empfohlen, eine hdcp-Abfrage aufgrund der zugrunde liegenden Berechnungskosten häufiger als einmal alle 250 Millisekunden aufzurufen. 500 Millisekunden sind das bevorzugte Minimum. Zwischenspeichern wird ausgeführt, um diese Kosten zu minimieren, aber alle Änderungen der Anzeigetopologie beim Abfragen ungültig machen die Zwischenspeicherung.

Als Implementierungsdetail können Grafikkarten HDCP 2.2 verwenden, wenn alle Knoten sie unterstützen, auch wenn die HDCP 2.2 Typ 1-Einschränkung nicht festgelegt wurde. HDCP 2.2 kann wesentlich länger dauern als HDCP 1.x, um zu interagieren. Beobachtungen zu Fernsehgeräten der aktuellen Generation zeigen Zeiten bis zu 8 Sekunden im Vergleich zu etwa 1 Sekunde für HDCP 1.x-Geräte einschließlich Repeater an. Daher erfordert eine erste hdcp=1 Abfrage beim Starten der Anwendung oder nach einer Änderung der Ausgabetopologie bis zu 8 Sekunden plus Rand für diesen schlimmsten Fall. Die Verwendung von 10 Sekunden als maximale Wartezeit wird empfohlen, die Anwendungsstartabfrage auszuführen, wenn der Benutzer am wenigsten erwartet wird, einen Titel zu wählen, z. B. auf einer ersten Benutzeroberfläche. Wenn keine Topologieänderungen vorgenommen werden, werden alle weiteren hdcp-Abfragen Unter-Sekunde sein. Wenn der Inhalt die gleiche HDCP-Ausgabeanforderung wie die Abfrage aufweist, wird die Zwischenspeicherung die mehrzweisige Wartezeit, die beim Wiedergabestart erneut auftritt, entjmieren.

Bei einer Änderung der Ausgabetopologie dauert die Stabilisierung des Desktops häufig mehrere Sekunden. Eine Änderung und insbesondere eine Reduzierung der Ausgabeschutzebene führt in der Regel dazu, dass die aktive Wiedergabe mit Hardware-DRM nicht im Design fehlschlägt. Hier sollte eine Reaktion auf einen MF_POLICY_UNSUPPORTED (0xC00D7159) Fehler darin sein, den Fehler vom Benutzer auszublenden, erneut abzufragen und mit einer geeigneten Inhaltsversion für alle geänderten Funktionen fortzusetzen. Effektiv wirkt dies als Erweiterung der "Hotplug"-Stabilisierungszeit.

Software-DRM-Decodierungsfeatureabfragen sind möglicherweise mehrdeutig bei der Leistung, da die H.264-Implementierung entweder softwaredecodierungs- oder DXVA-GPU-Offload (DirectX Video Acceleration) ermöglicht. H.264 DXVA ist jedoch in allen Windows-Endpunkten sehr verbreitet.

Eine funktionale Einschränkung bei Software-DRM-Decodierungsabfragen besteht darin, dass der Decode-bpc nicht ausgewertet wird. Windows unterstützt keine H.264 10-Bit-Decodierung, aber eine Abfrage ist decode-bpc=10 erfolgreich.

Das Featureabfrageergebnis spiegelt die maximalen theoretischen Funktionen der Subsysteme wider. Andere Aktivitäten in den GPU- oder unterschiedlichen Leistungszuständen können die tatsächliche Funktion verringern.

Beispiele für Hardware-DRM-Abfragen

Im Folgenden wird die häufigste Verwendung für 4K-10-Bit-HEVC Standard Dynamic Range (SDR)-Inhalte mit Hardware-DRM- und HDCP 2.2 Typ 1-Einschränkung gezeigt:

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

Wo mp4a kann durch mp3, , ac-3oder ec-3. Die Decodierungsbitrate kann je nach Codierung des Inhaltsanbieters angepasst werden. decode-fps kann auf 60 und nicht auf 30 festgelegt werden, kann aber durch Durchsatzfunktion des Hardware-DRM-Sicherheitsprozessors abgestört werden. display-res-x und display-res-y die Werte können niedriger als vollständige 4K festgelegt werden, wenn der Anbieter beispielsweise 4K-Datenströme auf 3200 x 1800, 3000 x 2000 oder 2560 x 1440 übertragen möchte.

Da die Decodierung von Abfrageergebnissen nicht erwartungsgemäß dynamisch geändert werden soll, können aufeinander folgende Abfragen hdcp=2 in "Vielleicht" eine kürzere Form als kleine Optimierung verwenden.

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

Natürlich wird diese Optimierung keine Änderung der dynamischen Monitorauflösung fangen, aber eine solche Änderung würde die Einrichtung von HDCP wahrscheinlich trotzdem stören.

Im Folgenden wird die häufigste Verwendung für 4K-10-Bit-HEVC High Dynamic Range (HDR)-Inhalte mit Hardware-DRM und HDCP 2.2 Typ 1-Einschränkung gezeigt:

Hinweis: Für Windows 10, Version 1607, gibt an, hdr=1 dass entweder die 10-Bit-MPO-Unterstützung mit DXGI_COLOR_SPACE_YCBCR_FULL_G22_LEFT_P2020 oder DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 oder DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020 vorhanden ist oder dass der entwicklungsgeschützte HighColor-Registrierungsschlüssel vorhanden ist und festgelegt wurde: HKLM\SOFTWARE\Microsoft\Windows\DWM key HighColor als DWORD-Wert von 1.

Im Folgenden wird die am häufigsten verwendete Verwendung für 1080p-8-Bit-H.264-SDR-Inhalte mit Hardware-DRM und HDCP ohne Einschränkung von 2.2 Typ 1 gezeigt:

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

Anforderungen

Anforderung	Wert
Überschrift	mfmediaengine.h

Siehe auch

MF_MEDIA_ENGINE_CANPLAY