Hardware-MFTs
Hinweis
Dieses Thema gilt für Windows 7 oder höher.
In diesem Thema wird beschrieben, wie Sie eine Media Foundation-Transformation (MFT) schreiben, die als Proxy für einen Hardwareencoder, Decoder oder digitalen Signalprozessor (DSP) fungiert.
Wichtig
Wenn ein Hardwarecodec den AVStream-Multimediaklassentreiber verwendet, ist kein benutzerdefinierter MFT erforderlich. Media Foundation stellt zu diesem Zweck einen AVStream-Proxy bereit. Die Informationen in diesem Thema gelten nur für den speziellen Fall, in dem der Hardwarecodec AVStream nicht verwendet. Weitere Informationen finden Sie unter Hardwarecodec-Unterstützung in AVStream.
Dieses Thema enthält folgende Abschnitte:
- Introduction (Einführung)
- Hardware-MFT-Attribute
- Hardware-Handshakesequenz
- Datenverarbeitung
- Gekoppelter Decoder/Encoder
- Zugehörige Themen
Einführung
Jeder Hardwarecodec, der nicht auf AVStream basiert, muss einen eigenen MFT bereitstellen, um als Proxy für den Treiber zu fungieren. Ein Hardwarecodec kann mehrere unterschiedliche Funktionsblöcke enthalten:
- Encoder
- Decoder
- Frameskalierung/Formatkonvertierung
Jede dieser Funktionen sollte von einem separaten MFT verwaltet werden. Ein Hardware-MFT sollte niemals als mehrzweckiges "Transcoder" fungieren. Legen Sie stattdessen Codierungsfunktionen in einen Encoder-MFT und Decodierungsfunktionen in einen Decoder MFT ein. Wenn die Hardware Frameskalierung und Formatkonvertierungen bietet, platzieren Sie diese Funktionen in einem separaten Videoprozessor, der in der Kategorie MFT_CATEGORY_VIDEO_PROCESSOR registriert ist. Wenn die Hardware keine Frameskalierung oder Formatkonvertierung unterstützt, stellt Media Foundation einen Softwarevideoprozessor bereit.
Hardware-MFTs haben die folgenden allgemeinen Anforderungen:
- Hardware-MFTs müssen das neue asynchrone Verarbeitungsmodell verwenden, wie unter Asynchrone MFTs beschrieben.
- Hardware-MFTs müssen dynamische Formatänderungen unterstützen, wie unter Dynamische Formatänderungen beschrieben.
Hardware-MFT-Attribute
Ein Hardware-MFT muss die folgenden Methoden im Zusammenhang mit Attributen implementieren:
- IMFTransform::GetAttributes: Gibt einen Attributspeicher für globale MFT-Attribute zurück.
- IMFTransform::GetInputStreamAttributes: Gibt einen Attributspeicher für einen Eingabedatenstrom zurück.
- IMFTransform::GetOutputStreamAttributes: Gibt einen Attributspeicher für einen Ausgabestream zurück.
Wenn der MFT zum ersten Mal erstellt wird, muss er die folgenden Attribute für seinen eigenen globalen Attributspeicher (d. a. den von GetAttributes zurückgegebenen Attributspeicher) festlegen:
| attribute | BESCHREIBUNG |
|---|---|
| MF_TRANSFORM_ASYNC | Muss auf TRUE festgelegt werden. Gibt an, dass die MFT asynchrone Verarbeitung ausführt. |
| MFT_ENUM_HARDWARE_URL_Attribute | Enthält den symbolischen Link für das Hardwaregerät. Der Topologieladeprogramm verwendet das Vorhandensein dieses Attributs, um zu testen, ob ein MFT ein Hardwaregerät darstellt. |
| MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE | Muss auf TRUE festgelegt werden. Gibt an, dass der MFT dynamische Formatänderungen unterstützt. |
Hardware-Handshakesequenz
Wenn zwei MFTs dasselbe physische Gerät darstellen, können sie Daten innerhalb der Hardware austauschen, z. B. über einen Hardwarebus. Es ist nicht erforderlich, die Daten in den Systemspeicher und dann wieder auf das Gerät zu kopieren.
Im folgenden Diagramm stellen die MFTs mit den Bezeichnungen "A" und "B" Funktionsblöcke innerhalb derselben Hardware dar. In einem Transcodierungsszenario kann "A" beispielsweise einen Hardwaredecoder und "B" einen Hardwareencoder darstellen. Der Datenfluss zwischen "A" und "B" erfolgt innerhalb der Hardware. Die MFT mit der Bezeichnung "C" ist ein Software-MFT. Der Datenfluss von "B" nach "C" verwendet den Systemspeicher.
Zum Herstellen einer Hardwareverbindung müssen die beiden Hardware-MFTs einen privaten Kommunikationskanal verwenden. Diese Verbindung wird während der Formatverhandlung, vor dem Festlegen der Medientypen und vor dem ersten Aufruf von ProcessInput hergestellt. Der Verbindungsprozess funktioniert wie folgt:
Der Topologieladeprogramm überprüft beide MFTs auf das Vorhandensein des attributs MFT_ENUM_HARDWARE_URL_Attribute . Beachten Sie, dass der Wert dieses Attributs nicht untersucht wird.
Wenn MFT_ENUM_HARDWARE_URL_Attribute auf beiden MFTs vorhanden ist, führt das Topologieladeprogramm folgende Schritte aus:
- Das Topologieladeprogramm ruft IMFTransform::GetOutputStreamAttributes auf der Upstream MFT (A) auf. Diese Methode gibt einen IMFAttributes-Zeiger zurück. Lassen Sie diesen Zeiger pUpstream bezeichnen.
- Der Topologieladeprogramm ruft IMFTransform::GetInputStreamAttributes für den nachgeschalteten MFT (B) auf. Dieser Aufruf gibt auch einen IMFAttributes-Zeiger zurück. Lassen Sie diesen Zeiger pDownstream bezeichnen.
- Der Topologieladeprogramm legt das MFT_CONNECTED_STREAM_ATTRIBUTE-Attribut für pDownstream fest, indem IMFAttributes::SetUnknown aufgerufen wird. Der Wert des Attributs ist der pUpstream-Zeiger .
- Der Topologieladeprogramm legt das MFT_CONNECTED_TO_HW_STREAM-Attribut sowohl für pDownstream als auch für pUpstream auf TRUE fest.
An diesem Punkt verfügt der nachgeschaltete MFT über einen Zeiger auf den Upstream MFT-Attributspeicher, wie im folgenden Diagramm dargestellt.
Hinweis
Zur Übersichtlichkeit zeigt dieses Diagramm die Streams und die Attributspeicher als unterschiedliche Objekte, die für die Implementierung jedoch nicht erforderlich sind.
Der nachgeschaltete MFT verwendet den IMFAttributes-Zeiger, um einen privaten Kommunikationskanal mit dem Upstream MFT einzurichten. Da der Kanal privat ist, wird der genaue Mechanismus von der Implementierung definiert. Beispielsweise kann der MFT eine private COM-Schnittstelle abfragen.
In Schritt 4 muss der nachgeschaltete MFT überprüfen, ob die beiden MFTs dasselbe physische Gerät verwenden. Andernfalls müssen sie auf die Verwendung des Systemspeichers für den Datentransport zurückgreifen. Dies ermöglicht es dem MFT, mit Software-MFTs und anderen Hardwaregeräten ordnungsgemäß zu arbeiten.
Wenn der Handshake erfolgreich ist und die beiden MFTs einen privaten Datenkanal gemeinsam nutzen, verwenden sie nicht das Standarddatenverarbeitungsmodell (im nächsten Abschnitt beschrieben) am Verbindungspunkt. Insbesondere sendet der downstream-MFT keine METransformNeedInput-Ereignisse . Weitere Informationen finden Sie im nächsten Abschnitt in diesem Thema.
Datenverarbeitung
Wenn ein Hardware-MFT den Systemspeicher für den Datentransport verwendet, funktioniert der Prozess wie folgt:
- Um weitere Eingaben anzufordern, sendet der MFT ein METransformNeedInput-Ereignis .
- Das METransformNeedInput-Ereignis bewirkt, dass die Pipeline IMFTransform::P rocessInput aufruft.
- Wenn der MFT Über Ausgabedaten verfügt, sendet der MFT ein METransformHaveOutput-Ereignis .
- Das METransformHaveOutput-Ereignis bewirkt, dass die Pipeline IMFTransform::P rocessOutput aufruft.
Ausführliche Informationen finden Sie unter Asynchrone MFTs.
Wenn der MFT jedoch einen Hardwarekanal verwendet, sendet er diese Ereignisse nicht am Hardwareverbindungspunkt, da die gesamte Datenübertragung intern innerhalb der Hardware erfolgt. Daher ruft die Pipeline am Verbindungspunkt weder ProcessInput noch ProcessOutput auf.
Betrachten Sie beispielsweise das erste Diagramm in diesem Thema. Bei dieser Konfiguration würde die Datenverarbeitung wie folgt ablaufen:
- "A" sendet METransformNeedInput , um Daten anzufordern.
- Die Pipeline ruft ProcessInput auf "A" auf.
- "A" und "B" verarbeiten die Daten in der Hardware.
- Wenn die Verarbeitung abgeschlossen ist, sendet "B" ein METransformHaveOutput-Ereignis .
- Die Pipeline ruft ProcessOutput auf "B" auf.
Gekoppelter Decoder/Encoder
Wenn sich Decoder und Encoder auf demselben Hardwarechip befinden, kann es vorzuziehen sein, sie beim Transcodieren zusammen zu verwenden. Das heißt, die Auswahl eines sollte dazu führen, dass das andere in der Transcodierungspipeline ausgewählt wird. Um sicherzustellen, dass übereinstimmende Hardwarecodecs ausgewählt werden, sollten beide Codec-MFTs einen benutzerdefinierten Medientyp bieten. So erstellen Sie einen benutzerdefinierten Medientyp:
- Legen Sie das MF_MT_MAJOR_TYPE-Attribut je nach Bedarf auf MFMediaType_Audio oder MFMediaType_Video fest.
- Legen Sie das MF_MT_SUBTYPE-Attribut auf einen benutzerdefinierten GUID-Wert fest.
Andere Typattribute sind optional. Der Decoder gibt den benutzerdefinierten Typ aus seiner IMFTransform::GetOutputAvailableType zurück, und der Encoder gibt den benutzerdefinierten Typ von seiner IMFTransform::GetInputAvailableType-Methode zurück. In beiden Fällen muss der benutzerdefinierte Typ der erste Eintrag in der Liste sein (dwTypeIndex = 0).
Um mit Softwarecodecs zu arbeiten, sollte der Codec auch mindestens ein Standardformat zurückgeben, z. B. NV12 für Video. Standardformate sollten nach dem benutzerdefinierten Typ (dwTypeIndex> 0) angezeigt werden. Wenn die beiden Codecs immer gekoppelt sein müssen und nicht mit Softwarecodecs zusammenarbeiten können, sollten die MFTs nur das benutzerdefinierte Format zurückgeben und keine Standardformate zurückgeben.
Hinweis
Wenn ein Decoder keine Standardformate zurückgibt, kann er nicht für die Wiedergabe mit dem erweiterten Videorenderer verwendet werden. In diesem Fall sollte er als rein transcodierter Decoder registriert werden. Weitere Informationen finden Sie unter Transcodierungsgeschützte Decoder.
Zugehörige Themen