Freigeben über


Hardware-MFTs

Anmerkung

Dieses Thema bezieht sich auf Windows 7 oder höher.

 

In diesem Thema wird beschrieben, wie Sie eine Media Foundation-Transformation (Media Foundation Transform, MFT) schreiben, die als Proxy für einen Hardware-Encoder, einen Decoder oder einen digitalen Signalprozessor (Digital Signal Processor, 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 im Speziellen, wenn der Hardwarecodec AVStream nicht verwendet. Weitere Informationen finden Sie unter Hardware codec Support in AVStream.

 

Dieses Thema enthält die folgenden Abschnitte:

Einleitung

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 "Transcodierungselement" fungieren. Setzen Sie stattdessen Codierungsfunktionen in einen Encoder MFT und Decodieren von Funktionen in einen Decoder MFT. 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 die Frameskalierung oder -formatkonvertierung nicht 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 in asynchronen MFTsbeschrieben.
  • Hardware-MFTs müssen dynamische Formatänderungen unterstützen, wie in dynamischen Formatänderungenbeschrieben.

Hardware-MFT-Attribute

Ein Hardware-MFT muss die folgenden Methoden im Zusammenhang mit Attributen implementieren:

Wenn das MFT zum ersten Mal erstellt wird, muss er die folgenden Attribute für seinen eigenen globalen Attributspeicher festlegen (d. h. den von GetAttributeszurückgegebenen Attributspeicher):

Attribut Beschreibung
MF_TRANSFORM_ASYNC Muss auf TRUE-festgelegt sein. Gibt an, dass die MFT asynchrone Verarbeitung durchführt.
MFT_ENUM_HARDWARE_URL_Attribute Enthält die symbolische Verknüpfung für das Hardwaregerät.
Das 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 sein. Gibt an, dass die MFT dynamische Formatänderungen unterstützt.

 

Hardware-Handshake-Sequenz

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 der Bezeichnung "A" und "B" funktionale Blöcke innerhalb derselben Hardware dar. In einem Transcodierungsszenario kann "A" beispielsweise einen Hardwaredecoder darstellen und "B" einen Hardware-Encoder darstellen. Der Datenfluss zwischen "A" und "B" erfolgt innerhalb der Hardware. Die MFT mit der Bezeichnung "C" ist eine Software-MFT. Der Datenfluss von "B" zu "C" verwendet Systemspeicher.

Diagramm mit Feldern mit der Bezeichnung

Um eine Hardwareverbindung herzustellen, müssen die beiden Hardware-MFTs einen privaten Kommunikationskanal verwenden. Diese Verbindung wird während der Formatverhandlung hergestellt, bevor die Medientypen festgelegt werden, und bevor der erste Aufruf von ProcessInput. Der Verbindungsvorgang funktioniert wie folgt:

  1. Das Topologieladeprogramm überprüft beide MFTs auf das Vorhandensein des MFT_ENUM_HARDWARE_URL_Attribute-Attributs. Beachten Sie, dass der Wert dieses Attributs nicht untersucht wird.

  2. Wenn MFT_ENUM_HARDWARE_URL_Attribute für beide MFTs vorhanden ist, führt das Topologieladeprogramm folgende Aktionen aus:

    1. Das Topologieladeprogramm ruft IMFTransform::GetOutputStreamAttributes für den upstream MFT (A) auf. Diese Methode gibt einen IMFAttributes Zeiger zurück. Lassen Sie diesen Zeiger pUpstream-kennzeichnen.
    2. Das 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-kennzeichnen.
    3. Das Topologieladeprogramm legt das MFT_CONNECTED_STREAM_ATTRIBUTE-Attribut für pDownstream- fest, indem IMFAttributes::SetUnknownaufgerufen wird. Der Wert des Attributs ist der pUpstream- Zeiger.
    4. Das Topologieladeprogramm legt das attribut MFT_CONNECTED_TO_HW_STREAM auf TRUE für pDownstream- und pUpstream-fest.
  3. An diesem Punkt weist der nachgeschaltete MFT einen Zeiger auf den Vorlauf-MFT-Attributspeicher auf, wie im folgenden Diagramm dargestellt.

    Diagramm mit jedem Mfts, der auf seinen Datenstrom zeigt, jeder Datenstrom, der auf seinen Speicher zeigt, und der Eingabespeicher mit einer gestrichelten Linie an den Ausgabespeicher

    Anmerkung

    Aus Gründen der Übersichtlichkeit zeigt dieses Diagramm die Datenströme und das Attribut als unterschiedliche Objekte an, die für die Implementierung jedoch nicht erforderlich sind.

     

  4. Der nachgeschaltete MFT verwendet die IMFAttributes Zeiger, um einen privaten Kommunikationskanal mit dem upstream-MFT einzurichten. Da der Kanal privat ist, wird der genaue Mechanismus durch die 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 gemeinsam nutzen. Wenn dies nicht der Fall ist, müssen sie auf die Verwendung des Systemspeichers für den Datentransport zurückgreifen. Dadurch kann MFT ordnungsgemäß mit Software-MFTs und anderen Hardwaregeräten arbeiten.

Wenn der Handshake erfolgreich ist und die beiden MFTs einen privaten Datenkanal teilen, verwenden sie nicht das Standarddatenverarbeitungsmodell (im nächsten Abschnitt beschrieben) am Verbindungspunkt. Insbesondere sendet der nachgeschaltete MFT keine METransformNeedInput--Ereignisse; Weitere Informationen finden Sie im nächsten Abschnitt in diesem Thema.

Datenverarbeitung

Wenn ein Hardware-MFT Systemspeicher für den Datentransport verwendet, funktioniert der Prozess wie folgt:

  1. Um weitere Eingaben anzufordern, sendet MFT ein METransformNeedInput-Ereignis.
  2. Das METransformNeedInput-Ereignis bewirkt, dass die Pipeline IMFTransform::P rocessInputaufruft.
  3. Wenn die MFT Ausgabedaten enthält, sendet die MFT ein METransformHaveOutput-Ereignis.
  4. Das METransformHaveOutput-Ereignis bewirkt, dass die Pipeline IMFTransform::P rocessOutputaufruft.

Weitere Informationen finden Sie unter asynchronen MFTs.

Wenn der MFT jedoch einen Hardwarekanal verwendet, sendet er diese Ereignisse nicht an den Hardwareverbindungspunkt, da die gesamte Datenübertragung intern innerhalb der Hardware erfolgt. Daher ruft die Pipeline ProcessInput- oder ProcessOutput- am Verbindungspunkt nicht auf.

Betrachten Sie beispielsweise das erste Diagramm in diesem Thema. Bei dieser Konfiguration würde die Datenverarbeitung wie folgt erfolgen:

  1. "A" sendet METransformNeedInput-, um Daten anzufordern.
  2. Die Pipeline ruft ProcessInput- für "A" auf.
  3. "A" und "B" verarbeiten die Daten in der Hardware.
  4. Wenn die Verarbeitung abgeschlossen ist, sendet "B" ein METransformHaveOutput Ereignis.
  5. Die Pipeline ruft ProcessOutput- für "B" auf.

Gekoppelter Decoder/Encoder

Wenn sich ein Decoder und Encoder auf demselben Hardwarechip befinden, kann es vorzuziehen sein, sie bei der Transcodierung zusammen zu verwenden. Das heißt, die Auswahl eines sollte dazu führen, dass der 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 attribut MF_MT_MAJOR_TYPE entsprechend auf MFMediaType_Audio oder MFMediaType_Videofest.
  • Legen Sie das attribut MF_MT_SUBTYPE auf einen benutzerdefinierten GUID-Wert fest.

Andere Typattribute sind optional. Der Decoder gibt den benutzerdefinierten Typ aus dem IMFTransform::GetOutputAvailableTypezurück, und der Encoder gibt den benutzerdefinierten Typ aus der 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 angezeigt werden (dwTypeIndex> 0). 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.

Anmerkung

Wenn ein Decoder keine Standardformate zurückgibt, kann er nicht für die Wiedergabe mit dem Enhanced Video Rendererverwendet werden. In diesem Fall sollte sie als transcodegeschützter Decoder registriert werden. Siehe Transcode-Only Decoder.

 

Schreiben eines benutzerdefinierten MFT-

Implementieren eines Codec MFT-

Media Foundation Transforms