DirectX VideoBeschleunigung IAMVideoAccelerator Operational Specification
[Das dieser Seite zugeordnete Feature DirectShow ist ein Legacyfeature. Es wurde durch MediaPlayer, IMFMediaEngine und Audio/Video Capture in Media Foundation ersetzt. Diese Features wurden für Windows 10 und Windows 11 optimiert. Microsoft empfiehlt dringend, dass neuer Code nach Möglichkeit MediaPlayer, IMFMediaEngine und Audio/Video Capture in Media Foundation anstelle von DirectShow verwendet. Microsoft schlägt vor, vorhandenen Code, der die Legacy-APIs verwendet, um nach Möglichkeit die neuen APIs zu verwenden.]
Der genaue Vorgangsmechanismus lautet wie folgt:
Jedes hier definierte Profil im eingeschränkten Modus verfügt über eine zugeordnete DirectX VA-GUID, die von den IPin::QueryAccept - und IPin::ReceiveConnection-Pins unterstützt und in IAMVideoAccelerator::GetVideoAcceleratorGUIDs aufgeführt werden kann.
Auf ähnliche Weise muss jeder Verschlüsselungsprotokolltyp für die Verwendung mit DirectX VA über einen zugeordneten Verschlüsselungsprotokolltyp GUID verfügen, der von den IPin::QueryAccept - und IPin::ReceiveConnection-Pins unterstützt und in IAMVideoAccelerator::GetVideoAcceleratorGUIDs aufgeführt wird. Die GUID "keine Verschlüsselung" DXVA_NoEncrypt darf in dieser Liste nicht gesendet werden, da unterstützung dafür erforderlich und daher implizit ist.
Nach dem Aufrufen von IPin::ReceiveConnection , um eine Verbindung mit dem Downstreameingabepin herzustellen, gibt der IAMVideoAcceleratorNotify::GetCreateVideoAcceleratorData des Decoders einen Zeiger auf eine DXVA_ConnectMode Datenstruktur zurück, die die Verbindungsmodusinformationen für die Verbindung enthält. IAMVideoAccelerator::GetCompBufferInfo wird mit *pdwNumTypesCompBuffers = 16 aufgerufen und gibt komprimierte Pufferinformationen basierend auf der Konvention zurück, dass die Typnummer jedes Puffers (wie in Abschnitt 3.4 der DirectX VA-Spezifikation definiert) direkt als nullbasierter Index in das Array der zurückgegebenen AMVACompBufferInfo-Datenstrukturen verwendet werden kann. Dies erfordert, dass der Acceleratortreiber für alle Puffertypen, die nicht verwendet werden (einschließlich Puffertyp 0, da es keine definierte Verwendung dieses Puffertyps gibt) AMVACompBufferInfo-Datenstrukturen mit einer Form von "dummy"-Parameterwerten bereitstellt (z. B. dwNumCompBuffers=0, dwWidthToCreate=0, dwHeightToCreate=0 und dwBytesToAllocate=0).
DXVA-Funktionsanzeigen und zugehörige Datenpuffer werden mithilfe von IAMVideoAccelerator::Execute gesendet. Die DXVA-Funktion wird im dwFunction-Parameter des Aufrufs angegeben. Die einzigen DXVA-Funktionen, die für die Initialisierung relevant sind, sind DXVA_ConfigQueryOrReplyFunc und DXVA_EncryptProtocolFunc.
Wenn dwFunction einen DXVA_ConfigQueryOrReplyFunc enthält, zeigt der lpPrivateInputData-Zeiger zum Übergeben von Daten an den Accelerator in diesem Aufruf auf eine Konfigurationsdatenstruktur, der lpPrivateOutputData-Zeiger zum Empfangen von Informationen aus dem Accelerator auf einen Bereich, in dem eine alternative oder doppelte Konfigurationsdatenstruktur platziert werden kann. Der pamvaBufferInfo-Zeiger für ein Array von AMVABUFFERINFO muss NULL sein. und dwNumBuffers müssen null sein. Das zurückgegebene HRESULT enthält den S_OK- oder S_FALSE-Hinweis oder E_FAIL oder E_INVALIDARG oder eine andere Fehleranzeige HRESULT im Falle eines schwerwiegenden Problems bei der Protokollausführung (z. B. einen ungültigen Konfigurationsparameter). Alle Aufrufe von IAMVideoAccelerator::Execute für alle Verwendungen von DXVA_ConfigQueryOrReplyFunc müssen allen anderen Aufrufen von IAMVideoAccelerator::Execute vorangestellt werden.
Wenn dwFunction eine DXVA_EncryptProtocolFunc enthält, verweist der lpPrivateInputData-Zeiger zum Übergeben von Daten an den Accelerator in diesem Aufruf auf eine Datenstruktur des Verschlüsselungsprotokolls, die mit DXVA_EncryptProtocolHeader beginnt. Der lpPrivateOutputData-Zeiger zum Empfangen von Informationen vom Accelerator verweist auf einen Bereich, in dem die vom Verschlüsselungsprotokoll zurückgegebenen Daten (z. B. ein Zertifikat) (der mit DXVA_EncryptProtocolHeader beginnt) platziert werden können. der pamvaBufferInfo-Zeiger für ein Array von AMVABUFFERINFO muss NULL und dwNumBuffers null sein. Das zurückgegebene HRESULT enthält S_OK, solange das Verschlüsselungsprotokoll normal funktioniert und im Falle eines schwerwiegenden Problems bei der Protokollausführung E_FAIL oder E_INVALIDARG oder eine andere Fehleranzeige enthält.
Nach der Initialisierung des Vorgangs in der oben genannten Weise verläuft der tatsächliche Betrieb des Decoders wie folgt:
IAMVideoAccelerator::BeginFrame muss aufgerufen werden, bevor bDXVA_Func mit komprimierten Pufferparametern gesendet werden, die Schreibvorgänge auf eine nicht komprimierte Zieloberfläche verursachen. Der Zweck von IAMVideoAccelerator::BeginFrame in DirectX VA besteht darin, Zieloberflächen Indexwerten zuzuordnen und den Videobeschleunigertreiber über die Absicht zu benachrichtigen, Schreibvorgänge für eine Oberfläche zu initiieren, damit der Treiber mit einer Angabe reagieren kann, ob die Oberfläche zum Überschreiben bereit ist. Die in IAMVideoAccelerator::BeginFrame übergebene AMVABeginFrame-Struktur muss einen pInputData-Zeiger auf einen einzelnen WORD wBeginPictureIndex-Parameter enthalten, der dem an IAMVideoAccelerator::BeginFrame übergebenen Frameindex entspricht (und dwSizeInputData muss 2 sein). Dies ist der Index, der in einem komprimierten Puffer verwendet werden soll, um einen Schreibvorgang auf die Oberfläche zu befehlen (z. B. als wDecodedPictureIndex, wDeblockedPictureIndex, wBlendedDestinationIndex oder wPicResampleDestPicIndex). Jeder Aufruf von IAMVideoAccelerator::BeginFrame muss mit einem entsprechenden Aufruf von IAMVideoAccelerator::EndFrame gekoppelt werden, wie unten beschrieben. Wenn beispielsweise ein komprimiertes Bild decodiert und dann alphaniert werden soll, indem Front-End-Puffer-zu-Puffer-Blending mit einem Grafikbild kombiniert wird, würde es einen Aufruf von IAMVideoAccelerator::BeginFrame geben, bevor das komprimierte Bild in eine in wDecodedPictureIndex angegebene Oberfläche decodiert wird, und dann ein Aufruf von IAMVideoAccelerator::EndFrame nach Übergabe aller komprimierten Puffer, die zum Decodieren des Bilds verwendet werden, dann ein zweiter Aufruf von IAMVideoAccelerator::BeginFrame vor dem Befehl der Alpha-Blending-Kombination der Grafikquelle mit dem decodierten Bild in einer in wBlendedDestinationIndex angegebenen Oberfläche, und dann ein zweiter Aufruf von IAMVideoAccelerator::EndFrame nach dem Alphamischungskombinationsvorgang. Der Zeiger pOutputData in AMVABeginFrameInfo muss NULL sein (und dwSizeOutputData ist "0"). Das HRESULT, das von IAMVideoAccelerator::BeginFrame zurückgegeben wird, lautet:
- S_OK, wenn die nicht komprimierte Oberfläche verfügbar und einsatzbereit ist.
- E_PENDING, wenn die nicht komprimierte Oberfläche noch nicht zur Verwendung verfügbar ist, aber bald verfügbar sein wird (wenn die unkomprimierte Oberfläche für die Anzeige gelesen wird und die Lese-/Anzeige der Oberfläche noch nicht abgeschlossen ist).
- E_FAIL oder E_INVALIDARG eine andere Fehleranzeige nur dann, wenn ein Datenformat- oder Protokollfehler erkannt wird (z. B. ein falscher Wert von dwSizeInputData oder ein pOutputData-Wert ohne NULL ).
DXVA-Funktionsanzeigen und zugehörige Datenpuffer werden mithilfe von IAMVideoAccelerator::Execute gesendet. Im selben Aufruf von IAMVideoAccelerator::Execute kann mehrere bDXVA_Func Wert angegeben werden. Die bDXVA_Func Werte müssen in den dwFunction-Parameter des Aufrufs gepackt werden, wobei der erste Funktionsbefehl in den acht MSBs, der nächste Befehl in den nächsten acht Bits usw. mit allen verbleibenden Bits mit Nullen gefüllt ist. Der für bDXVA_Func 0xFF Wert gibt an, dass die bDXVA_Func auf zwei oder vier Bytes erweitert wird. Wenn das zweite Byte ebenfalls 0xFF ist, bedeutet dies, dass bDXVA_Func auf vier Bytes erweitert wird. Wenn die oberen vier Bits des dritten Byte 0xF oder 0x0 sind, gibt dies an, dass bDXVA_Func einen DXVA_ConfigQueryOrReplyFunc oder DXVA_EncryptProtocolFunc enthält. Befehle mit mehreren Byte dürfen keine Fortsetzung über das Ende von dwFunction anzeigen. Der Decoder muss darauf achten, dass zwischen verschiedenen bDXVA_Func Werten, die im gleichen Aufruf von IAMVideoAccelerator::Execute angegeben sind, keine sequenziellen Abhängigkeiten vorhanden sind und dass alle potenziellen Racebedingungen (z. B. zwischen Bilddecodierung und Unterbildvermischung, zwischen Unterbildladen und Unterbildvermischung usw.) durch entsprechende Aufrufe von IAMVideoAccelerator verhindert werden: BeginFrame und IAMVideoAccelerator::QueryRenderStatus vor nachfolgenden Aufrufen von IAMVideoAccelerator::Execute.
Wenn dwFunction einen DXVA_ConfigQueryOrReplyFunc enthält, zeigt der lpPrivateInputData-Zeiger zum Übergeben von Daten an den Accelerator in diesem Aufruf auf eine Konfigurationsdatenstruktur, der lpPrivateOutputData-Zeiger zum Empfangen von Informationen aus dem Accelerator auf einen Bereich, in dem eine alternative oder doppelte Konfigurationsdatenstruktur platziert werden kann. Der pamvaBufferInfo-Zeiger für ein Array von AMVABUFFERINFO muss NULL sein. und dwNumBuffers müssen null sein. Das zurückgegebene HRESULT enthält die S_OK oder S_FALSE Angabe als Reaktion auf die Abfrage oder E_FAIL oder E_INVALIDARG eine andere Fehleranzeige HRESULT im Falle eines schwerwiegenden Problems bei der Protokollausführung (z. B. einen invalid.configuration-Parameter). Alle Aufrufe von IAMVideoAccelerator::Execute für alle Verwendungen von DXVA_ConfigQueryOrReplyFunc müssen allen anderen Aufrufen von IAMVideoAccelerator::Execute vorangestellt werden.
Wenn dwFunction eine DXVA_EncryptProtocolFunc enthält, verweist der lpPrivateInputData-Zeiger zum Übergeben von Daten an den Accelerator in diesem Aufruf auf eine Datenstruktur des Verschlüsselungsprotokolls, die mit DXVA_EncryptProtocolHeader beginnt. Der lpPrivateOutputData-Zeiger zum Empfangen von Informationen vom Accelerator verweist auf einen Bereich, in dem die vom Verschlüsselungsprotokoll zurückgegebenen Daten (z. B. ein Zertifikat) (der mit DXVA_EncryptProtocolHeader beginnt) platziert werden können. der pamvaBufferInfo-Zeiger für ein Array von AMVABUFFERINFO muss NULL und dwNumBuffers null sein. Das zurückgegebene HRESULT enthält S_OK, solange das Verschlüsselungsprotokoll normal funktioniert und im Falle eines schwerwiegenden Problems bei der Protokollausführung E_FAIL oder E_INVALIDARG oder eine andere Fehleranzeige enthält.
Wenn dwFunction keine DXVA_ConfigQueryOrReplyFunc oder DXVA_EncryptProtocolFunc enthält, verweist der lpPrivateInputData-Zeiger zum Übergeben von Daten an den Accelerator auf eine Pufferbeschreibungsliste. Die ersten vier Einträge in der Pufferbeschreibungslistenstruktur für jeden Puffer (dwTypeIndex, dwBufferIndex, dwDataOffset und dwDataSize) müssen gleich denen in der AMVABUFFERINFO-Datenstruktur für denselben Puffer sein. Wenn bDXVA_Func gleich "1" in dwFunction und bPicReadbackRequests "1" angegeben ist, der lpPrivateOutputData-Zeiger zum Empfangen von Informationen vom Accelerator muss auf einen Bereich des persistenten Arbeitsspeichers (z. B. Heap) verweisen, der mit lesegeschützten Makroblockdaten aus dem Accelerator gefüllt werden soll (diese Daten werden erst dann garantiert vorhanden, wenn IAMVideoAccelerator::QueryRenderStatus zum Schreiben in denselben Bildparameterpuffer S_OK wie in Punkt 10 unten beschrieben). Andernfalls muss der lpPrivateOutputData-Zeiger für den Empfang von Informationen vom Accelerator auf einen einzelnen DWORD zeigen, der auf einen der folgenden Anzeigewerte festgelegt wird (besonders nützlich für die Meldung von Bitstreamfehlern im VLD-Off-Host-Vorgang).
Wert BESCHREIBUNG 0 Ausführung OK. 1 Kleineres Problem im Datenformat. 2 Ein erhebliches Problem im Datenformat. 3 Schwerwiegendes Problem im Datenformat. 4 Ein weiteres schwerwiegendes Problem. Wenn ein "schwerwiegendes" Problem angezeigt wird, sollte der Softwaredecoder die Funktion(en) nicht mehr betreiben, es sei denn, es können Korrekturmaßnahmen ergriffen werden. Diese vom Accelerator zurückgegebenen Daten dürfen erst vom Host gelesen werden, nachdem das Pufferrendering für das Bild abgeschlossen ist, wie von IAMVideoAccelerator::QueryRenderStatus getestet werden kann. Das zurückgegebene HRESULT enthält S_OK, solange der Schnittstellenvorgang normal funktioniert und im Falle eines schwerwiegenden Problems möglicherweise E_FAIL oder E_INVALIDARG oder eine andere Fehleranzeige zurückgibt.
Der Bilddecodierungsparameterpuffer muss zu den ersten Puffern gehören, die für die Decodierung jedes Bilds gesendet werden, wenn IAMVideoAccelerator::Execute mit bDXVA_Func gleich "1" ist, und alle Puffer zum Decodieren eines Bilds in einem Bitstrom müssen vor allen Puffern zum Decodieren nachfolgender Bilder gesendet werden. Wenn ein Makroblock-Steuerungsbefehlpuffer gesendet wird, muss ein entsprechender Datenpuffer für die Restdifferenz (mit Daten für dieselben Makroblocks) mit demselben IAMVideoAccelerator::Execute-Aufruf gesendet werden.
IAMVideoAccelerator::EndFrame wird aufgerufen, nachdem alle komprimierten Puffer gesendet wurden, die die Erstellung des Ausgabeinhalts auf einer angegebenen nicht komprimierten Oberfläche verursachen (ein Ergebnis von Vorgängen, die für wDecodedPictureIndex, wDeblockedPictureIndex, wBlendedDestinationIndex oder wPicResampleDestPicIndex angegeben sind). Der Zweck dieses Aufrufs von IAMVideoAccelerator::EndFrame besteht darin, die Videobeschleunigerhardware zu benachrichtigen, dass alle für den angegebenen Vorgang erforderlichen Daten gesendet wurden. Der Zeiger auf Daten, die über IAMVideoAccelerator::EndFrame gesendet werden sollen, zeigt auf einen einzelnen WORD wEndPictureIndex, der den Index des abschließenden Frames enthält. Dieser Parameter muss mit dem wBeginPictureIndex-Wert übereinstimmen, der im vorherigen Aufruf von IAMVideoAccelerator::BeginFrame vor dem Senden der relevanten komprimierten Puffer angegeben wurde. Nach einem Aufruf von IAMVideoAccelerator::EndFrame, die unkomprimierte Oberfläche mit dem Index wEndPictureIndex darf erst nach einem weiteren Aufruf von IAMVideoAccelerator::BeginFrame ausgegeben werden, um anzukündigen, dass dies geschieht und ein S_OK zurückgegeben wurde. Dieser Zieloberflächenindex kann jedoch in nachfolgenden Lesezugriffsbefehlen wie wForwardRefPictureIndex, wBackwardRefPictureIndex, wPicResampleSourcePicIndex oder bRefPicSelect[i] auftreten. Das von IAMVideoAccelerator:EndFrame zurückgegebene HRESULT muss S_OK werden, es sei denn, es liegt ein Datenformat- oder Protokollfehler vor, in diesem Fall kann es sich um E_FAIL oder E_INVALIDARG oder eine andere Fehleranzeige sein.
Bei der feldbasierten Decodierung (z. B. in MPEG-2-Bitstreams) gibt es keine 1:1-Zuordnung von Funktionsbildern im Bitstream zu nicht komprimierten Oberflächen in der Beschleunigerschnittstelle. Beim Decodieren von Feldbildern in einem MPEG-2-Bitstrom werden zwei "Bilder" decodiert, um eine vollständige unkomprimierte Ausgabeoberfläche zu erzeugen. In der Definition der DirectX-VA-Schnittstelle entspricht jeder Frame jeder Verwendung von wDecodedPictureIndex, wDeblockedPictureIndex, wBlendedDestinationIndex oder wPicResampleDestPicIndex. Daher sind zwei Aufrufpaare von IAMVideoAccelerator::BeginFrame und IAMVideoAccelerator::EndFrame für die Decodierung von Feldbildern in nicht komprimierte Ausgabeoberflächen erforderlich.
Ein Aufruf von IAMVideoAccelerator::QueryRenderStatus mit dwFlags gleich 0, der irgendwann nach einem Aufruf von IAMVideoAccelerator::EndFrame mit einem bestimmten wEndPictureIndex erfolgt und die status eines gesendeten Puffers überprüft, der den wEndPictureIndex in wDecodedPictureIndex enthielt. wDeblockedPictureIndex, wBlendedDestinationIndex oder wPicResampleDestPicIndex geben eine S_OK Angabe zurück, wenn alle Vorgänge zum Schreiben der Daten in die unkomprimierte Oberfläche wurde abgeschlossen und gibt E_PENDING zurück, wenn der Vorgang noch nicht abgeschlossen ist. E_FAIL oder E_INVALIDARG oder eine andere Fehleranzeige kann im Falle eines Protokollfehlers zurückgegeben werden.
Zugehörige Themen