Spülung

  • Artikel

[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.]

Während das Filterdiagramm ausgeführt wird, können sich beliebige Datenmengen durch das Diagramm bewegen. Einige davon befinden sich möglicherweise in Warteschlangen und warten darauf, geliefert zu werden. Es gibt Zeiten, in denen das Filterdiagramm diese ausstehenden Daten so schnell wie möglich entfernen und durch neue Daten ersetzen muss. Nach einem Suchbefehl generiert der Quellfilter beispielsweise Beispiele von einer neuen Position in der Quelle. Um die Latenz zu minimieren, sollten nachgeschaltete Filter alle Beispiele verwerfen, die vor dem Befehl seek erstellt wurden. Der Vorgang des Verwerfens von Beispielen wird als Flushing bezeichnet. Dadurch kann das Diagramm reaktionsfähiger sein, wenn Ereignisse den normalen Datenfluss ändern.

Das Leeren wird vom Pullmodell etwas anders behandelt als das Pushmodell. In diesem Artikel wird zunächst das Pushmodell beschrieben. anschließend werden die Unterschiede im Pullmodell beschrieben.

Das Leeren erfolgt in zwei Phasen.

  • Zunächst ruft der Quellfilter IPin::BeginFlush auf dem Eingabenadel des Downstreamfilters auf. Der Downstreamfilter beginnt mit der Ablehnung von Beispielen aus Upstream. Außerdem verwirft es alle darin gespeicherten Beispiele und sendet den BeginFlush-Aufruf nachgeschaltet an den nächsten Filter.
  • Wenn der Quellfilter zum Senden neuer Daten bereit ist, ruft er IPin::EndFlush am Eingabenadel auf. Dadurch wird dem nachgeschalteten Filter signalisiert, dass er neue Beispiele empfangen kann. Der Downstreamfilter sendet den EndFlush-Aufruf an den nächsten Filter.

In der BeginFlush-Methode führt der Eingabenadel folgendes aus:

  1. Ruft BeginFlush an nachgeschalteten Eingabenadeln auf.
  2. Lehnt alle weiteren Aufrufe ab, die Daten streamen, einschließlich Receive und EndOfStream.
  3. Entsperrt alle Upstream Filter, die blockiert sind und auf ein Beispiel aus dem Zuteilungsgeber des Filters warten. Einige Filter heben ihre Zuteilungen zu diesem Zweck auf.
  4. Beendet alle Wartezeiten, die das Streaming blockieren. Beispielsweise blockieren Rendererfilter, wenn sie angehalten werden. Sie blockieren auch, wenn sie darauf warten, ein Beispiel zur richtigen Streamzeit zu rendern. Der Filter muss die Blockierung aufheben, damit Beispiele, die Upstream in die Warteschlange gestellt werden, übermittelt und abgelehnt werden können. Mit diesem Schritt wird sichergestellt, dass alle Upstream Filter schließlich die Blockierung aufheben.

In der EndFlush-Methode führt der Eingabenadel folgendes aus:

  1. Wartet, bis alle Beispiele in der Warteschlange verworfen werden.
  2. Gibt alle gepufferten Daten frei. Dieser Schritt kann manchmal in der BeginFlush-Methode ausgeführt werden. BeginFlush wird jedoch nicht mit dem Streamingthread synchronisiert. Der Filter darf keine weiteren Daten zwischen dem Aufruf von BeginFlush und dem Aufruf von EndFlush verarbeiten oder puffern.
  3. Löscht alle ausstehenden EC_COMPLETE Benachrichtigungen.
  4. Ruft EndFlush downstream auf.

An diesem Punkt kann der Filter erneut Beispiele akzeptieren. Alle Beispiele sind garantiert aktueller als die Leerung.

Im Pullmodell initiiert der Parserfilter die Leerung anstelle des Quellfilters. Es ruft nicht nur IPin::BeginFlush und IPin::EndFlush im Downstreamfilter auf, es ruft auch IAsyncReader::BeginFlush und IAsyncReader::EndFlush auf dem Ausgabenadel des Quellfilters auf. Wenn der Quellfilter ausstehende Leseanforderungen enthält, werden diese verworfen.

Leeren von Daten