Multimediaschnittstelle Microsoft DirectShow

Fach: Vertiefung (Seminar) Fachrichtung: MNC Semester: 3 Name: Robin Lüdtke Matrikel: 41621

Inhaltsverzeichnis

1. Grundlagen .....................................................................3

1.1 VFW........................................................................................................................... 3

1.2 WDM (KS) / WMF .................................................................................................... 4

1.3 DirectShow – DirectX................................................................................................ 5

1.4 Aufgaben von DirectShow......................................................................................... 6

1.5 COM - kurze Einführung ........................................................................................... 7

2. Architektur .....................................................................9

2.1 Filter-Graph-Manager .............................................................................................. 11

3. Filter-Graphen..............................................................12

3.1 Erstellung von Filter-Graphen.................................................................................. 12

3.2 Filter-Verbindungsprotokolle................................................................................... 14 3.2.1 MediaType-Vermittlung................................................................................................................ 14 3.2.2 Transport-Vermittlung .................................................................................................................. 15 3.2.3 Speicherverwaltung-Vermittlung .................................................................................................. 16

3.3 Datenfluss-Protokolle............................................................................................... 17 3.3.1 Streaming-Protokoll ...................................................................................................................... 17 3.3.2 Control-Protokoll .......................................................................................................................... 18

3.4 Synchronisation........................................................................................................ 20

4. Beispiel ..........................................................................22

5. Zusammenfassung........................................................23

6. Quellen ..........................................................................23

2

1. Grundlagen In der folgenden Ausarbeitung werden die Grundlagen von DirectShow beschrieben. Jeder, der mittels Microsoft-Betriebssystem (ab Win98) versucht hat, eine DVD, ein Video, einen Song im MP3-Format wiederzugeben oder beispielsweise eine Webcam über USB oder eine Videokamera über Firewire benutzt hat, hat unbewusst die DirectShow-Schnittstelle benutzt. Denn der größte Teil der Multimediasoftware (z.B.: Windows Media Player, Pinnacle Studio, Winamp, Intro-Videos bei PC-Spielen, …) unter Windows nutzt DirectShow für die Multimediadatenverarbeitung.

1.1 VFW 1992 wurde die VFW-Multimediaschnittstelle als frei erhältliches AddOn für das Microsoft-Betriebssystem Windows 3.11 zur Verfügung gestellt. Anfangs waren die Aufgaben und Leistung sehr beschränkt. Durch Weiterentwicklung ist folgender Aufgaben-/Funktionsumfang entstanden:

• Aufgaben: Abspielen / Aufnahme / Kompression / Dekompression von Video-/Audiodaten

• Anfangs: nur 16-Bit Architektur; Heute: teilweise 32-Bit. • AVI (Audio Video Interleaved) Container-Dateiformat • Spezielle Treiber für Kommunikation mit Hardware

Die Weiterentwicklung von VFW ist seit einigen Jahren eingestellt. Wesentliche Gründe (Nachteile) dafür sind:

• VFW-Treiber: separate Treiber für WinNT/Win9x notwendig (nicht Sourcecode-/Binärkompatibel), keine standardisierten gerätespezifischen Kommunikationsschnittstellen (z.B.: fehlende TVTuner-Unterstützung), Treibermodell inkonsistent

• Unterstützung weniger Dateiformate (z.B.: AVI Container-Dateiformat) • nur teilweise 32 Bit Architektur • keine Synchronisationsmechanismen • AVI Container-Dateiformat: begrenzt auf 2 GB, nicht streamingfähig, Synchronisation

schwierig Aufgrund der genannten Nachteile ist eine neue Multimediaschnittstelle unabdingbar. Zusätzlich sind das VFW-Treibermodell sowie das AVI Container-Dateiform, aufgrund enormer Einschränkungen und Nachteile für heutige Anforderungen nicht mehr akzeptabel. Aufgrund von Kompatibilitätszwecken ist es weiterhin Bestandteil der Windows-Betriebssysteme. Beispiel: Will man eine Videodatei über das Internet empfangen (streamen), so muss die Multimediaschnittstelle sowie das Dateiformat über Synchronisationsmechanismen verfügen. Weder die VFW-Multimediaschnittstelle noch das AVI Dateiformat können somit für einen derartigen Einsatzbereich verwendet werden.

Neuentwicklung: Multimediaschnittstelle (DirectShow) / Treiberarchitektur (siehe Abschnitt 1.2 (WDM)) / Dateiformat (siehe Abschnitt 1.2 (WMF))

3

1.2 WDM (KS) / WMF WDM (Windows Driver Model) (KS (Kernel-Streaming)): Dieses Treibermodell basiert auf dem WinNT-Treibermodell mit wesentlichen Erweiterungen (z.B.: Plug&Play). WDM wird für Multimediageräte und neuere USB oder Firewire-Geräte verwendet. Vorteile gegenüber VFW-Treiber:

• Treiber sind innerhalb der Windows-Betriebssysteme kompatibel. Entwickler müssen somit nicht für jedes Betriebssystem einen eigenen Treiber programmieren, wie es bei VFW der Fall ist.

• es besteht volle 32-Bit Unterstützung • standardisierte Kommunikationsschnittstellen sind vorhanden (z.B.: TVTuner-

Unterstützung, Captureformate auslesen, Videoparametereinstellung,…)

Die erste Implementierung von WDM sah noch vor, alle Signale in einem auf Kernel-Ebene laufenden Mixer zusammenzumischen und erst dann auszugeben. Dabei entstand eine nicht zu verhindernde Latenz von 30ms, die im Video-/Audiobereich unakzeptabel ist. Auf Vorschlag der Firma Cakewalk wurde eine Variante von WDM entworfen, die es ermöglichte, auch an diesem Mixer vorbei auf die Hardware zuzugreifen. Inzwischen wurde dieser Vorschlag von Microsoft offiziell anerkannt und diese Variante wird als WDM(KS) (Kernel-Streaming) bezeichnet. Geräte auf WDM-Treibern basierend, unterstützen das Kernel-Streaming. Dabei werden die Daten ohne umschalten in den User-Mode, komplett im Kernel-Mode transportiert. Daraus ergeben sich folgende Vorteile:

• Die Umschaltung zwischen User- und Kernel-Mode ist sehr rechenintensiv und dadurch entstehen hohe Latenzzeiten Latenzzeit wird verringert

• Kernel-Streaming erlaubt hohen Datentransfer ohne CPU-Belastung Das Kernel-Streaming basiert auf einer Filterarchitektur, wie in der folgenden Abbildung 1 dargestellt. Jeder Filter entspricht einem WDM-Treiber mit KS-Unterstützung. Filter werden über Pins miteinander verbunden. Der Datentransfer geschieht über die verbundenen Pins im Kernel-Mode (Multimediadaten-Transport von Hardware zu Hardware).

Abbildung 1: Kernel Streaming Filter-Architektur am Beispiel WMF (Windows Media Format): Innerhalb des WMF wird das Container-Dateiformat ASF (Advanced-Streaming-Format) beschrieben. Dies ist ein proprietäres Format und stellt Microsofts eigene MPEG4-Implementierung dar. Entwickelt wurde es vor der Verabschiedung des endgültigen MPEG4 Standards, welcher das QuickTime Movie (MOV-Format) vorsieht. Auch bietet das WMF die

4

Möglichkeit der Kompression von Video-/Audiodaten mittels Microsofts entwickelten MPEG4-Codec’s, sowie die effiziente Multimedia-Datenübertragung per Netzwerk (geringe Netzwerkbandbreite). In neueren WMF-Versionen wird zusätzlich HDTV unterstützt. Mit Microsofts MPEG4-Codec komprimierte Videos erhalten die Dateiendung „.wmv“ (Windows Media Video) und Audiodaten „.wma“ (Windows Media Audio) Vorteile von ASF Container-Dateiformat gegenüber AVI Container-Dateiformat:

• ASF enthält Synchronisationsmechanismen und ist somit • Streamingfähig • Dateigröße nicht begrenzt

1.3 DirectShow – DirectX DirectX ist eine Sammlung von Komponenten für verschiedene multimediale Bereiche (Grafik, Audio,…) und bietet dafür Schnittstellen für die effiziente Kommunikation von Software mit Hardware. Dem Programmierer steht eine hardwareunabhängige Funktionsbibliothek bereit. Wird eine DirectX-Funktion verwendet, die eine spezielle Hardware erfordert, so wird diese Funktion bei fehlender Hardwareunterstützung mittels Softwareemulation (optimierte Softwareroutinen mittels Assemblercode) bereitgestellt. DirectShow ist seit 1996 Bestandteil der DirectX-Komponentensammlung und benutzt andere DirectX-Komponenten wie in Abbildung 2 dargestellt. Im Abschnitt 2 folgt eine detaillierte Erklärung.

Abbildung 2: DirectX Komponenten

5

1.4 Aufgaben von DirectShow Hauptaufgaben: In der Abbildung 3 wird das Hauptprinzip von DirectShow präsentiert. DirectShow wird vorerst zur Vereinfachung als Black-Box dargestellt. Im ersten Schritt wird immer eine Multimediadatenquelle benötigt (links dargestellt), welche Multimediadaten erzeugt und an die Black-Box weiterleitet. Als Quelle können verschiedene Multimedia-Peripheriegeräte dienen (z.B.: DVB-T-/TV-Karten, Framegrabber, Firewire-/USB-Kameras, Audioquellen), welche über einen WDM- oder VFW-Treiber verfügen. Multimediadatenträger(z.B.: Video-CD, Video-DVD) sowie auf Datenträgern abgelegte Videos (z.B.: MPEG-Video, QuickTime-Video), Audiomaterial (z.B.: MP3, PCM-Audio) und Einzelbilder (z.B.: JPG, BMP, TIFF) oder Netzwerkstreams sind ebenfalls möglich. Im zweiten Schritt werden die erhaltenen Multimediadaten von der Multimediadatenquelle, innerhalb der Black-Box verarbeitet (z.B.: Kompression, Dekompression, Multiplexing, …). Die Applikation kann dabei die Datenverarbeitung in der Black-Box über verschiedene Funktionen steuern. Im letzten Schritt werden die Multimediadaten ausgegeben (rechts dargestellt). Die Ausgabe kann entsprechend des Multimediadatenformats an die Grafikkarte, Soundkarte oder auf einen Datenträger (z.B.: Videos, Einzelbilder) oder Netzwerkstream erfolgen.

Abbildung 3: Hauptaufgaben von DirectShow DES (DirectShow Editing Service): Aufbauend auf der DirectShow-Architektur bietet DirectShow zusätzlich eine API für Videobearbeitung (Video-/Audioschnitt), die in dieser Dokumentation nicht erklärt wird.

6

1.5 COM - kurze Einführung DirectShow sowie alle DirectX-Komponenten und andere Software basieren auf der „COM“-Technologie (Component Object Model). Um ein besseres Verständnis der folgenden Abschnitte und Beispiele zu erhalten, werden an dieser Stelle die Grundlagen dieser Technologie beschrieben. Komponentenbasierte Softwareentwicklung ist die Basis der Software heutzutage. Anstelle der Programmierung von komplexer Software werden Software-Teilstücke (Komponenten) programmiert, welche zusammen kommunizieren. Der größte Vorteil liegt darin, dass die meisten Komponenten so aufgebaut werden können, um sie in einem nächsten Projekt ohne größere Veränderungen wieder zu verwenden. Ein weiterer Vorteil ergibt sich in der Überarbeitung der Komponenten, wobei jede Komponente separat weiterentwickelt werden kann, ohne die anderen Komponenten zu beeinflussen. Die Basis der Komponentenentwicklung beruht dabei auf einem einheitlichen Kommunikationsprotokoll, damit die erstellten Komponenten untereinander überhaupt kommunizieren können. Microsoft hat dafür die Schnittstelle „COM“ (Component Object Model) ins Leben gerufen, welche die Art und Weise der Kommunikation zwischen Objekten sowie die Spezifikationen der Objekte selbst und ihre Funktionalitäten beschreiben. COM ist dabei Sprach- Plattform- und Maschinenunabhängig (COM kann ebenfalls über Netzwerk mit Objekten kommunizieren) entwickelt. Die Basis eines COM-Objekts ist ein Codeblock, welcher ein oder mehrere COM-Schnittstellen (Interfaces) beinhaltet. Eine COM-Schnittstelle ist wiederum eine Kapselung von Funktionen und die Implementierung ist ähnlich der Implementierung von virtuellen Funktionstabellen der meisten C++ Compiler. In C++ bedeuten COM-Objekte eine oder mehrere abstrakte Klassen, welche COM-Schnittstellen genannt werden. Andere Klassen können lediglich die Funktionen der COM-Objekte durch die angebundenen Schnittstellen aufrufen aber haben keinen Zugang auf Membervariablen, sondern können diese nur über Set/Get Funktionen, welche die Schnittstelle bietet verändern.

Abbildung 4: COM Objekt + Schnittstellen (Interfaces) Alle COM-Schnittstellen werden direkt oder indirekt von der so genannten Klasse „IUnknown“ abgeleitet. IUnknown ist folgendermaßen deklariert: typedef struct interface; interface IUnknown { virtual HRESULT QueryInterface( REFIID idd, void** ppvObject) = 0; virtual ULONG AddRef( void)= 0; virtual ULONG Release( void) = 0;};

7

Die Funktionen AddRef und Release dienen dem Anlegen und Zerstören von COM-Objekten und sollen nicht weiter betrachtet werden. Hauptbestandteil damit COM überhaupt funktionieren kann, ist die Funktion QueryInterface(). Durch diese Funktionen können weitere Schnittstellen, die das COM-Objekt anbietet verwendet werden. Der Funktion wird eine Schnittstellen-ID (GUID) und ein Zeiger übergeben, welcher nach Abschluss mit dem Schnittstellenzeiger, durch die ID bestimmte Schnittstelle gefüllt ist. Als Beispiel könnte man sich ein Radio vorstellen. Zuerst legt man ein Radio-Objekt an und erhält einen Schnittstellen Zeiger auf pRadio. Will man nun den CD-Player bedienen so fragt man über die Radio-Schnittstelle, ob eine Schnittstelle ICDPlayer vorhanden ist: ICDPlayer* pCDPlayer = NULL; HRESULT hr = pRadio->QueryInterface(IID_ICDPlayer, (VOID**)&pCDPlayer ); // pCDPlayer kann nun genutzt werden Dies ist der Vorteil von COM. Das Objekt kann verbessert und erweitert werden ohne jegliche Neukompilierung. Wenn man sich beispielsweise für die Unterstützung eines Kassettenplayers entscheidet, so muss nur über QueryInterface() die Schnittstelle ICassettePlayer nachgefragt werden. Damit COM so arbeiten kann gibt es zwei Restriktionen für das System-Design. Alle Schnittstellen müssen public definiert sein. In den DirectX Header-Dateien kann man beispielsweise alle DirectX-Schnittstellen finden. Jedes COM-Programm kann jedes COM-Objekt nutzen, solange es die Schnittstellendefinition sowie die IDs (GUIDs) für die COM-Schnittstelle kennt. Eine weitere Restriktion ist, dass eine COM-Schnittstelle sich niemals ändern darf. Nachdem sie fertig gestellt ist und der Öffentlichkeit zugänglich ist, kann keine Modifikation mehr vorgenommen werden. Um weitere Funktionalitäten zu integrieren müssen neue COM-Schnittstellen erstellt werden. Will man also die vorhandene Schnittstelle ICDPlayer erweitern so muss man eine neue Schnittstelle ICDPlayer2 anlegen. Wird die erweiterte COM-Schnittstelle ICDPlayer2 nicht benötigt, so kann natürlich auch ICDPlayer weiterhin uneingeschränkt genutzt werden. Die „älteren“ COM-Schnittstellen verfallen also nicht. Nun bleibt noch die letzte Frage, wie COM-Objekte überhaupt angelegt werden. Ein COM Objekt wird generell durch eine COM-Objekt-ID und einer Schnittstellen-ID bestimmt. Intern ruft die COM-Erstellungsroutine die Windows-Registrierung auf und sucht die COM-Objekt-ID. Wenn das COM-Objekt im System installiert ist, so gibt es in der Registrierung eine Referenz von COM-Objekt-ID auf eine DLL. Die DLL wird dann von der nachfragenden Anwendung aus geladen. Das Objekt wird unter Benutzung einer DLL-Side Class-Factory konstruiert und gibt eine Iunknown-Schnittstelle zurück und danach wird diese Schnittstelle nach der angegebenen Schnittstellen-ID untersucht. Beispiel: Wenn man nach der COM-Objekt-ID für Direct3D in der Registrierung sucht, so findet man eine Referenz zu d3d9.dll. Um allen COM-Objekt Entwicklern eine eindeutige ID für Ihre COM-Objekte zu garantieren, gibt es die sogenannte GUID (globally unique identifiers), welche aus 16 Byte besteht und einmalig ist. Diese GUID setzt sich zusammen aus einem sehr langen TIMESTAMP und einer Hardware-ID (z.B. Netzwerkkarte des Rechners).

8

2. Architektur In den folgenden Abschnitten wird die in Abbildung 3 dargestellte Black-Box (DirectShow) detailliert beschrieben. Den ersten Einblick gewährt die Abbildung 5. Sie zeigt die zwei Hauptbestandteile von DirectShow (hellblau unterlegt). Der Filter-Graph-Manager dient zur Erstellung und Steuerung des Filter-Graphen und wird in Abschnitt 2.1 genauer erklärt. Der Filter-Graph stellt einen gerichteten Graphen mit Knoten (genannt Filter (implementiert als COM-Objekt)) dar, die über eine verschiedene Anzahl an Input- und Output-Pins verfügen. Die Filter werden über ihre Pins miteinander verbunden. Die Datenverarbeitung findet somit vollständig in den Filtern und der Daten-Transport über die Pins statt. Es stehen drei Filterarten zur Verfügung:

• Source-Filter leiten Daten in den Filter-Graph ein. Daten können beispielsweise aus einer Multimediadatei oder DVD, vom Netzwerk oder einer Firewire-/USB-Kamera stammen. Diese Filterart kann nur über Output-Pins verfügen, da sie am Anfang der Filterkette steht.

• Transform-Filter erhalten einen Eingangs-Datenstrom. Dieser wird im Filter verarbeitet und anschließend ein neuer Ausgangs-Datenstrom erzeugt. Video-/Audiokompressoren, Dekompressoren und Effektfilter sind Beispiele für Transform-Filter. Der Filter kann Input- sowie Output-Pins besitzen.

• Rendering-Filter befinden sich immer am Ende des Filter-Graphen. Der ankommende Eingangs-Datenstrom wird verarbeitet und dem Benutzer präsentiert. Ein Video-Rendering-Filter nutzt für die Präsentation von Videomaterial die Direct3D-Schnittstelle für optimale 2D-Grafikbeschleunigung. Beim Audio-Rendering-Filter erfolgt die Wiedergabe des Audiomaterials mittels der DirectSound-Schnittstelle. Bei der Wiedergabe einer Mididatei kommt die DirectMusic-Schnittstelle zum Einsatz. Ein Rendering-Filter kann auch zum Schreiben von Daten auf verschiedene Datenträger oder für das Erzeugen von Netzwerkstreams verwendet werden. Diese Filterart kann nur Input-Pins besitzen, da sie am Ende der Filterkette steht.

Abbildung 5: DirectShow-Architektur

9

Der genannte Sachverhalt soll am Beispiel noch einmal verdeutlicht werden. Es soll eine AVI-Datei mit integriertem Video und Audio wiedergegeben werden. An erster Stelle benötigt man einen Source-Filter, der einen Datenstrom von einem Datenträger lesen kann. In Abbildung 6 ist dieser Filter am Anfang des Filter-Graphen zu sehen mit einem Output-Pin. Dieser Datenstrom muss anschließend in eine Video- sowie Audiospur aufgeteilt werden. Diesen Vorgang übernimmt der „AVI-Splitter“-Transform-Filter. Da das Video- und Audiomaterial in der AVI-Datei im komprimierten Format vorliegt, müssen weitere Dekompressions-Filter (Transform-Filter) eingefügt werden. Im Beispiel übernimmt der „DivX Decoder Filter“ die Dekompression des Videomaterials und der „MPEG Layer-3 Decoder“ die Dekompression der Audiospur. Im nächsten Schritt können weitere Transform-Filter in den Filter-Graph eingebaut werden (z.B.: „MV Rotate 90“-Filter (Video mit 90° Drehung) oder „Echo“-Filter). Abschließend stehen der „Video Renderer“-Filter sowie der „Default DirectSound Device“-Filter für die Präsentation von Video- sowie Audiomaterial zur Verfügung. Diese nutzen wie oben erwähnt die DirectX-Komponenten zur Präsentation der Multimediadaten.

Abbildung 6: Filter-Graph für Wiedergabe einer „AVI“-Datei. Der Programmablauf jeder DirectShow-Anwendung ist immer gleich und in folgende drei Schritte unterteilt (siehe Abbildung 7):

Abbildung 7: Programmablauf einer DirectShow-Anwendung

1) Applikation erstellt ein Objekt des Filter-Graph-Managers 2) Filter-Graph-Manager erstellt einen Filter-Graphen 3) Die Applikation gibt Steuerbefehle (z.B.: Start, Stop, Pause) an Filter-Graph-

Manager. Der Filter-Graph-Manager steuert den Filter-Graphen und sendet Events des Filter-Graphen (z.B.: Videodateiende erreicht) an die Anwendung.

Die Applikation kommuniziert nur mit dem Filter-Graph-Manager. Einzige Ausnahme ist

die Konfiguration der einzelnen Filter im Filter-Graph durch die Anwendung selbst.

10

2.1 Filter-Graph-Manager Wie in Abschnitt 2 angedeutet, ist der Filter-Graph-Manager das zentrale Objekt von DirectShow mit folgenden Aufgaben:

• Erstellung, Steuerung, Synchronisation von Filter-Graphen • Ereignisbehandlung (z.B.: Videodateiende erreicht)

Er fungiert als Zwischenstück zwischen Applikation und Filter-Graph. Implementiert als COM-Objekt stellt er eine große Anzahl an COM-Schnittstellen für seinen Aufgabenbereich zur Verfügung. Beispiele (siehe Abbildung 8):

• IGraphBuilder COM-Schnittstelle: stellt Methoden für die Filter-Graph Erstellung bereit (siehe 3.1)

• IFilterMapper2 COM-Schnittstelle: enthält Methoden für die Registrierung, Unregistrierung und Suche von Filtern

• IMediaControl COM-Schnittstelle: dient der Datenfluss-Kontrolle des Filter-Graphen (Start, Stop, Pause – Methoden)

Abbildung 8: Filter-Graph-Manager-Schnittstellen

11

3. Filter-Graphen Der Aufbau von Filter-Graphen kann im Abschnitt 2 nachgelesen werden.

3.1 Erstellung von Filter-Graphen Für die Erstellung von Filter-Graphen ist nur der Filter-Graph-Manager zuständig (siehe Abschnitt 2.1). Die Anwendung gibt lediglich Befehle zur Erstellung von Filter-Graphen über die Filter-Graph-Manager COM-Schnittstelle IGraphBuilder, mit den Hauptmethoden:

• IGraphBuilder::RenderFile(„Mediadateiname“) • IGraphBuilder::Render(OutputPin) • IGraphBuilder::Connect(OutputPin, InputPin)

Intelligent Connect: Hinter diesen Methoden verbirgt sich das so genannte „Intelligent Connect“. Dies bedeutet: Es bestehen drei Möglichkeiten einen Filter-Graph zu erstellen, wie in Abbildung 9 dargestellt ist.

Abbildung 9: „Intelligent Connect“ Vollautomatische Erstellung von Filter-Graphen: Die Anwendung ruft lediglich die Methode IGraphBuilder::RenderFile(…) des Filter-Graph-Managers, unter Angabe einer Datei welche abgespielt werden soll auf. Daraufhin erstellt der Filter-Graph-Manager einen kompletten Filter-Graph, indem er folgende Schritte durchläuft:

1) Der Filter-Graph-Manager ruft die Methode IGraphBuilder::AddSourceFilter(...) auf, welche einen passenden Source-Filter in den Filter-Graph einfügt.

2) Der Filter-Graph-Manager ruft die Methode IGraphBuilder::Render(Output-Pin) auf, wobei das Output-Pin des eingefügten Source-Filters als Übergabeparameter dient. Dieser Methodenaufruf bewirkt das Einfügen eines Rendering-Filters in den Filter-Graph. Durch die Angabe des Output-Pins kann der passende Rendering-Filter bestimmt werden.

3) Aufruf der Methode IGraphBuilder::Connect(Output-Pin, Input-Pin). Als Output-Pin-Übergabeparameter dient das Source-Filter-Output-Pin und das Rendering-Filter-Input-Pin wird als Input-Pin-Übergabeparameter verwendet. Somit wird eine Verbindung von Source-Filter und Rendering-Filter veranlasst. In den meisten Fällen kann man die beiden Pins nicht einfach verbinden, denn es werden noch weitere Zwischenfilter (Transform-Filter) benötigt. Wie diese Zwischenfilter gefunden werden, klärt der folgende Absatz

12

IGraphBuilder::Connect(OutputPin, InputPin): Diese Methode muss gesondert betrachtet werden, da für die Verbindung von Pins größtenteils verschiedene Zwischenfilter (Transform-Filter) benötigt werden. Als Beispiel stelle man sich einen Source-Filter, der nur unkomprimierte RGB-Bilder liefert und einen Video Rendering-Filter, der nur das YUV-Format versteht vor. Diese beiden Filter will man mittels IGraphBuilder::Connect(Output-Pin, Input-Pin) verbinden. Eine direkte Verbindung wäre nicht möglich. Es wird also ein Zwischenfilter (Transform-Filter) benötigt, der die Farbraumtransformation übernimmt. Folgender Algorithmus wird bei jedem Aufruf dieser Methode einmal oder mehrfach abgearbeitet:

1) Direkte Verbindung der Pins probieren; Kein Erfolg 2) 2) Filter aus dem Cache probieren; Kein Erfolg 3) Cache: Alle Filter die in einem

bestehenden Filter-Graph vorhanden waren und wieder entfernt worden sind, werden im Cache abgelegt. Nach zerstören des Filter-Graphen wird auch der Cache geleert.

3) unverbundene Filter im Filter-Graph probieren; Kein Erfolg 4) 4) Filter über Windows-Registrierung suchen und probieren; Jeder Filter muss vor der

Verwendung vom Anwender registriert werden und erhält einen Eintrag in der internen Windows-Betriebssystem-Registrierung. Die Filter sind in Kategorien unterteilt (Source-Filter, Transform-Filter, Rendering-Filter). Weiterhin erhält jeder Filter einen Major- und SubType, die angeben welche Media-Formate (z.B.: MajorType: RGB, SubType: RGB555) der Filter unterstützt.

Um Deadlocks zu vermeiden, wird nach einer gewissen Anzahl von Versuchen dieser

Algorithmus abgebrochen. Halbautomatische Erstellung von Filter-Graphen: Die gewünschten Filter werden manuell in den Filter-Graph eingefügt und die fehlenden Filter werden vollautomatisch ergänzt. Als Beispiel kann man sich folgendes Szenario vorstellen. Es soll eine Videodatei in Farbe wiedergegeben werden und das Bild soll aber in Graustufen dargestellt werden. An erster Stelle fügt man den vorhandenen Graustufen-DirectShow-Filter in den Filter-Graph ein. Im zweiten Schritt folgt der Aufruf von IGraphBuilder::RenderFile(„Videodateiname“). Aufgrund des oben genannten Algorithmus wird der Graustufen-Filter während der Erstellung des Filter-Graphen an eine passende Stelle vor den Video-Rendering-Filter eingebunden. Manuelle Erstellung von Filter-Graphen: Alle benötigten Filter werden manuell eingefügt und verbunden. Dynamic-Graph-Building: Der größte Teil der erhältlichen Filter unterstützt nur die Verbindung von Filtern bei gestopptem Filter-Graph. Abhilfe schafft das Dynamic-Graph-Building, was im Filter implementiert sein muss. Das Ziel ist während dem Filter-Graph-„Run“-Zustand den Filter-Graph manipulieren zu können. Dieses Thema soll an dieser Stelle nicht weiter behandelt werden, da kaum Filter mit dieser Unterstützung zu finden sind.

13

3.2 Filter-Verbindungsprotokolle In den folgenden drei Abschnitten soll geklärt werden welche Schritte notwendig sind, um zwei Filter miteinander zu verbinden. Die Verbindung der Filter vollzieht sich nur über die Pins der Filter. Pins sind als COM-Objekte implementiert und stellen verschiedene COM-Schnittstellen zur Verfügung.

3.2.1 MediaType-Vermittlung Der erste Schritt beim Verbindungsaufbau ist die MediaType-Vermittlung. Eine Verbindung zweier Filter ist nur dann möglich, wenn sie den gleichen Medien-Typ unterstützen. Medien-Typ: Der Medien-Typ wird durch die DirectShow AM_MEDIA_TYPE-Struktur beschrieben. Die Struktur enthält an erster Stelle einen Major- und SubType. Dabei legt der MajorType (siehe Abbildung 10 - orange dargestellt) fest, ob es sich um eine Video-, Audio-, oder beispielsweise Midispur handelt. Der SubType beschreibt den Medien-Typ genauer (siehe Abbildung 10 - blau dargestellt). Um den Medien-Typ noch detaillierter darzustellen, stehen für Video beispielsweise die VIDEOINFOHEADER- und BITMAPINFOHEADER-Struktur zur Verfügung, welche verschiedene Bildeigenschaften beinhalten. Für die detaillierte Beschreibung des Audiomaterials ist die WAVEFORMATEX-Struktur zuständig, die die Eigenschaften über das Audiomaterial speichert. Alle diese Strukturen werden in die AM_MEDIA_TYPE-Struktur eingebettet. Die Applikation ruft die Filter-Graph-Manager COM-Schnittstellen-Methode IGraphBuilder::Connect(…) auf. Daraufhin veranlasst der Filter-Graph-Manager den Austausch der AM_MEDIA_TYPE-Struktur der beiden Filter untereinander. Bei Übereinstimmung wird mit dem nächsten Verbindungsschritt in Abschnitt 3.2.2 fortgefahren.

Abbildung 10: MediaType-Vermittlung

14

3.2.2 Transport-Vermittlung Für den Datenaustausch über die Pins stehen verschiedene Transportprotokolle zur Auswahl (siehe Abbildung 11). Im zweiten Schritt des Verbindungsaufbaus muss zwischen den zwei Filtern ein Transportprotkoll ausgehandelt werden.

Abbildung 11: Transportprotkolle

Local-memory Transportprotokolle (am häufigsten verwendet): Im Push-Verfahren werden die Daten vom Output-Pin des vorhergehenden Filters an das Input-Pin des nachfolgenden Filters transportiert. Als Beispiel kann man sich eine Webcam vorstellen, welche die Daten in den Filter-Graph einspeist. Im Pull-Verfahren werden die Daten des Input-Pins vom nachfolgenden Filter vom Output-Pin des vorhergehenden Filters angefordert. Ein einfaches Beispiel ist die Wiedergabe einer AVI-Datei. Der benötigte AVI-Splitter-Filter (siehe Abbildung 6) arbeitet im Pull-Verfahren und fordert seine Daten vom vorhergehenden Filter (Dateilese-Filter) an. Kernel-Streaming Transportprotokoll: Informationen über die Kernel-Streaming Technologie können im Abschnitt 1.2 gefunden werden. Bei diesem Transportprotokoll werden lediglich Steuerinformationen über die Pins übertragen. Der Datenaustausch erfolgt direkt von Hardware zu Hardware im Kernel-Mode. Die verwendeten DirectShow-Filter stellen Abstraktionen der jeweiligen Hardware-Treiber dar. In Abbildung 11 ist ein Beispiel angegeben.

15

3.2.3 Speicherverwaltung-Vermittlung Der dritte und letzte Schritt beim Verbindungsaufbau besteht im Aushandeln eines Memory-Allocators (Speicherverwaltung) zwischen zwei Filtern. Die Übertragung der Daten von einem Filter zu einem anderen Filter basieret auf Media-Samples, die von einem Memory-Allocator verwaltet werden (siehe Abbildung 12 und Abschnitt 3.3.1). Der Memory-Allocator wird von den Pins der Filter zur Verfügung gestellt. Media-Sample: Ein Media-Sample ist ein COM-Objekt, welches einen Speicher (Memory-Buffer) verwaltet, in dem die Media-Daten (z.B.: Video-/Audiosamples) abgelegt werden. Für den Zugriff implementiert das Media-Sample die COM-Schnittstelle IMediaSample. Um feststellen zu können, welche Art von Media-Daten im Media-Sample enthalten sind, erhält jedes Media-Sample eine gefüllte AM_MEDIA_TYPE-Struktur, die mit der Methode IMediaSample::GetMediaType(AM_MEDIA_TYPE) abgerufen und mit IMediaSample::SetMediaType(AM_MEDIA_TYPE) gesetzt wird.

Abbildung 12: Speicherverwaltung-Vermittlung Auswahl des Memory-Allocators: Der Memory-Allocator verwaltet eine bestimmte Anzahl an Media-Samples und es befindet sich immer ein Memory-Allocator zwischen zwei Filtern. Der Algorithmus für die Auswahl des Memory-Allocators ist in Abbildung 12 (oberer Teil) zu finden. Wichtig ist, dass der Memory-Allocator immer vom Output-Pin gewählt wird und die Memory-Allocator-Anforderungen des Input-Pins berücksichtigt werden.

16

3.3 Datenfluss-Protokolle In einem Filter-Graph werden zwei verschiedene Arten von Daten transportiert:

• Media-Daten (z.B.: Video-/Audiosamples): in Downstream-Reihenfolge transportiert (Source-F. Rendering-F.)

• Kontroll-Daten: in Upstream-Reihenfolge transportiert (Rendering-F. Source-F.) Beispiele für Kontroll-Daten-Protokolle:

• End-of-stream-Protokoll: Definiert, wie die Filter die End-Of-Stream-Informationen erzeugen und verarbeiten und wie der Filter-Graph-Manager informiert wird.

• Flushing-Protokoll: Definiert, wie die Filter Daten durch den Filter-Graph flushen • Error detection and reporting-Protokoll: Definiert, wie Fehler vom Filter

gehandhabt und durch den Filter-Graph weitergereicht werden • Quality management-Protokoll: dynamische Anpassung der Datenrate im Filter-

Graph entsprechend der Laufzeit-Performance. Erhält ein Rendering-Filter zu viele oder zu wenige Daten, so kann er dies durch senden von Quality-Messages an die einzelnen Filter regulieren.

In den folgenden zwei Abschnitten werden das Media-Daten- und ein Kontroll-Daten-Protokoll vorgestellt.

3.3.1 Streaming-Protokoll Die Abbildung 13 beschreibt das Media-Daten-Datenfluss-Protokoll innerhalb eines Filter-Graphen anhand des Push-Models (siehe Abschnitt 3.2.2). In der Abbildung wird davon ausgegangen, dass die Filter erfolgreich verbunden sind und zwischen zwei Filtern ein Memory-Allocator gewählt ist. Weiterhin befindet sich der Filter-Graph im zweiten Durchlauf. Dies bedeutet, dass ein Media-Sample schon den Rendering-Filter erreicht hat und ein zweites Media-Sample vom Source-Filter gefüllt wird.

Abbildung 13: Media-Daten-Datenfluss-Protokoll im Filter-Graph

17

Ablauf-Algorithmus:

1) Der Source-Filter fordert ein Media-Sample vom Memory-Allocator an. 2) Dieses Media-Sample wird im Source-Filter befüllt. 3) Das Media-Sample wird an den Transform-Filter übermittelt. 4) Im Transform-Filter wird ein neues Media-Sample vom Memory-Allocator

angefordert. Zum gleichen Zeitpunkt geschieht Vorgang 1). 5) Die Media-Daten vom Media-Sample werden in das Media-Sample übertragen

(kopiert) und entsprechend manipuliert. Zum gleichen Zeitpunkt geschieht Vorgang 2).

6) Das Media-Sample wird wieder freigegeben und das Media-Sample wird an den Rendering-Filter übergeben. Zum gleichen Zeitpunkt geschieht Vorgang 3).

7) Im Rendering-Filter wird das erhaltene Media-Sample präsentiert. Zum gleichen Zeitpunkt geschieht Vorgang 4).

Der angegebene Algorithmus basiert auf der Verwendung eines Transform-Filters, in dem die Media-Daten kopiert werden müssen, aufgrund der verschiedenen verwendeten Memory-Allocator (siehe Punkt 5). Es gibt viele Anwendungsfälle, in denen die Media-Daten aber nicht kopiert werden sollen. Dafür steht der TransInPlace-Transform-Filter zur Verfügung (siehe Abbildung 13). Dieser Filter kann jedoch nur eingesetzt werden, wenn der Memory-Allocator am Input-Pin auch am Output-Pin verwendet wird. Dies bedeutet, dass der vorhergehende Filter und der nachfolgende Filter den gleichen Allocator verwenden müssen. In den meisten Fällen ist dies problemlos möglich. Jedoch gibt es Rendering-Filter, die nur ihren eigenen implementierten Allocator akzeptieren. In solchen Fällen besteht keine Chance der TransInPlace-Transform-Filter-Verwendung.

3.3.2 Control-Protokoll In diesem Kapitel wird das Kontroll-Daten-Control-Protokoll vorgestellt. Es beschreibt die Zustandsübergange (z.B.: Run to Stop) im Filter-Graph.

Abbildung 14: Control-Protkoll Filter können drei verschiedene Zustände annehmen: Run, Pause und Stop.

18

Der Pause-Zustand dient der Datenpufferung im Filter-Graph, damit auf ein Run-Kommando sofort reagiert werden kann. Alle Zustandsübergange werden vom Filter-Graph-Manager kontrolliert. Ruft eine Anwendung die Methoden IMediaControl::Run, IMediaControl::Pause oder IMediaControl::Stop vom Filter-Graph-Manager auf (siehe Abbildung 14), so leitet der Filter-Graph-Manager diese Zustandübergange an alle Filter im Filter-Graph weiter. Der Übergang vom Stop- in den Run-Zustand erfolgt immer über den Pause-Zustand (siehe Abbildung 14). Für die meisten Filter ist der Run- und Pause-Zustand identisch. Folgender Filter-Graph soll betrachtet werden: Source->Transform->Rendering. Es wird angenommen, dass der Source-Filter keine Live-Capture-Quelle ist. Wird der Source-Filter in den Pause-Zustand versetzt, so erzeugt dieser einen Streaming-Thread, welcher neue Daten generiert und diese so schnell wie möglich in Media-Samples schreibt. Anschließend transportiert der Thread die Media-Samples im „Push“-Verfahren (siehe Abschnitt 3.2.2) zum Transform-Filter. Während sich der Rendering-Filter im Pause-Zustand befindet, wartet er auf ein Media-Sample. Sobald er das erste Media-Sample erhält, blockiert er bis er in einen anderen Zustand versetzt wird. Damit ist der Filter-Graph gepuffert und bereit gestartet zu werden. Der Source- und Transform-Filter ignorieren den Zustandsübergang von Pause zu Run, da der Rendering-Filter den Streaming-Thread sowieso nach Erhalt des ersten Media-Samples blockiert. Wird der Rendering-Filter vom Pause- in den Run-Zustand versetzt, so wird die Blockierung aufgehoben und im ersten Schritt erfolgt die Verarbeitung des Media-Samples, welches im Pause-Zustand gehalten wurde. Anschließend wird jedes Media-Sample entsprechend seiner Präsentationszeit verarbeitet (siehe Abschnitt 3.4). Live-Quellen (z.B.: Webcams,…) bilden eine Ausnahme, denn eine Live-Quelle produziert keine Samples im Pause-Zustand, sondern nur im Run-Zustand. Damit wird auch keine Datenpufferung im Pause-Zustand benötigt. Wird ein Filter in den Stop-Zustand versetzt, so werden alle folgenden Media-Samples, die der Filter erhält verworfen und die Pins der Filter geben die Media-Samples vom Memory-Allocator frei. Bei Source-Filtern würde zusätzlich der Streaming-Thread und weitere benötigte Threads freigegeben werden. Zustandsübergänge: Der Filter-Graph-Manager sendet die Zustandsübergänge in Upstream-Reihenfolge (siehe Abschnitt 3.3 / Abbildung 14). Die Reihenfolge ist dabei wichtig, um den Verlust von Media-Samples zu vermeiden und Deadlocks im Filter-Graph auszuschließen. Die entscheidensten Zustandsübergänge sind zwischen Pause und Stop: Stop- zu Pause-Zustand: Nachdem jeder Filter in den Pause-Zustand versetzt ist, ist er zum Empfang von neuen Media-Samples bereit. Der Source-Filter ist immer der Letzte, der die Pause-Zustandsmitteilung erhält. Er beginnt einen Streaming-Thread zu erzeugen und startet anschließend mit dem Transport neuer Media-Samples. Da sich alle anderen Filter im Pause-Zustand befinden, wird kein Media-Sample verworfen. Der Filter-Graph-Manager wartet solange, bis jeder Rendering-Filter ein Media-Sample erhalten hat (mit Ausnahme der Live-Quellen, wie oben beschrieben). Pause- zu Stop-Zustand: Wird ein Filter in den Stop-Zustand versetzt, gibt er alle Media-Samples frei, die er noch hält. Dadurch wird die Blockade in den Upstream-Filtern, die auf Media-Samples warten aufgehoben. Es könnte passieren, dass der Upstream-Filter noch einige zusätzliche Media-Sample sendet, bevor er das Stop-Kommando bekommt, aber der Downstream-Filter würde diese verwerfen, da er sich schon im Stop-Zustand befindet.

19

3.4 Synchronisation In diesem Abschnitt werden die Synchronisationsmechanismen von DirectShow näher beleuchtet.

Abbildung 15: Synchronisation im Filter-Graph Die Funktionsweise der Synchronisation soll am Beispiel (Abbildung 15) näher verdeutlicht werden. Die Abbildung 15 zeigt die Wiedergabe einer AVI-Datei mit komprimiertem Video und Audio (siehe Abbildung 6) und die verwendeten Threads sind mit einem roten, blauen und grünen Pfeil markiert. Der Source- und Parser-Filter transportieren die Media-Daten im Pull-Verfahren (siehe Abschnitt 3.2.2) mit Hilfe eines Threads (roter Pfeil), wobei der Parser-Filter Media-Daten vom Source-Filter anfordert. Die angeforderten Media-Daten werden im Parser-Filter in eine Video- und Audiospur aufgesplittet und danach über zwei Output-Pins an die Dekoder-Filter mittels Push-Verfahren (siehe Abschnitt 3.2.2) gesendet. Für den Transport der Video- und Audiodaten werden jeweils ein Thread (blauer und grüner Pfeil) zur Verfügung gestellt, damit die Dekompression in den Dekompressions-Filtern und die Präsentation der Daten in den Rendering-Filtern parallel abgearbeitet werden kann. Würde man den Filter-Graph in Abbildung 15 ohne jegliche Synchronisationsmechanismen starten, so würde das System die Media-Daten so schnell wie möglich verarbeiten. Dieser Effekt ist in einigen Fällen sogar erwünscht, wenn man beispielsweise eine WAV-Datei, so schnell wie möglich in MP3 umkonvertieren möchte. Für die Wiedergabe einer Media-Datei müssen aber unbedingt Synchronisationsmechanismen verwendet werden, damit das Video- und Audiomaterial synchron wiedergegeben werden kann und die Abspielgeschwindigkeit eingehalten wird. Timestamps: Für die Synchronisation werden Timestamps verwendet. Ein Timestamp besteht aus einem Startzeitpunkt (timeStart), an dem das Media-Sample im Rendering-Filter präsentiert werden soll und einem Endzeitpunkt (timeEnd), der angibt zu welchem Zeitpunkt das Media-Sample wieder freigegeben werden kann. timeEnd minus timeStart ergeben die Präsentationsdauer eines Media-Samples. timeStart und timeEnd werden jeweils in einer 64-Bit-Variablen (REFERENCE_TIME) in 100 Nanosekunden-Einheiten gespeichert. Der Timestamp wird mit der Methode IMediaSample::SetTime(…) an das Media-Sample (siehe Abschnitt 3.2.3:

20

Media Sample) übertragen und wird über die Methode IMediaSample::GetTime(…) abgerufen. Für die Generierung der Timestamps sind meist die Source-Filter zuständig. Am Beispiel (Abbildung 15) erledigt dies der Parser-Filter. Um einen Timestamp erzeugen zu können, wird eine Reference-Clock benötigt. Reference-Clock/Reference-Time/Stream-Time: Eine Reference-Clock stellt einen sehr genauen Zeitgeber zur Verfügung. Dieser Zeitgeber ist größtenteils in der Hardware implementiert (z.B.: Soundkarte). Soll ein Filter-Graph mit Hilfe von Synchronisationsmechanismen abgespielt werden, so muss der Filter-Graph vor der Wiedergabe eine zuverlässige Reference-Clock zur Verfügung stellen. Ein Filter-Graph kann nur über eine Reference-Clock verfügen.

Abbildung 16: manuelle Reference-Clock-Auswahl Die Auswahl der Reference-Clock kann automatisch oder (wie in Abbildung 16 dargestellt) manuell geschehen. Für die manuelle Auswahl stehen drei Möglichkeiten zur Verfügung:

• Die Applikation implementiert die Reference-Clock und stellt sie dem Filter-Graph zur Verfügung.

• Die Reference-Clock ist in einem Filter des Filter-Graphen implementiert. • Der Filter-Graph soll ohne Synchronisationsmechanismen arbeiten und die Media-

Daten so schnell wie möglich verarbeiten. Ist beim Start des Filter-Graphen keine Reference-Clock angegeben, so sucht der Filter-Graph automatisch eine passende Reference-Clock nach folgendem Algorithmus:

• Filter-Graph-Manager sucht Reference-Clock-Implementationen in Filtern in Upstream-Reihenfolge (beginnend bei Rendering-Filter)

• erste gefundene Reference-Clock (in Filter) wird übernommen • keine Reference-Clock gefunden Filter Graph Manager stellt interne Reference-

Clock auf Basis der System-Uhrzeit zur Verfügung Die von der Reference-Clock zur Verfügung gestellte Zeit wird als Reference-Time bezeichnet, die immer aufsteigend und niemals rückwärts läuft. Innerhalb eines Filter-Graph wird jedoch nur die Stream-Time, welche relativ zum letzten Filter-Graph-Start definiert ist verwendet (siehe Abbildung 15). Beispiel: Wenn ein Media-Sample ein timeStart von t zugewiesen ist, so sollte das Sample zur Stream-Time t vom Rendering-Filter präsentiert werden. Nachdem der Parser-Filter im Beispiel (siehe Abbildung 15) anhand einer Reference-Clock den Timestamp erstellt hat, wird das Media-Sample über den Dekompressor-Filter zum Rendering-Filter transportiert. Der Rendering-Filter liest anschließend den Timestamp vom erhaltenen Media-Sample aus und arbeitet den angegebenen Algorithmus (Abbildung 15 rechts) ab.

21

4. Beispiel Sourcecode für Wiedergabe einer MPEG-Datei (vollautomatische Filter-Graph Erstellung): //Schnittstellenzeiger definieren 1: IGraphBuilder *pGraph; 2: IMediaControl *pMediaControl; 3: IMediaEvent *pEvent; 4: CoInitialize(NULL); //COM-Laufzeitumgebung initialisieren //Filter Graph Manager Objekt erstellen+IGraphBuilder Schnittstellenzeiger erzeugen 5: CoCreateInstance(CLSID_FilterGraph, …, …,IID_IGraphBuilder, (void **)&pGraph); 6: pGraph->RenderFile(„Beispiel.mpg“, NULL); //Graph vollautomatisch erstellen 7: pGraph->QueryInterface(IID_IMediaControl, (void **)&pMediaControl); 8: pMediaControl->Run(); //Graph starten //Warten auf Beendigung des Graphen 9: pGraph->QueryInterface(IID_IMediaEvent, (void **)&pEvent); 10: long evCode; pEvent->WaitForCompletion(INFINITE, &evCode); 11: pMediaControl->Release(); pEvent->Release(); pGraph->Release(); //Schnittstellenzeiger freigeben 12: CoUninitialize(); //COM-Laufzeitumgebung freigeben In den Zeilen 1-3 werden einige COM-Schnittstellenzeiger definiert. Die folgende Methode CoInitialize(…) (Zeile 4) dient der Initialisierung der COM-Laufzeitumgebung und muss bei jeder COM-Anwendung, vor der Benutzung der COM-Technologie aufgerufen werden. In Zeile 5 erfolgt die Erstellung des Filter-Graph-Manager-Objekts. Zusätzlich wird der Standard-COM-Schnittstellenzeiger IGraphBuilder des Filter-Graph-Managers erzeugt. Durch Aufruf der Methode pGraph->RenderFile(„Beispiel.mpg“,NULL) (Zeile 6) der COM-Schnittstelle IGraphBuilder, wird der Filter-Graph-Manager veranlasst, einen Filter-Graph entsprechend der wiederzugebenden Datei vollautomatisch zu erstellen. Um den Filter-Graph steuern zu können, wird die ImediaControl-COM-Schnittstelle benötigt. Diese wird über die IgraphBuilder-COM-Schnittstelle mittels pGraph->QueryInterface(IID_IMediaControl, (void **)&pMediaControl) (Zeile 7) erstellt. Der Filter-Graph wird über die erzeugte IMediaControl-COM-Schnittstelle (Zeile 8) gestartet. Die MPEG-Datei soll anschließend bis zum Ende abgespielt werden. Um das Dateiende-Ereignis zu erhalten wird die COM-Schnittstelle IMediaEvent benötigt. Diese wird ebenfalls über die IgraphBuilder-COM-Schnittstelle mittels pGraph->QueryInterface(IID_IMediaEvent, (void **)&pEvent) (Zeile 9) erhalten. In der folgenden Zeile wird durch den Methodenaufruf pEvent->WaitForCompletion(INFINITE, &evCode) der Applikationsthread solange blockiert, bis die MPEG-Datei fertig wiedergegeben ist. In Zeile 11 werden die in Zeile 1-3 definierten COM-Schnittstellenzeiger wieder freigegeben. Die COM-Laufzeitumgebung muss ebenfalls freigegeben werden, was in Zeile 12 erledigt wird.

22

5. Zusammenfassung Im Rahmen der vorliegenden Arbeit wurden die wichtigsten Grundlagen der Multimediaschnittstelle DirectShow gegeben. Darunter fallen die Entstehung und die Hauptaufgaben von DirectShow sowie die Architektur und die Hauptbestandteile, den Filter-Graph-Manager und damit verbunden die Erstellung, Kontrolle und Synchronisation von Filter-Graphen. Aufgrund des enormen Umfangs von DirectShow, konnten einige Themengebiete (z.B.: DES (DirectShow Editing Service)) nur grob umrissen werden. Die Entwicklung eigener DirectShow-Filter stellt ein sehr interessantes Thema dar und hilft DirectShow wesentlich besser zu verstehen. Leider konnte dieser Teil nicht behandelt werden, da es den Rahmen dieser Arbeit sprengen würde. DirectShow löst die alte VFW-Multimediaschnittstelle ab und bietet als neue Multimediaschnittstelle von Microsoft viele Vor- und auch einige Nachteile:

Vorteile Nachteile

• gut dokumentiert • modulare Struktur • wiederverwendbare Komponenten

(Filter)

• abhängig von Microsoft-Betriebssystemen

• Kenntnisse in der Windows-Programmierung notwendig

6. Quellen Offline-Literatur:

• Programming Microsoft DirectShow for Digital Video and Television / Mark D. Pesce.

• Audio-,Video- und Grafikprogrammierung / Kai Bruns, Benjamin Neidhold • DirectShow-SDK Dokumentation • Microsoft MSDN-Bibliothek

Online-Literatur:

• http://www.gdcl.co.uk/ • http://www.jmcgowan.com/avi.html • Suchmaschinen (Google) / Internet

23