Verwenden von IAMVideoAccelerator durch Decoder

Die IAMVideoAccelerator-Schnittstelle ermöglicht generische Videobeschleunigungsvorgänge, einschließlich DirectX Video Acceleration (VA). Für die Beschleunigung von Nicht-DirectX-VRs müssen der Decoder und der Videotreiber ein gemeinsames Protokoll einhalten.

In diesem Abschnitt wird die allgemeine Reihenfolge der Vorgänge beschrieben, die jeder Decoder bei Verwendung dieser Schnittstelle befolgen sollte. Weitere spezifische Informationen zu DirectX VA-basierten Decodern finden Sie unter Zuordnen der DirectX-Videobeschleunigung zu IAMVideoAccelerator.

Hinweis

Diese Schnittstelle ist in Windows 2000 und höher verfügbar.

Die IAMVideoAccelerator-Schnittstelle wird auf dem Eingabepin des Overlay Mixer oder Video Mixing Renderer (VMR) verfügbar gemacht. Die IAMVideoAcceleratorNotify-Schnittstelle wird auf dem Ausgabepin des Decoders verfügbar gemacht. Die Sequenz der Ereignisse zum Verbinden der Filterpins sieht wie folgt aus:

  1. Der Filter Graph Manager ruft IPin::Verbinden auf dem Ausgabepin des Decoderfilters auf. Ein AM _ MEDIA _ TYPE ist ein optionaler Parameter.

    • AM _ MEDIA _ TYPE ist eine Datenstruktur, die einen Medientyp beschreibt. Es enthält eine Haupttyp-GUID (in unserem Fall MEDIATYPE _ Video), eine Untertyp-GUID (in unserem Fall sollte eine Videobeschleunigungs-GUID sein) und eine Vielzahl anderer Dinge. Eine dieser Dinge ist eine Formattyp-GUID, die Informationen zu den Medien enthält, einschließlich der Breite und Höhe eines nicht komprimierten Videobilds, höchstwahrscheinlich in einer MPEG1VIDEOINFO-, VIDEOINFOHEADER-, MPEG2VIDEOINFO-oder VIDEOINFOHEADER2-Struktur.
    • Die AM _ MEDIA _ TYPE-Struktur weist den Decoder an, den angegebenen Medientyp zu verwenden, der "vollständig angegeben" oder "teilweise angegeben" sein kann. Wenn "vollständig angegeben" wäre, würde der Decoder normalerweise einfach versuchen, mit diesem Medientyp zu arbeiten. Wenn "teilweise angegeben", wird versucht, einen "vollständig angegebenen" kompatiblen Betriebsmodus zu finden, mit dem eine Verbindung hergestellt werden kann, die mit dem "teilweise angegebenen" Medientyp konsistent ist.
    • Die übliche Art, einen "vollständig angegebenen" Medientyp zu finden, der für eine Verbindung verwendet werden soll, besteht darin, einfach eine Liste jedes vom Ausgabepin unterstützten "vollständig angegebenen" Medientyps auszuführen, der mit dem "teilweise angegebenen" Medientyp kompatibel ist, und zu versuchen, eine Verbindung mit jedem dieser Medien herzustellen, bis dies erfolgreich war. Der Prozess wäre normalerweise ähnlich, wenn kein AM _ MEDIA _ TYPE im IPin::Verbinden-Aufruf enthalten ist, der Ausgabepin jedoch alle Medientypen überprüfen muss.
  2. Wenn der Decoder überprüfen möchte, ob ein bestimmter AM _ MEDIA _ TYPE (einschließlich einer Videobeschleunigungs-GUID) vom Downstreameingabepin unterstützt wird, kann er IPin::QueryAccept (mit der Videobeschleunigungs-GUID als Untertyp des AM MEDIA _ _ TYPE) aufrufen oder einfach versuchen, eine Verbindung mit diesem Pin herzustellen, wie in Punkt 5 unten beschrieben.

  3. Wenn der Decoder nicht weiß, welche Videobeschleunigungs-GUIDs der Downstreameingabepin unterstützt, und nicht nur eine bestimmte Kandidaten-GUID für den Videobeschleunigungs-Code vorschlagen möchte, indem er die IPin::QueryAcceptdes Downstreameingabepins aufruft, kann der Decoder IAMVideoAccelerator::GetVideoAcceleratorGUIDs aufrufen, um eine Liste der vom Pin unterstützten Videobeschleunigungs-GUIDs abzurufen.

  4. Für einige bestimmte Videobeschleunigungs-GUIDs kann der Decoder den IAMVideoAccelerator::GetUncompFormatsSupported des Downstreameingabepins aufrufen, um eine Liste der DDPIXELFORMAT-Pixelformate abzurufen, die zum Rendern einer bestimmten Videobeschleunigungs-GUID verwendet werden können. Die zurückgegebene Liste sollte als absteigende Präferenzreihenfolge betrachtet werden (d. b. mit dem bevorzugten Format, das zuerst aufgeführt wird).

  5. Der Decoder ruft IPin::ReceiveConnectiondes Downstreameingabepins auf und übergibt ihm einen AM MEDIA _ _ TYPE mit der richtigen Videobeschleunigungs-GUID als Untertyp des Medientyps. Dadurch wird die Verbindung für den Vorgang eingerichtet, einschließlich der Erstellung der unkomprimierten Ausgabeoberflächen (die mithilfe der Breite und Höhe in AM _ MEDIA _ TYPE zugeordnet werden, und der Anzahl der Oberflächen, die durch einen unten beschriebenen Aufruf gefunden werden, und der anderen Informationen, die der Videobeschleunigung zur Verfügung steht und zu diesem Zweck verwenden möchte , z. B. die Videobeschleunigungs-GUID selbst). Wenn der Downstreameingabepin die Videobeschleunigungs-GUID oder einen anderen Aspekt der Verbindung ablehnt, kann dies dazu führen, dass IPin::ReceiveConnection fehlschlägt. Wenn IPin::ReceiveConnection fehlschlägt, wird dies in einem zurückgegebenen HRESULT angegeben, und der Decoder kann versuchen, den Aufruf erneut vorzunehmen, z. B. mit einer neuen Videobeschleunigungs-GUID in der AM MEDIA _ _ TYPE-Struktur.

    • [!Note]

      Dies ist eine weitere Möglichkeit (und die definitivste Methode) für den Decoder, um zu bestimmen, was vom downstream-Eingabepin unterstützt wird– einfach IPin::ReceiveConnection aufrufen und versuchen, eine Verbindung herzustellen, und dann zu überprüfen, ob der Verbindungsversuch erfolgreich war.

    • Während der IPin::ReceiveConnectionruft der Renderer die IAMVideoAcceleratorNotify::GetUncompSurfacesInfodes Decoders auf, übergibt ihm die Videobeschleunigungs-GUID und eine AMVAUncompBufferInfo-Struktur, um herauszufinden, wie viele unkomprimierte Oberflächen zugeordnet werden sollen. Der Decoder füllt die -Struktur aus und gibt diese zurück, die die minimale und maximale Anzahl von Oberflächen enthält, die dem bestimmten Typ zugeordnet werden sollen, und eine DDPIXELFORMAT-Struktur, die das Pixelformat der zuzuweisenden Oberflächen beschreibt.

    • [!Note]

      Im Aufruf von IAMVideoAcceleratorNotify::GetUncompSurfacesInfo wird tatsächlich nichts an den Decoder übergeben, außer an die GUID des Videobeschleunigungs.

  6. Der Renderer ruft den IAMVideoAcceleratorNotify::SetUncompSurfacesInfodes Decoders auf und übergibt die tatsächliche Anzahl der zugeordneten nicht komprimierten Oberflächen an den Decoder.

  7. Der Renderer ruft IAMVideoAcceleratorNotify::GetCreateVideoAcceleratorData des Decoders auf, um alle Daten abzurufen, die zum Initialisieren der Videobeschleunigung erforderlich sind.

  8. Der Decoder ruft IAMVideoAccelerator::GetCompBufferInfoauf und übergibt ihm eine Videobeschleunigungs-GUID, eine AMVAUncompDataInfo-Struktur und die Anzahl der komprimierten Puffertypen, um eine Reihe von AMVACompBufferInfo-Datenstrukturen zurückzugeben, die den einzelnen Typen komprimierter Datenpuffer entsprechen, die von der Videobeschleunigungs-GUID verwendet werden.

    • Die AMVAUncompDataInfo-Struktur enthält die Breite und Höhe der decodierten unkomprimierten Daten (in Pixel) und das DDPIXELFORMAT des nicht komprimierten Bilds.
    • Die zurückgegebenen AMVACompBufferInfo-Datenstrukturen enthalten Folgendes:
      • Die Anzahl der komprimierten Puffer, die für den jeweiligen Typ benötigt werden.

      • Die Breite und Höhe der zu erstellenden Oberfläche (Felder, die möglicherweise eine tatsächliche Bedeutung haben).

        Hinweis

        Der DirectDraw-Oberflächenzuordnungsvorgang für die komprimierten Puffer stellt derzeit nicht bereit, dass die Breite oder Höhe dieser Oberflächen größer oder gleich 2^15 ist, obwohl der Aufruf der Oberflächenzuordnung möglicherweise nicht übermäßig fehlschlägt, wenn dieser Grenzwert verletzt wird. Daher könnte der Treiber seine Anforderungen für komprimierten Pufferspeicher strukturieren, um so extreme Größen zu vermeiden. Anstatt beispielsweise einen Puffer mit width="1" und height="65536" anzufordern, sollte der Treiber einen Puffer von width="1024" und height="64" anfordern.

      • Die Gesamtanzahl von Bytes, die von der Oberfläche verwendet werden sollen.

      • Eine Struktur vom Typ DDSCAPS2, die ein DirectDrawSurface-Objekt definiert und die Funktionen zum Erstellen von Oberflächen zum Speichern komprimierter Daten beschreibt.

      • Ein DDPIXELFORMAT, das das Pixelformat beschreibt, das zum Erstellen von Oberflächen zum Speichern komprimierter Daten verwendet wird (ein Feld, das möglicherweise eine tatsächliche Bedeutung hat oder nicht).

Hinweis

Die Aufrufe des Renderers an einige der IAMVideoAcceleratorNotify-Schnittstellenmethoden des Decoders können (und würden normalerweise) innerhalb des Aufrufs des IPin::ReceiveConnectiondes Decoders auftreten. Dies gilt insbesondere für Folgendes:

Hinweis

Zur Unterstützung dynamischer Formatänderungen kann der Decoder auch IPin::ReceiveConnection und andere Methoden pro oben aufrufen, während die Filter verbunden sind und ausgeführt werden. Diese Funktion wird bereitgestellt, um dynamische Formatänderungen zu unterstützen (wenn auch nicht in H.263, Anhang P, sinn, da alle Datensätze von Grund auf neu gestartet werden und alle Informationen zum Referenzbild daher verloren gehen).

Im Folgenden wird die Verwendung von IAMVideoAccelerator während des Vorgangs nach der Initialisierung beschrieben:

  1. Für jede nicht komprimierte Oberfläche ruft der Decoder IAMVideoAccelerator::BeginFrame auf, um mit der Verarbeitung zum Erstellen des Ausgabebilds zu beginnen. Wenn dies geschieht, sendet der Decoder eine AMVABeginFrameInfo-Struktur.

    • Die AMVABeginFrameInfo-Struktur enthält einen Index für einen Zielpuffer, einen Zeiger auf einige Daten, die nachgeschaltet werden sollen, und einen Zeiger auf einen Ort, an den der Accelerator einige Daten für den Decoder zum Lesen platzieren kann.

    • HINWEIS 1: Die Zugriffstaste empfängt den Zielpufferindex nicht, da er vom Renderer vor dem Downstream übersetzt wird.

    • HINWEIS 2: IAMVideoAccelerator::BeginFrame kann zwischen Aufrufen von IAMVideoAccelerator::EndFramemehrfach aufgerufen werden.

    • HINWEIS 3: Es gibt keine Annahme innerhalb des Schnittstellenvorgangs, dass IAMVideoAccelerator::BeginFrame und IAMVideoAccelerator::EndFrame für die Verarbeitung jedes einzelnen Bilds im Bitstream aufgerufen werden müssen.

      IAMVideoAccelerator::BeginFrame erstellt im Hinblick auf die Schnittstelle eine Zuordnung innerhalb des Renderers zwischen einem Index und einer nicht komprimierten Oberfläche. Es bietet auch eine Möglichkeit, eine bestimmte Funktion in einem Gerätetreiber aufzurufen (mit Unterstützung einer Möglichkeit, beliebige Daten zwischen dem Decoder und dem Gerätetreiber hin und her zu übergeben).

      (Im DirectX-Va-Vorgang ist jedoch eine unten beschriebene Anforderung vorhanden, dass IAMVideoAccelerator::BeginFrame und IAMVideoAccelerator::EndFrame für die Verarbeitung jedes einzelnen Bilds im Bitstream aufgerufen werden müssen.)

  2. Zum Senden nicht komprimierter Daten an die Zugriffstaste ruft der Decoder Folgendes auf:

    • IAMVideoAccelerator::QueryRenderStatus, um zu bestimmen, ob ein Puffer zum Lesen aus oder schreiben in sicher ist.
    • IAMVideoAccelerator::GetBuffer zum Sperren und Abrufen des Zugriffs auf einen angegebenen Puffer (wenn dieser zuvor nicht aufgerufen wurde, um diesen Zugriff zu erhalten). GetBuffer kann auch verwendet werden, um eine Kopie des Inhalts des letzten nicht komprimierten Ausgabebilds abzurufen, für das IAMVideoAccelerator::BeginFrame aufgerufen wurde, vorausgesetzt, IAMVideoAccelerator::EndFrame wurde für diesen Zielpufferindex nicht aufgerufen. Wenn die DDI den Renderstatus DDERR _ WASBATDRAWING für den angeforderten Puffer zurückgibt, wird eine Standbyschleife in GetBuffer betrieben, bis diese Bedingung gelöscht wird. Um GetBuffer aufzurufen, benötigt der Decoder einige Informationen aus einer AMVACompBufferInfo-Datenstruktur, die durch Aufrufen von IAMVideoAccelerator::GetCompBufferInfoabgerufen wird.
    • IAMVideoAccelerator::Execute, um anzugeben, dass die Daten in einem Satz komprimierter Puffer, wie in einem Array von AMVABUFFERINFO-Datenstrukturen angegeben, verarbeitet werden sollen. In diesem Aufruf wird der Funktionscode dwFunction an den Treiber übergeben. Ein lpPrivateInputData-Zeiger wird auch an einige Daten übergeben, um downstream zu senden, und ein lpPrivateOutputData-Zeiger wird an eine Stelle übergeben, an der der Downstreamprozess einige Daten zum Lesen des Decoders platzieren kann.
    • IAMVideoAccelerator::ReleaseBuffer, um anzugeben, dass der Decoder die Verwendung eines angegebenen Puffers für den Moment abgeschlossen hat und keinen gesperrten Zugriff mehr auf den Puffer benötigt. (Wenn der Decoder den Puffer weiterhin verwenden möchte, kann er IAMVideoAccelerator::ReleaseBuffer für den Moment einfach nicht aufrufen, wodurch vermieden wird, dass IAMVideoAccelerator::GetBuffer aufgerufen werden muss, bis der Puffer wirklich nicht mehr verwendet werden soll.) Der Decoder sollte nach dem Aufruf von Execute erst in den Puffer schreiben, wenn QueryRenderStatus angibt, dass der Puffer schreibsicher ist.
  3. Um die Ausgabeverarbeitung für einen Zielpuffer abzuschließen, ruft der Decoder IAMVideoAccelerator::EndFrameauf. Mit diesem Aufruf können beliebige Daten nachgeschaltet werden. Dies ist im Wesentlichen das Ergebnis dieses Aufrufs. Er sendet in diesem Aufruf keinen Zielpufferindex, sodass er der Zugriffstaste nicht genau angeben kann, welcher Zielpuffer abgeschlossen ist, es sei denn, diese Angabe ist in den willkürlich übergebenen Daten enthalten.

  4. Um einen Frame anzuzeigen, ruft der Decoder IAMVideoAccelerator::D isplayFrame mit dem Anzuzeigenden Index des Frames und einer IMediaSample-Struktur mit Start- und Stoppzeitstempeln und relevanten Flags wie dwTypeSpecificFlags in der AM _ SAMPLE2 _ PROPERTIES-Struktur und dwInterlaceFlags in der VIDEOINFOHEADER2-Struktur auf. Der Decoder muss überprüfen, ob alle Dekomprimierungsvorgänge, die sich auf den Inhalt des Frames auswirken, abgeschlossen wurden, bevor DisplayFrame aufgerufen wird.

  5. Schließlich sollte der Decoder nach Abschluss der gesamten Verarbeitung den Abschluss aller verbleibenden begonnenen Ausgabeframes durch Aufrufen von IAMVideoAccelerator::EndFrame angeben und alle seine gesperrten Puffer freigeben, indem IAMVideoAccelerator::ReleaseBuffer für jeden nicht freigegebenen Puffer aufgerufen wird.

Decoderschnittstellen und Spezifikationen