ProtectionCapabilities.IsTypeSupported(String, String) Methode

Referenz

Definition

Namespace:: Windows.Media.Protection

Wichtig

Einige Informationen beziehen sich auf Vorabversionen, die vor dem Release ggf. grundlegend überarbeitet werden. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.

Bearbeiten

Abfragen von Videodecodierungs-, Anzeige- und Ausgabeschutz-Subsystemen für DRM-Funktionen.

Warnung

Es wird empfohlen, diese Methode nur mit Windows 10, Version 1607 oder neuerer Betriebssystemversion, zu verwenden, auch wenn sie in älteren Versionen von Windows 10 vorhanden ist.

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

Parameter

type: String
Platform::String

winrt::hstring

Zeichenfolge, die die Features identifiziert, für die 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 <parameter>Feature-benannt.

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

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

keySystem: String
Platform::String

winrt::hstring

Eine Zeichenfolge, die den PlayReady-Namespace zur Überprüfung der Abfrage angibt, wobei Hardware- oder Softwareschutz angegeben wird. 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).

Gibt zurück

ProtectionCapabilityResult

Ein Wert, der angibt, ob die abgefragten Funktionen wahrscheinlich unterstützt, möglicherweise unterstützt werden oder nicht unterstützt werden.

Hinweise

Der Typ Eingabeparameters muss RFC 6381 Content-Type-Medientyp und Untertypbezeichner vorhanden sein. 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 abfrage General: Efficiency 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. Diese Vielleicht hat Vorrang vor einem Wahrscheinlich Ergebnis aus dem AND aller anderen Featureabfragen, bis die Vielleicht im Laufe der Zeit aufgelöst wird, um entweder Wahrscheinlich oder Nicht unterstützt. Das aktuelle Zeitlimit für Vielleicht aufzulösen ist 10 Sekunden.

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

Artikel	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?	Y
1b	Entschlüsseln	decode-res-y	Nicht negative Zahl in Pixeln	Unterstützt der Videodecoder diese maximale Auflösung auf der Y-Achse?	Y
1c	Entschlüsseln	Decodierungsbitrate	Positive Zahl in Kilobits pro Sekunde (KBit/s)	Unterstützt der Videodecoder diese maximale Bitrate?	Y
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?	Y
1e	Entschlüsseln	decode-bpc (decode-bpp ist veraltet)	0, 8, 10 oder 12	Kann der Videodecoder diese Farbtiefe pro Pixel nutzen?	Y
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?	Y
2b	Anzeige 1	display-res-y	Nicht negative Zahl in Pixeln	Unterstützt mindestens eine überschneidende^*** Anzeige diese Auflösung auf der Y-Achse?	Y
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	2^* anzeigen	Hdr	1 (unterstützt)	Unterstützt das Ziel das Hdr-Rendering (High Dynamic Range)	Y
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?	Y
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?^****	Y
6a	Entschlüsselung	Verschlüsselungstyp	"cenc" oder "cbcs"	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.	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 an 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 (angefordertes x >= ist-Intersecting set maximum x) AND (angefordert y >= tatsächliche Überschneidungssatz maximal y) mit einer Änderung, die hochformatige Anzeige im Querformat normalisiert 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. Die Vielleicht Ergebnis, weil 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. 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 ca. 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 muss eine erste hdcp=1 Abfrage beim Starten der Anwendung oder nach einer Ausgabetopologieänderung bis zu 8 Sekunden plus Rand für diesen schlimmsten Fall warten. 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 -Fehler (0xC00D7159) 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 mit decode-bpc=10 wird erfolgreich ausgeführt.

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

Kann mp4a durch mp3, ac-3oder ec-3ersetzt werden. Die Decodierungsbitrate kann je nach Codierung des Inhaltsanbieters angepasst werden. decode-fps kann auf 60 und nicht auf 30 festgelegt werden, kann aber durch die Durchsatzfunktion des Hardware-DRM-Sicherheitsprozessors tot werden. display-res-x und display-res-y 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 für hdcp=2, während in "Vielleicht" eine kürzere Form als kleine Optimierung verwendet werden kann.

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 hdr=1 an, 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 nur-Entwicklungs-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”’);

Gilt für:

Weitere Informationen

ProtectionCapabilityResult

Freigeben über