Alternative Videorenderer

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

In diesem Thema wird beschrieben, wie Sie einen benutzerdefinierten Videorenderer für DirectShow schreiben.

Schreiben eines alternativen Renderers

Microsoft DirectShow bietet einen fensterbasierten Videorenderer. Es bietet auch einen Vollbildrenderer in der Laufzeitinstallation. Sie können die DirectShow-Basisklassen verwenden, um alternative Videorenderer zu schreiben. Damit alternative Renderer ordnungsgemäß mit DirectShow-basierten Anwendungen interagieren können, müssen die Renderer die in diesem Artikel beschriebenen Richtlinien einhalten. Sie können die Klassen CBaseRenderer und CBaseVideoRenderer verwenden, um diese Richtlinien beim Implementieren eines alternativen Videorenderings zu befolgen. Überprüfen Sie ihre Implementierung aufgrund der kontinuierlichen Entwicklung von DirectShow in regelmäßigen Abständen, um sicherzustellen, dass die Renderer mit der neuesten Version von DirectShow kompatibel sind.

In diesem Thema werden viele Benachrichtigungen erläutert, für die ein Renderer verantwortlich ist. Eine kurze Überprüfung der DirectShow-Benachrichtigungen kann helfen, die Phase festzulegen. Es gibt im Wesentlichen drei Arten von Benachrichtigungen, die in DirectShow auftreten:

• Streambenachrichtigungen, bei denen es sich um Ereignisse handelt, die im Mediendatenstrom auftreten und von einem Filter an den nächsten übergeben werden. Dies können Benachrichtigungen zum Starten, Leeren am Ende oder Zum Ende des Datenstroms sein und durch Aufrufen der entsprechenden Methode am Eingabenadel des Nachstromfilters (z. B. IPin::BeginFlush) gesendet werden.
• Filtern Sie Graphbenachrichtigungen, bei denen es sich um Ereignisse handelt, die von einem Filter an den Filter Graph-Manager gesendet werden, z. B. EC_COMPLETE. Dies wird durch Aufrufen der IMediaEventSink::Notify-Methode im Filter Graph-Manager erreicht.
• Anwendungsbenachrichtigungen, die von der steuernden Anwendung aus dem Filter Graph Manager abgerufen werden. Eine Anwendung ruft die IMediaEvent::GetEvent-Methode im Filter Graph-Manager auf, um diese Ereignisse abzurufen. Häufig übergibt der Filter Graph-Manager die empfangenen Ereignisse an die Anwendung.

In diesem Thema wird die Verantwortung des Renderers bei der Verarbeitung empfangener Streambenachrichtigungen und beim Senden entsprechender Filterdiagrammbenachrichtigungen erläutert.

Behandeln von Datenstromende- und Leerungsbenachrichtigungen

Eine Benachrichtigung zum Ende des Datenstroms beginnt bei einem Upstream Filter (z. B. dem Quellfilter), wenn dieser Filter erkennt, dass er keine weiteren Daten mehr senden kann. Es wird durch jeden Filter im Diagramm übergeben und endet schließlich am Renderer, der später für das Senden einer EC_COMPLETE Benachrichtigung an den Filter Graph-Manager verantwortlich ist. Renderer haben eine besondere Verantwortung, wenn es um die Verarbeitung dieser Benachrichtigungen geht.

Ein Renderer empfängt eine Streamendebenachrichtigung, wenn die IPin::EndOfStream-Methode seines Eingabenadels vom Upstream-Filter aufgerufen wird. Ein Renderer sollte sich diese Benachrichtigung notieren und alle bereits empfangenen Daten weiterhin rendern. Sobald alle verbleibenden Daten empfangen wurden, sollte der Renderer eine EC_COMPLETE Benachrichtigung an den Filter Graph Manager senden. Die EC_COMPLETE Benachrichtigung sollte von einem Renderer jedes Mal gesendet werden, wenn er das Ende eines Datenstroms erreicht. Darüber hinaus dürfen EC_COMPLETE Benachrichtigungen nur gesendet werden, wenn das Filterdiagramm ausgeführt wird. Wenn das Filterdiagramm daher angehalten wird, wenn ein Quellfilter eine Benachrichtigung zum Ende des Datenstroms sendet, sollte EC_COMPLETE erst gesendet werden, wenn das Filterdiagramm schließlich ausgeführt wird.

Alle Aufrufe der Methoden IMemInputPin::Receive oder IMemInputPin::ReceiveMultiple , nachdem eine Benachrichtigung zum Ende des Datenstroms signalisiert wurde, sollten abgelehnt werden. E_UNEXPECTED ist die am besten geeignete Fehlermeldung, die in diesem Fall zurückgegeben werden sollte.

Wenn ein Filterdiagramm beendet wird, sollte jede zwischengespeicherte Benachrichtigung zum Ende des Datenstroms gelöscht und beim nächsten Start nicht erneut gesendet werden. Dies liegt daran, dass der Filter graph-Manager alle Filter immer kurz vor der Ausführung anhält, sodass eine ordnungsgemäße Leerung erfolgt. Wenn also beispielsweise das Filterdiagramm angehalten und eine Benachrichtigung zum Ende des Datenstroms empfangen wird und dann das Filterdiagramm beendet wird, sollte der Renderer keine EC_COMPLETE Benachrichtigung senden, wenn er anschließend ausgeführt wird. Wenn keine Suchvorgänge aufgetreten sind, sendet der Quellfilter während des Pausenzustands, der einem Ausführungszustand vorangeht, automatisch eine weitere Benachrichtigung zum Ende des Datenstroms. Wenn hingegen während des Beendens des Filterdiagramms eine Suchfunktion aufgetreten ist, kann der Quellfilter daten senden, sodass keine Benachrichtigung zum Streamende gesendet wird.

Videorenderer sind häufig von Benachrichtigungen zum Ende des Datenstroms abhängig, um nicht nur EC_COMPLETE Benachrichtigungen zu senden. Wenn beispielsweise ein Stream die Wiedergabe beendet hat (d. h. eine Benachrichtigung zum Ende des Datenstroms wird gesendet) und ein anderes Fenster über ein Videorendererfenster gezogen wird, wird eine Reihe von WM_PAINT Fenstermeldungen generiert. Die typische Praxis für die Ausführung von Videorenderern besteht darin, beim Empfang von WM_PAINT Nachrichten davon abzusehen, den aktuellen Frame neu zu bemalen (basierend auf der Annahme, dass ein anderer zu zeichnende Frame empfangen wird). Wenn jedoch die Benachrichtigung zum Ende des Datenstroms gesendet wurde, befindet sich der Renderer in einem Wartezustand. Sie wird weiterhin ausgeführt, ist sich aber bewusst, dass sie keine zusätzlichen Daten empfängt. Unter diesen Umständen zeichnet der Renderer den Wiedergabebereich üblicherweise schwarz.

Die Behandlung der Spülung ist eine zusätzliche Komplikation für Renderer. Das Spülen erfolgt über ein Paar von IPin-Methoden namens BeginFlush und EndFlush. Das Leeren ist im Wesentlichen ein zusätzlicher Zustand, den der Renderer behandeln muss. Es ist illegal, dass ein Quellfilter BeginFlush aufruft, ohne EndFlush aufzurufen. Daher ist der Zustand hoffentlich kurz und diskret. Der Renderer muss jedoch Daten oder Benachrichtigungen, die er während des Leervorgangs empfängt, ordnungsgemäß verarbeiten.

Alle Nach dem Aufruf von BeginFlush empfangenen Daten sollten sofort abgelehnt werden, indem S_FALSE zurückgegeben wird. Darüber hinaus sollten alle zwischengespeicherten Benachrichtigungen zum Ende des Datenstroms auch gelöscht werden, wenn ein Renderer geleert wird. Ein Renderer wird in der Regel als Reaktion auf eine Suche geleert. Durch die Leerung wird sichergestellt, dass alte Daten aus dem Filterdiagramm gelöscht werden, bevor neue Proben gesendet werden. (In der Regel wird die Wiedergabe von zwei Abschnitten eines Datenstroms nacheinander am besten über verzögerte Befehle verarbeitet, anstatt auf den Abschluss eines Abschnitts zu warten und dann einen Suchbefehl auszugeben.)

Behandeln von Zustandsänderungen und Anhalten der Vervollständigung

Ein Rendererfilter verhält sich genauso wie jeder andere Filter im Filterdiagramm, wenn sein Zustand geändert wird, mit der folgenden Ausnahme. Nach dem Anhalten hat der Renderer einige Daten in die Warteschlange gestellt, die beim anschließenden Ausführen gerendert werden können. Wenn der Videorenderer beendet wird, behält er diese Daten in der Warteschlange bei. Dies ist eine Ausnahme von der DirectShow-Regel, dass keine Ressourcen von Filtern gehalten werden sollen, während das Filterdiagramm beendet wird.

Der Grund für diese Ausnahme ist, dass der Renderer durch das Halten von Ressourcen immer über ein Bild verfügt, mit dem das Fenster neu gezeichnet werden kann, wenn er eine WM_PAINT Nachricht empfängt. Es verfügt auch über ein Image, um Methoden wie CBaseControlVideo::GetStaticImage zu erfüllen, die eine Kopie des aktuellen Images anfordern. Ein weiterer Effekt des Haltens von Ressourcen ist, dass das Halten am Bild verhindert, dass der Zuteilungsvorgang aufgehoben wird, was wiederum dazu führt, dass die nächste Zustandsänderung viel schneller erfolgt, da die Bildpuffer bereits zugeordnet sind.

Ein Videorenderer sollte Beispiele nur während der Ausführung rendern und freigeben. Während sie angehalten werden, kann der Filter sie rendern (z. B. beim Zeichnen eines statischen Posterbilds in einem Fenster), sollte sie aber nicht freigeben. Audiorenderer rendern nicht, während sie angehalten sind (obwohl sie andere Aktivitäten ausführen können, z. B. das Vorbereiten des Wellengeräts). Die Zeit, zu der die Beispiele gerendert werden sollen, wird abgerufen, indem die Streamzeit im Beispiel mit der als Parameter übergebenen Referenzzeit für die IMediaControl::Run-Methode kombiniert wird. Renderer sollten Stichproben ablehnen, deren Startzeiten kleiner oder gleich Endzeiten sind.

Wenn eine Anwendung ein Filterdiagramm anhält, wird das Filterdiagramm erst von seiner IMediaControl::P ause-Methode zurückgegeben, bis daten in die Warteschlange der Renderer eingereiht sind. Um dies sicherzustellen, sollte ein Renderer, wenn er angehalten wird, S_FALSE zurückgeben, wenn keine Daten darauf warten, gerendert zu werden. Wenn Daten in eine Warteschlange eingereiht sind, können S_OK zurückgegeben werden.

Der Filter Graph-Manager überprüft alle Rückgabewerte, wenn ein Filterdiagramm angehalten wird, um sicherzustellen, dass die Renderer Daten in die Warteschlange gestellt haben. Wenn mindestens ein Filter nicht bereit ist, ruft der Filter Graph-Manager die Filter im Diagramm ab, indem er IMediaFilter::GetState aufruft. Die GetState-Methode benötigt einen Timeoutparameter. Ein Filter (in der Regel ein Renderer), der immer noch auf das Eintreffen von Daten wartet, bevor die Zustandsänderung abgeschlossen ist, gibt VFW_S_STATE_INTERMEDIATE zurück, wenn die GetState-Methode abläuft. Sobald Daten beim Renderer eintreffen, sollte GetState sofort mit S_OK zurückgegeben werden.

Sowohl im Zwischen- als auch im abgeschlossenen Zustand wird der gemeldete Filterzustand State_Paused. Nur der Rückgabewert gibt an, ob der Filter wirklich bereit ist oder nicht. Wenn ein Renderer auf das Eintreffen von Daten wartet, dessen Quellfilter eine Benachrichtigung zum Streamende sendet, sollte dies auch die Statusänderung abschließen.

Sobald für alle Filter Tatsächlich Daten auf das Rendern warten, schließt das Filterdiagramm die Änderung des Pausenzustands ab.

Behandlung der Beendigung

Videorenderer müssen Beendigungsereignisse des Benutzers ordnungsgemäß behandeln. Dies bedeutet, dass das Fenster ordnungsgemäß ausgeblendet und zu wissen ist, was zu tun ist, wenn ein Fenster anschließend zur Anzeige gezwungen wird. Außerdem müssen Videorenderer den Filter graph-Manager benachrichtigen, wenn sein Fenster zerstört wird (genauer gesagt, wenn der Renderer aus dem Filterdiagramm entfernt wird), um Ressourcen freizugeben.

Wenn der Benutzer das Videofenster schließt (für instance durch Drücken von ALT+F4), besteht die Konvention darin, das Fenster sofort auszublenden und eine EC_USERABORT Benachrichtigung an den Filter Graph-Manager zu senden. Diese Benachrichtigung wird an die Anwendung übergeben, wodurch die Wiedergabe des Graphen beendet wird. Nach dem Senden EC_USERABORT sollte ein Videorenderer alle zusätzlichen Beispiele ablehnen, die an ihn übermittelt werden.

Das Diagrammstoppflagge sollte vom Renderer aktiviert werden, bis es anschließend beendet wird. An diesem Punkt sollte es zurückgesetzt werden, damit eine Anwendung die Benutzeraktion überschreiben und das Diagramm bei Bedarf weiterhin wiedergeben kann. Wenn ALT+F4 gedrückt wird, während das Video ausgeführt wird, wird das Fenster ausgeblendet, und alle weiteren übermittelten Beispiele werden abgelehnt. Wenn das Fenster anschließend angezeigt wird (z. B. über IVideoWindow::p ut_Visible), sollten keine EC_REPAINT Benachrichtigungen generiert werden.

Der Videorenderer sollte auch die EC_WINDOW_DESTROYED-Benachrichtigung an das Filterdiagramm senden, wenn der Videorenderer beendet wird. Tatsächlich ist es am besten, dies zu behandeln, wenn die IBaseFilter::JoinFilterGraph-Methode des Renderers mit einem NULL-Parameter aufgerufen wird (der angibt, dass der Renderer gerade aus dem Filterdiagramm entfernt werden soll), anstatt zu warten, bis das tatsächliche Videofenster zerstört wird. Durch das Senden dieser Benachrichtigung kann der Plug-In-Verteiler im Filter Graph-Manager Ressourcen, die vom Fensterfokus abhängen, an andere Filter wie Audiogeräte übergeben.

Behandeln dynamischer Formatänderungen

In einigen Fällen kann der Upstream Filter des Renderers versuchen, das Videoformat zu ändern, während das Video wiedergegeben wird. Am häufigsten ist es der Video-Dekomprimierungsor, der eine dynamische Formatänderung initiiert.

Ein Upstream Filter, der versucht, Formate dynamisch zu ändern, sollte immer die IPin::QueryAccept-Methode auf dem Renderereingabenadel aufrufen. Ein Videorenderer hat einen gewissen Spielraum, welche Arten von dynamischen Formatänderungen er unterstützen sollte. Es sollte dem Upstream Filter zumindest erlauben, Paletten zu ändern. Wenn ein Upstream Filter die Medientypen ändert, wird der Medientyp an das erste Beispiel angefügt, das im neuen Format bereitgestellt wird. Wenn der Renderer Beispiele zum Rendern in einer Warteschlange enthält, sollte er das Format erst ändern, wenn das Beispiel mit der Typänderung gerendert wird.

Ein Videorenderer kann auch eine Formatänderung vom Decoder anfordern. Beispielsweise kann der Decoder aufgefordert werden, ein DirectDraw-kompatibles Format mit einem negativen biHeight-Format bereitzustellen. Wenn der Renderer angehalten wird, sollte er QueryAccept auf der Upstream Pin aufrufen, um zu sehen, welche Formate der Decoder bereitstellen kann. Der Decoder zählt möglicherweise nicht alle Typen auf, die er akzeptieren kann, daher sollte der Renderer einige Typen anbieten, auch wenn der Decoder sie nicht ankündigen.

Wenn der Decoder in das angeforderte Format wechseln kann, gibt er S_OK aus QueryAccept zurück. Der Renderer fügt dann den neuen Medientyp an das nächste Medienbeispiel auf der Upstream Zuweisung an. Damit dies funktioniert, muss der Renderer eine benutzerdefinierte Zuweisung bereitstellen, die eine private Methode zum Anfügen des Medientyps an das nächste Beispiel implementiert. (Rufen Sie innerhalb dieser privaten Methode IMediaSample::SetMediaType auf, um den Typ festzulegen.)

Der Eingabenadel des Renderers sollte die benutzerdefinierte Zuweisung des Renderers in der IMemInputPin::GetAllocator-Methode zurückgeben. Überschreiben Sie IMemInputPin::NotifyAllocator, sodass ein Fehler auftritt, wenn der Upstream Filter nicht die Zuweisung des Renderers verwendet.

Bei einigen Decodern führt das Festlegen von biHeight auf eine positive Zahl für YUV-Typen dazu, dass der Decoder das Bild auf den Kopf stellt. (Dies ist falsch und sollte als Fehler im Decoder betrachtet werden.)

Wenn eine Formatänderung vom Videorenderer erkannt wird, sollte er eine EC_DISPLAY_CHANGED Benachrichtigung senden. Die meisten Videorenderer wählen während der Verbindung ein Format aus, damit das Format effizient über GDI gezeichnet werden kann. Wenn der Benutzer den aktuellen Anzeigemodus ändert, ohne den Computer neu zu starten, kann sich ein Renderer mit einer fehlerhaften Bildformatverbindung befinden und diese Benachrichtigung senden. Der erste Parameter sollte der Pin sein, der erneut verbunden werden muss. Der Filtergraph-Manager sorgt dafür, dass das Filterdiagramm beendet und der Pin wiederhergestellt wird. Während der anschließenden erneuten Verbindung kann der Renderer ein geeigneteres Format annehmen.

Wenn ein Videorenderer eine Palettenänderung im Stream erkennt, sollte er die EC_PALETTE_CHANGED Benachrichtigung an den Graph-Filter-Manager senden. Die DirectShow-Videorenderer erkennen, ob sich eine Palette wirklich im dynamischen Format geändert hat. Die Videorenderer verwenden dies nicht nur, um die Anzahl der gesendeten EC_PALETTE_CHANGED Benachrichtigungen herauszufiltern, sondern auch, um die Erforderliche Menge an Palettenerstellung, Installation und Löschung zu reduzieren.

Schließlich erkennt der Videorenderer möglicherweise auch, dass sich die Größe des Videos geändert hat. In diesem Fall sollte er die EC_VIDEO_SIZE_CHANGED Benachrichtigung senden. Eine Anwendung kann diese Benachrichtigung verwenden, um platz in einem zusammengesetzten Dokument auszuhandeln. Die tatsächlichen Videodimensionen sind über die IBasicVideo-Steuerungsschnittstelle verfügbar. Die DirectShow-Renderer erkennen vor dem Senden dieser Ereignisse, ob sich die Größe des Videos tatsächlich geändert hat.

Behandeln persistenter Eigenschaften

Alle Eigenschaften, die über die IBasicVideo - und IVideoWindow-Schnittstellen festgelegt werden, sollen über Verbindungen hinweg persistent sein. Daher sollte das Trennen und erneute Verbinden eines Renderers keine Auswirkungen auf die Fenstergröße, -position oder -formatvorlagen aufweisen. Wenn sich die Videodimensionen jedoch zwischen Verbindungen ändern, sollte der Renderer die Quell- und Zielrechtecke auf die Standardwerte zurücksetzen. Die Quell- und Zielpositionen werden über die IBasicVideo-Schnittstelle festgelegt.

Sowohl IBasicVideo als auch IVideoWindow bieten ausreichend Zugriff auf Eigenschaften, damit eine Anwendung alle Daten in der Schnittstelle in einem persistenten Format speichern und wiederherstellen kann. Dies ist nützlich für Anwendungen, die die genaue Konfiguration und die Eigenschaften von Filtergraphen während einer Bearbeitungssitzung speichern und später wiederherstellen müssen.

Behandeln von EC_REPAINT-Benachrichtigungen

Die EC_REPAINT Benachrichtigung wird nur gesendet, wenn der Renderer entweder angehalten oder beendet wird. Diese Benachrichtigung signalisiert dem Graphfilter-Manager, dass der Renderer Daten benötigt. Wenn das Filterdiagramm beendet wird, wenn es eine dieser Benachrichtigungen empfängt, wird das Filterdiagramm angehalten, bis alle Filter Daten empfangen (durch Aufrufen von GetState) und dann erneut beendet. Wenn er beendet wird, sollte ein Videorenderer das Bild beibehalten, damit nachfolgende WM_PAINT Nachrichten verarbeitet werden können.

Wenn ein Videorenderer daher beim Beenden oder Anhalten eine WM_PAINT Nachricht empfängt und nichts mit dem er sein Fenster zeichnen kann, sollte er EC_REPAINT an den Graphfilter-Manager senden. Wenn eine EC_REPAINT Benachrichtigung empfangen wird, während angehalten, ruft der Graphfilter-Manager IMediaPosition::p ut_CurrentPosition mit der aktuellen Position auf (d. h. sucht nach der aktuellen Position). Dies führt dazu, dass die Quellfilter das Filterdiagramm leeren und neue Daten durch das Filterdiagramm gesendet werden.

Ein Renderer muss jeweils nur eine dieser Benachrichtigungen senden. Wenn der Renderer eine Benachrichtigung gesendet hat, sollte er daher sicherstellen, dass erst dann mehr gesendet wird, wenn einige Beispiele übermittelt wurden. Die herkömmliche Methode hierfür besteht darin, ein Flag zu haben, das angibt, dass eine Neubemalung gesendet werden kann, die deaktiviert wird, nachdem eine EC_REPAINT Benachrichtigung gesendet wurde. Dieses Flag sollte zurückgesetzt werden, sobald Daten übermittelt wurden oder wenn der Eingabenadel geleert wird, aber nicht, wenn das Ende des Datenstroms am Eingabepin signalisiert wird.

Wenn der Renderer seine EC_REPAINT Benachrichtigungen nicht überwacht, überflutet er den Filter Graph-Manager mit EC_REPAINT Anforderungen (die relativ teuer zu verarbeiten sind). Wenn z. B. ein Renderer kein Bild zu zeichnen hat und ein anderes Fenster in einem Vollziehvorgang über das Fenster des Renderers gezogen wird, empfängt der Renderer mehrere WM_PAINT Nachrichten. Nur die erste sollte eine EC_REPAINT Ereignisbenachrichtigung vom Renderer an den Filter Graph-Manager generieren.

Ein Renderer sollte seine Eingabenadel als ersten Parameter an die EC_REPAINT Benachrichtigung senden. Dadurch wird der angefügte Ausgabepin nach IMediaEventSink abgefragt, und wenn dies unterstützt wird, wird die EC_REPAINT Benachrichtigung zuerst dorthin gesendet. Dadurch können Ausgabepins Neubemalungen verarbeiten, bevor das Filterdiagramm berührt werden muss. Dies erfolgt nicht, wenn das Filterdiagramm beendet wird, da über die decommittedierte Rendererzuweisung keine Puffer verfügbar wären.

Wenn der Ausgabepin die Anforderung nicht verarbeiten kann und das Filterdiagramm ausgeführt wird, wird die EC_REPAINT Benachrichtigung ignoriert. Ein Ausgabepin muss S_OK von IMediaEventSink::Notify zurückgeben, um zu signalisieren, dass die Anforderung zum erneuten Streichen erfolgreich verarbeitet wurde. Der Ausgabepin wird im Filter Graph Manager-Workerthread aufgerufen, wodurch vermieden wird, dass der Renderer den Ausgabepin direkt aufruft, sodass alle Deadlockprobleme vermieden werden. Wenn das Filterdiagramm beendet oder angehalten wird und die Ausgabe die Anforderung nicht verarbeitet, ist die Standardverarbeitung abgeschlossen.

Behandeln von Benachrichtigungen im Full-Screen-Modus

Der IVideoWindow-Plug-In-Verteiler (PID) im Filterdiagramm verwaltet die Vollbildwiedergabe. Es wird ein Videorenderer gegen einen spezialisierten Vollbildrenderer ausgetauscht, ein Fenster eines Renderers auf den Vollbildmodus gestreckt oder der Renderer muss die Vollbildwiedergabe direkt implementieren. Um in Vollbildprotokollen zu interagieren, sollte ein Videorenderer eine EC_ACTIVATE Benachrichtigung senden, wenn sein Fenster aktiviert oder deaktiviert wird. Anders ausgedrückt: Für jede WM_ACTIVATEAPP Nachricht, die ein Renderer empfängt, sollte eine EC_ACTIVATE Benachrichtigung gesendet werden.

Wenn ein Renderer im Vollbildmodus verwendet wird, verwalten diese Benachrichtigungen das Umschalten in und aus diesem Vollbildmodus. Die Fensterdeaktivierung tritt in der Regel auf, wenn ein Benutzer ALT+TAB drückt, um zu einem anderen Fenster zu wechseln, das der DirectShow-Vollbildrenderer als Hinweis verwendet, um zum typischen Renderingmodus zurückzukehren.

Wenn die EC_ACTIVATE-Benachrichtigung beim Wechsel aus dem Vollbildmodus an den Filter graph-Manager gesendet wird, sendet der Graph-Filter-Manager eine EC_FULLSCREEN_LOST Benachrichtigung an die steuernde Anwendung. Die Anwendung kann diese Benachrichtigung verwenden, um beispielsweise den Status einer Vollbildschaltfläche wiederherzustellen. Die EC_ACTIVATE Benachrichtigungen werden intern von DirectShow verwendet, um das Einschalten von Videorenderern im Vollbildmodus zu verwalten.

Zusammenfassung der Benachrichtigungen

In diesem Abschnitt werden die Filterdiagrammbenachrichtigungen aufgelistet, die ein Renderer senden kann.

Zugehörige Themen

Schreiben von Videorenderern