IMFExtendedDRMTypeSupport::IsTypeSupportedEx-Methode (mfmediaengine.h)
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
);
Parameter
[in] type
Ein BSTR , der die Features identifiziert, für die die Unterstützung abgefragt wird. Dieser Parameter akzeptiert RFC 2045 Content-Type-Zeichenfolgen, um Medientyp- und Untertypbezeichner anzugeben, und RFC 6381 Codecs-Bezeichner für die erforderlichen Codecs. Diese Basiszeichenfolgen sind konsistent mit 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 ist als Feature bezeichnet.
Die Implementierung erfordert, dass der RFC 2045-Medientyp und die Untertypbezeichner, z. B. "video/mp4", und rfc 6381 codec parameter codec="<video codec>[,<audio codec>]" immer vorhanden sind, 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, mit dem die Abfrage überprüft werden soll, und der Hardware- oder Softwareschutz angibt. Verwenden Sie "com.microsoft.playready.recommendation.3000" für Hardwareabfragen (PlayReady muss Unterstützung für Hardwareauslagerung haben), "com.microsoft.playready.recommendation.2000" für explizite Abfragen nach Softwareschutzunterstützung und "com.microsoft.playready.recommendation" 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-Enumeration , der angibt, ob die abgefragten Funktionen wahrscheinlich unterstützt, möglicherweise unterstützt werden oder nicht unterstützt werden.
Rückgabewert
S_OK auf Erfolg.
Hinweise
Der Typeingabeparameter muss über rfc 6381 Content-Type-Medientyp und Untertypbezeichner verfügen. Außerdem muss die Parameterzeichenfolge RFC 2045 Codecs 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 der Windows 10, Version 1709, werden auch Folgende unterstützt:
Video/mp4;codecs=”vp9,<audio codec>”
Video/mp4;codecs=”vp09,<audio codec>”
Der Featureteil 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:
- Nur eine Abfrage von Featurenamen plus Werten kann von jedem der Subsysteme in einem einzelnen Aufruf verwendet werden.
- Eine Decodierungssubsystemabfrage kann ohne Eine Anzeige 1-, Anzeige 2- oder Ausgabeschutzabfrage ausgeführt werden.
- Für eine Display 1-Subsystemabfrage muss eine Decodierungssubsystemabfrage vorhanden sein.
- Eine Display 2-Subsystemabfrage erfordert eine Decodierungssubsystemabfrage, aber keine Display 1-Subsystemabfrage.
- Eine HDCP-Abfrage (Output Protection Subsystem) kann mit oder ohne Eine Decodierungs-, Display 1- oder Display 2-Subsystemabfrage ausgeführt werden, vorbehaltlich der Einschränkungen #3 und #4.
Die General: Efficiency Abfrage kann mit allen anderen Subsystemabfragen kombiniert werden.
Das zurückgegebene Ergebnis ist das logische AND aller einzelnen Featureabfragen mit der folgenden Klarstellung: Ein Maybe-Ergebnis ist nur vom Ausgabeschutzsubsystem und nur vorübergehend zulässig. Dieses Vielleicht hat Vorrang vor einem Wahrscheinlichen Ergebnis aus dem UND aller anderen Featureabfragen, bis vielleicht im Laufe der Zeit in Wahrscheinlich oder Nicht unterstützt aufgelöst wird. Das aktuelle Zeitlimit für Maybe to resolve beträgt 10 Sekunden.
In der folgenden Tabelle sind die unterstützten einzelnen Featureabfragen aufgelistet, die nach Videosubsystem organisiert sind:
| Element | Video-Untersystem | Funktionsname | Featurewert | BESCHREIBUNG | Obligatorisch für dieses Subsystem |
|---|---|---|---|---|---|
| 1a | Decode | decode-res-x | Nicht negative Zahl in Pixel | Unterstützt der Videodecoder diese maximale Auflösung in der X-Achse? | J |
| 1b | Decode | decode-res-y | Nicht negative Zahl in Pixel | Unterstützt der Videodecoder diese maximale Auflösung in der Y-Achse? | J |
| 1c | Decode | Decodierungsbitrate | Positive Zahl in Kilobit pro Sekunde (KBit/s) | Unterstützt der Videodecoder diese maximale Bitrate? | J |
| 1d | Decode | decode-fps | 24, 25, 29.97, 30, 50, 59.94 oder 60 | Unterstützt das decodierte Video diesen wert für maximale Frames pro Sekunde (FPS)? | J |
| 1e | Decode | decode-bpc (decode-bpp ist veraltet) | 0, 8, 10 oder 12 | Kann der Videodecoder diese Farbtiefe pro Pixel nutzen? | J |
| 1f | Decode | Decoder-Hardwarebeschleunigung** | 1 oder kein Wert als true | Ist die DXVA-Hardwarebeschleunigung unabhängig davon verfügbar, ob ein Betriebssystemdecoder vorhanden ist? | N |
| 1g | Decode | Decoder-Software-Beschleunigung ** | 1 oder kein Wert als true | Kann ein Betriebssystemdecoder den Stream decodieren? | N |
| 1h | Decode | decoder-software-requires-hardware** | 1 oder kein Wert als true | Erfordert die Funktionalität des Betriebssystemdecoders, dass die DXVA-Hardwarebeschleunigung vorhanden ist? | N |
| 2a | Anzeige 1 | display-res-x | Nicht negative Zahl in Pixel | Unterstützt mindestens ein sich überschneidendes** Display diese Auflösung in der X-Achse? | J |
| 2b | Anzeige 1 | display-res-y | Nicht negative Zahl in Pixel | Unterstützt mindestens ein sich überschneidendes*** Display diese Auflösung auf der Y-Achse? | J |
| 2c | Anzeige 1 | Display-Refreshrate | 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 sich überschneidende Displays mit ≥ erforderlichen Auflösung mindestens diese Farbtiefe? | N |
| 3 | Anzeige 2* | hdr | 1 (unterstützt) | Unterstützt das Ziel HDR-Rendering (High Dynamic Range) | J |
| 4 | Ausgabeschutz | Hdcp | 0 (off), 1 (on ohne HDCP 2.2 Type 1-Einschränkung), 2 (ein mit HDCP 2.2 Type 1-Einschränkung | Unterstützen alle sich überschneidenden aktivierten Displays mindestens die Anforderungsschutzebene? | J |
| 5 | Allgemein: Effizienz** | Effizienzeinstellung | 0 (off = no restriction), 1 (on = limit resolution when on battery power) | Möchte der Benutzer Akkulaufzeit, Streaming-Overhead und/oder Downloadgeschwindigkeit der höchsten Auflösung vorzugeigen?**** | J |
| 6a | Entschlüsselung | Verschlüsselungstyp | "cenc" oder "cbcs", mit optionalem Suffix "-clearlead". | 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 Build 22621 wird das Suffix "-clearlead" unterstützt. Wenn "-clearlead" an den Verschlüsselungstypwert angefügt wird, wird auch Unterstützung für die Verwendung von eindeutigen Inhalten am Anfang verschlüsselter Inhalte angefordert. Das Löschen von Inhalten am Anfang des Inhalts beschleunigt die Zeit bis zur Darstellung des ersten Frames. Wenn dem Verschlüsselungstyp "-clearlead" hinzugefügt wird, wird die Versionsnummer des angeforderten Codecs überprüft. Die Av1- und VP9-Codecs werden auf Hauptversion 2 und HEVC 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 Überschneidungsalgorithmus ist:
- Suchen Sie nach allen Anzeigen, in denen die Videoclientregion der Anwendung die Benutzeroberfläche mit Pixeln aufweist.
- Suchen Sie alle Grafikkarten, die die Displays aus Schritt 1 antreiben. Bei einer Hardware-DRM-Abfrage wird dieser Satz von Adaptern nur auf die Adapter gefiltert, die Hardware-DRM-Unterstützung haben.
- Suchen Sie alle Displays, die mit den Grafikkarten aus Schritt 2 verbunden sind.
**** Es liegt am Inhaltsanbieter, das Auflösungslimit auszuwählen, das verwendet werden soll, wenn diese Richtlinie aktiviert ist. Ein Grenzwert von 1080p wird empfohlen, aber es kann 720p verwendet werden. Beachten Sie, dass die Eingabe für diese Richtlinie von der Benutzeroberfläche der Videoeinstellungen stammt, die in Windows 10 Version 1709 hinzugefügt wurde.
Die Paare für die Elemente 1a und 1b sowie 2a und 2b werden jeweils als (angeforderte x >= tatsächliche Überschneidungsgruppe maximum x) UND (angefordert y >= tatsächlicher Überschneidungssatz maximum y) berechnet, mit der Änderung, dass die Hochformatanzeige in das Querformat normalisiert wird, indem x und y bei Bedarf ausgetauscht werden.
Die hdcp-Abfrage (Element 4) weist rechenintensive Kosten für den ersten Aufruf auf. HDCP muss auf der angeforderten Ebene aktiviert werden, um zu prüfen, ob die angeforderte Ebene mit der aktiven Anzeigetopologie erfüllt werden kann. Das Möglicherweise ergebnis, weil HDCP asynchron ausgewertet wird und mit HDCP 2.2 mehrere Sekunden dauert, aber die Abfrage synchron mit minimaler Blockierung ist, erfordert, dass der Aufrufer die Abfrage wiederholt verwendet, bis das Ergebnis als Wahrscheinlich oder Nicht unterstützt abgeschlossen wird. Wenn Sie die angeforderte HDCP-Ebene in einer Abfrage ändern, während sie sich noch im Zustand Maybe befindet, führt dies 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 nicht öfter als einmal alle 250 Millisekunden aufzurufen. 500 Millisekunden sind das bevorzugte Minimum. Die Zwischenspeicherung wird ausgeführt, um diese Kosten zu minimieren, aber alle Änderungen der Anzeigetopologie während der Abfrage ungültig machen die Zwischenspeicherung ungültig.
Als Implementierungsdetails können Grafikkarten HDCP 2.2 verwenden, wenn dies von allen Knoten unterstützt wird, auch wenn die HDCP 2.2 Typ 1-Einschränkung nicht festgelegt wurde. HDCP 2.2 kann deutlich länger dauern als HDCP 1.x. Beobachtungen auf Fernsehern der aktuellen Generation zeigen Zeiten von bis zu 8 Sekunden gegenüber etwa 1 Sekunde für HDCP 1.x-Geräte einschließlich Repeatern. Daher erfordert eine erste hdcp=1 Abfrage beim Starten der Anwendung oder nach einer Änderung der Ausgabetopologie bis zu 8 Sekunden plus Marge für diesen schlimmsten Fall. Bei Verwendung von 10 Sekunden als maximale Wartezeit wird empfohlen, die Anwendungsstartabfrage auszuführen, wenn der Benutzer am wenigsten erwartet wird, dass er einen Titel auswählt, z. B. auf einer anfänglichen Benutzeroberfläche. Wenn keine Topologieänderungen auftreten, werden alle weiteren hdcp-Abfragen in einer Sekunde angezeigt. Wenn der Inhalt die gleiche HDCP-Ausgabeanforderung wie die Abfrage aufweist, wird beim Zwischenspeichern die wartezeit von mehreren Sekunden beim Start der Wiedergabe erneut ausgelöst.
Bei einer Ausgabetopologieänderung dauern hochauflösende Fernseher und Monitore oft mehrere Sekunden, um den Desktop zu stabilisieren. Eine Änderung und insbesondere eine Verringerung des Ausgabeschutzniveaus führt in der Regel dazu, dass die aktive Wiedergabe mit Hardware-DRM designbedingt fehlschlägt. Hier sollte eine Reaktion auf einen MF_POLICY_UNSUPPORTED -Fehler (0xC00D7159) darin sein, den Fehler vor dem Benutzer auszublenden, erneut abzuabfragen und mit einer entsprechenden Inhaltsversion für alle geänderten Funktionen fortzusetzen. Dies wirkt effektiv als Verlängerung der "Hotplug"-Stabilisierungszeit.
Software-DRM-Decodierungsfeatureabfragen sind potenziell mehrdeutig hinsichtlich der Leistung, da die H.264-Implementierung die Softwaredecodierung oder die DxVA-GPU-Auslagerung (DirectX Video Acceleration) ermöglicht. H.264 DXVA ist jedoch für alle Windows-Endpunkte sehr verbreitet.
Eine Funktionseinschränkung bei Software-DRM-Decodierungsabfragen besteht darin, dass decode-bpc nicht ausgewertet wird. Windows unterstützt keine H.264-10-Bit-Decodierung, aber eine Abfrage mit decode-bpc=10 ist erfolgreich.
Das Featureabfrageergebnis spiegelt die maximalen theoretischen Funktionen der Subsysteme wider. Andere Aktivitäten in der GPU oder unterschiedliche Leistungszustände können die tatsächliche Funktion beeinträchtigen.
Hardware-DRM-Abfragebeispiele
Im Folgenden wird die häufigste Verwendung für 4K 10-Bit-HEVC-Inhalte (SDR) mit Hardware-DRM und HDCP 2.2 Typ 1-Einschränkung veranschaulicht:
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”’);
Dabei mp4a kann durch mp3, ac-3oder ec-3ersetzt werden. Die Decodierungsbitrate kann je nach Codierung des Inhaltsanbieters angepasst werden. decode-fps kann auf 60 statt auf 30 festgelegt werden, kann aber durch die Durchsatzfunktion des Hardware-DRM-Sicherheitsprozessors abgegrenzt werden. display-res-x und display-res-y werte können niedriger als full 4K festgelegt werden, wenn der Anbieter 4K-Streams auf 3200 x 1800, 3000 x 2000 oder 2560 x 1440 Displays pushen möchte.
Da es nicht erwartet wird, dass sich die Ergebnisse der Decodierungsabfrage dynamisch ändern, kann die aufeinander folgende Abfrage für hdcp=2 die Zeit in Maybe 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 abfangen, aber eine solche Änderung würde wahrscheinlich die einrichtung von HDCP sowieso 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 veranschaulicht:
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”’);
Hinweis: Für Windows 10, Version 1607, gibt an, hdr=1 dass entweder 10-Bit-MPO 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 reine Entwicklungsregistrierungsschlüssel HighColor vorhanden ist und festgelegt wurde: HKLM\SOFTWARE\Microsoft\Windows\DWM key HighColor als DWORD-Wert von 1.
Im Folgenden wird die häufigste Verwendung für 8-Bit-H.264-SDR-Inhalte von 1080p mit Hardware-DRM und HDCP ohne 2.2 Typ 1-Einschränkung 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
| Kopfzeile | mfmediaengine.h |
Weitere Informationen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für