Filterzustände

[Das dieser Seite zugeordnete Feature DirectShow-ist ein Legacyfeature. Es wurde von MediaPlayer, IMFMediaEngineund Audio/Video Capture in Media Foundationersetzt. Diese Features wurden für Windows 10 und Windows 11 optimiert. Microsoft empfiehlt dringend, dass neuer Code MediaPlayer-, IMFMediaEngine und Audio-/Videoaufnahme in Media Foundation anstelle von DirectShow-verwendet, wenn möglich. Microsoft schlägt vor, dass vorhandener Code, der die Legacy-APIs verwendet, um die neuen APIs zu verwenden, falls möglich umgeschrieben werden.]

Filter weisen drei mögliche Zustände auf: beendet, angehalten und ausgeführt. Der Zweck des angehaltenen Zustands besteht darin, Daten im Diagramm anzuzeigen, sodass ein Ausführungsbefehl sofort reagiert. Der Filter Graph-Manager steuert alle Zustandsübergänge. Wenn eine Anwendung IMediaControl::Run, IMediaControl::P auseoder IMediaControl::Stopaufruft der Filter Graph Manager die entsprechende IMediaFilter Methode für alle Filter. Übergänge zwischen angehaltener und ausgeführter Ausführung durchlaufen immer den angehaltenen Zustand. Wenn die Anwendung also Ausführen auf einem beendeten Diagramm aufruft, hält der Filter Graph-Manager das Diagramm an, bevor es ausgeführt wird.

Für die meisten Filter sind die ausgeführten und angehaltenen Zustände identisch. Betrachten Sie das folgende Filterdiagramm:

Quell-> Transformieren > Renderer

Angenommen, der Quellfilter ist keine Liveaufnahmequelle. Wenn der Quellfilter angehalten wird, wird ein Thread erstellt, der neue Daten generiert und so schnell wie möglich in Medienbeispiele schreibt. Der Thread "pusht" die Beispiele nach unten, indem IMemInputPin::Receive für den Eingabenadel des Transformationsfilters aufgerufen wird. Der Transformationsfilter empfängt die Beispiele im Thread des Quellfilters. Es kann einen Workerthread verwenden, um die Beispiele an den Renderer zu übermitteln, aber in der Regel liefert er sie im selben Thread. Während der Renderer angehalten wird, wartet er auf den Empfang eines Beispiels. Nachdem es eine erhalten hat, blockiert und hält es auf unbestimmte Zeit. Wenn es sich um einen Videorenderer handelt, wird das Beispiel als Posterbild angezeigt, wobei das Bild bei Bedarf aktualisiert wird.

An diesem Punkt ist der Datenstrom vollständig angehalten und bereit für das Rendern. Wenn das Diagramm angehalten bleibt, werden Beispiele im Diagramm hinter dem ersten Beispiel "stapeln", bis jeder Filter in Empfangen oder IMemAllocator::GetBufferblockiert wird. Es geht jedoch keine Daten verloren. Sobald die Blockierung des Quellthreads aufgehoben wurde, wird er einfach an dem Punkt fortgesetzt, an dem er blockiert wurde.

Der Quellfilter und der Transformationsfilter ignorieren den Übergang von angehalten in die Ausführung – sie verarbeiten einfach so schnell wie möglich Daten. Wenn der Renderer jedoch ausgeführt wird, beginnt er mit dem Rendern von Beispielen. Zuerst wird das Beispiel gerendert, das beim Anhalten gehalten wurde. Jedes Mal, wenn es ein neues Beispiel empfängt, wird die Präsentationszeit des Beispiels berechnet. (Ausführliche Informationen finden Sie unter Uhrzeit und Uhrzeiten in DirectShow.) Der Renderer enthält jedes Beispiel bis zur Präsentationszeit, zu dem zeitpunkt, an dem es das Beispiel rendert. Während sie auf die Präsentationszeit wartet, blockiert sie entweder die Receive-Methode oder empfängt neue Beispiele in einem Arbeitsthread mit einer Warteschlange. Filter vor dem Renderer sind nicht an der Planung beteiligt.

Livequellen, z. B. Aufnahmegeräte, sind eine Ausnahme von dieser allgemeinen Architektur. Bei einer Live-Quelle ist es nicht geeignet, daten im Voraus zu markieren. Die Anwendung kann das Diagramm anhalten und dann lange warten, bevor sie ausgeführt wird. Das Diagramm sollte keine veralteten Beispiele rendern. Daher erzeugt eine Livequelle keine Beispiele, während sie angehalten werden, nur während der Ausführung. Um diese Tatsache an den Filterdiagramm-Manager zu signalisieren, gibt die IMediaFilter::GetState-Methode des Quellfilters VFW_S_CANT_CUE zurück. Dieser Rückgabecode gibt an, dass der Filter in den angehaltenen Zustand gewechselt ist, obwohl der Renderer keine Daten empfangen hat.

Wenn ein Filter beendet wird, werden alle weiteren Proben abgelehnt, die an ihn übermittelt werden. Quellfilter beenden ihre Streamingthreads, und andere Filter beenden alle Arbeitsthreads, die sie möglicherweise erstellt haben. Pins dekommitieren ihre Allokatoren.

Zustandsübergänge

Der Filter Graph-Manager führt alle Zustandsübergänge in vorgelagerter Reihenfolge aus, beginnend vom Renderer und rückwärts zum Quellfilter. Diese Sortierung ist erforderlich, um zu verhindern, dass Stichproben verworfen werden, und um zu verhindern, dass das Diagramm deadlocking. Die wichtigsten Zustandsübergänge liegen zwischen angehalten und angehalten:

• Angehalten: Während jeder Filter angehalten wird, wird er bereit, Beispiele vom nächsten Filter zu empfangen. Der Quellfilter ist der letzte, der angehalten werden soll. Er erstellt den Streamingthread und beginnt mit der Bereitstellung von Beispielen. Da alle nachgeschalteten Filter angehalten werden, lehnt kein Filter Proben ab. Der Filter Graph-Manager schließt den Übergang erst ab, wenn jeder Renderer im Diagramm ein Beispiel erhalten hat (mit Ausnahme von Livequellen, wie zuvor beschrieben).
• Angehalten angehalten: Wenn ein Filter beendet wird, gibt er alle darin enthaltenen Beispiele frei, wodurch alle upstream-Filter aufgehoben werden, die in GetBuffer-warten. Wenn der Filter auf eine Ressource innerhalb der Receive-Methode wartet, wartet er nicht mehr und gibt von Receivezurück, wodurch die Blockierung des aufrufenden Filters aufgehoben wird. Wenn der Filter Graph-Manager den nächsten upstream-Filter beendet, wird dieser Filter nicht in GetBuffer- oder Empfangenblockiert und kann auf den Stoppbefehl reagieren. Der Upstreamfilter liefert möglicherweise einige zusätzliche Beispiele, bevor er den Stoppbefehl erhält, aber der nachgeschaltete Filter lehnt sie einfach ab, da er bereits beendet wurde.

Verwandte Themen

Datenfluss im Filterdiagramm-