Inhaltsverzeichnis

1  Einleitung  1

1.1  Ziel  1

1.2  Inhalt  5

2  Verwandte Projekte und Systeme  6

2.1  DirectX  6

2.1.1  Übersicht DirectX  6

2.1.2  Übersicht DirectShow  7

2.1.3  Formate in DirectShow  8

2.2  GStreamer  10

2.2.1  Übersicht GStreamer  10

2.2.2  GStreamer und Formate  10

2.3  Digital Media Library  12

2.3.1  Übersicht Digital Media Parameters  12

2.4  Multimedia-Heimnetzwerke  14

2.4.1  HAVi  14

2.4.2  Übersicht HAVi  14

2.4.3  Formate in HAVi  15

2.5  Ansätze aus der Forschung  16

3  Das N-MMProjekt  18

3.1  Übersicht  18

3.1.1  N-MMKnoten  18

3.1.2  Jacks  19

3.1.3  Der Multimedia-Datenflußgraph  19

4  Formatdefinition  21

4.1  Formatklassifikation  21

4.2  Formatspezifikation  23

4.2.1  Konzept der Formatspezifikation  23

4.2.2  Datentypen  23

4.3  Modellierung von Abhängigkeiten  25

4.4  Arten von Knoten  25

4.5  Intersection-Formate  28

4.6  Formatbewertung  29

4.6.1  Default-Formate  29

i

INHALTSVERZEICHNIS

4.6.2  Gewichtungsmodell  29

4.6.3  Kostenmodell  31

5  Formatverhandlung  34

5.1  Ziel der Formatverhandlung  34

5.2  Übersicht über die Formatverhandlung  35

5.3  Spezifikation einer Anfrage  36

5.4  Formatverhandlung  36

5.4.1  Aufbau des Verhandlungsgraphen  37

5.4.2  Das Kürzeste-Wege-Problem  43

5.4.3  SSSP  44

5.4.4  Dijkstra-Algorithmus  45

5.4.5  Die Formatverhandlung nach Kosten  46

5.4.6  Die Formatverhandlung nach Qualität  47

5.4.7  Bearbeitung des Verhandlungsgraphen  47

5.4.8  Der Abhängigkeitsgraph  51

5.5  Aufbau des Multimedia-Datenflußgraphen  55

5.6  Zusammenfassung  55

6  Konzeption und Implementierung  57

6.1  Implementierung der Formate  57

6.2  Implementierung des Algorithmus  60

6.3  Anwendungsprogrammierung  60

6.4  Laufzeit  61

6.5  Ein Programm zum Erstellen von Formatdefinitionen  61

7  Einsatzbeispiel  63

7.1  Definition der Formate  63

7.2  Aufbau des Usergraphen  64

7.3  Aufbau des Verhandlungsgraphen  65

7.4  Aufbau des Abhängigkeitsgraphen  65

7.5  Ergebnis  66

8  Zusammenfassung und Ausblick  67

8.1  Erzielte Ergebnisse  67

8.2  Erweiterungsvorschläge  68

8.2.1  Modellierung von Abhängigkeiten  68

8.2.2  Kostenmessung  68

8.2.3  Einsatz anderer Algorithmen  68

8.2.4  Berücksichtigung von Netzwerkengpässen  69

8.2.5  Eine detailliertere Kostenbetrachtung  69

A  Formatklassifikation  71

B  Formatspezifikation  72

C  Beispiele für Formate  73

ii

Kapitel 1

Einleitung

1.1 Ziel

Fortschritte in der Computer- und Kommunikationstechnologie haben in den vergangenen Jahren die Integration von digitalem Audio und Video auf fast jedem handelsüblichen Computer möglich gemacht. Die unter dem Schlagwort Multimedia entstandenen Anwendungen umfassen dabei auch rechnerübergreifende Multimedia-Anwendungen wie z. Bsp. Videokonferenzsysteme oder Video-on-Demand, und förderten das Interesse an verteilten Multimedia-Systemen seitens der Industrie, der Forschung und verschiedener Standardisierungskomitees. HAVi (Home Audio/Video Interoperability) [35], GStreamer [57] oder die Corba Multimedia System Services [13] stellen nur einige Beispiele dar.

In die Riege solcher verteilter Multimedia-Systeme reiht sich auch das Netzwerk Multimedia (NMM) Projekt [46] ein, das als Ziel eine netzwerkintegrierte Multimedia-Infrastruktur für Linux verfolgt. Im Unterschied zu traditionellen Multimedia-Infrastrukturen wie Miscrosofts DirectX [43] oder Apples Quicktime [2, 5, 6], die auf einem PC-zentrierten Ansatz beruhen, ist das Netzwerk im NMM-Projekt zentraler Bestandteil der Architektur. Dadurch ist es möglich, Geräte, die nicht am eigenen Computer angeschlossen sind, über das Netzwerk zu kontrollieren. Abbildung 1.1 aµ zeigt ein

Abbildung 1.1: Beispiel für eine Anwendung im NMM-Projekt

1

Abbildung 1.2: Der XMMS Player für Linux [1] zeigt detaillierte Angaben über die abgespielte Datei.

Beispiel für einen solchen Ansatz: Die im Netzwerk verfügbare Kamera kann von einem anderen Computer genutzt werden. Der Ausdruck „Geräte“ bezeichnet nicht notwendigerweise nur physikalische Geräte wie eine Kamera, sondern auch Softwarekomponenten mit Implementierungen von Kompressionsalgorithmen, Netzwerkprotokollen und Konvertierungsroutinen. All diese „Geräte“ werden unter dem Begriff NMM-Knoten zusammengefaßt. Um einen Anwendungsfall wie in Abbildung 1.1 zu realisieren, wird ein sogenannter Multimedia-Datenflußgraph aufgebaut, der alle beteiligten NMM-Knoten verknüpft und den Fluß des Datenstroms definiert (s. Abbildung 1.1 b).

Einer der wichtigsten Aspekte dieses Themenkomplexes und damit auch die Thematik dieser Arbeit, besteht in einer intuitiven und zugleich eindeutigen Definition der Formate im NMM-Projekt. Unter einem Format versteht man dabei die beschreibenden Metadaten eines Datenstroms zwischen den NMM-Knoten in dem Datenflußgraph. Diese Metadaten beinhalten Eigenschaften der Datenströme wie z. Bsp. Auflösung, Farbraum oder Bildwiederholrate.

Abbildung 1.2 zeigt anhand eines Beispiels, wie ein solches Format eines Multimedia-Datenstroms aussehen könnte. Zu sehen ist ein Medienwiedergabeprogramm, der XMMS (X MultiMedia System) Player [1] für Linux, das Informationen über die abgespielte Datei anzeigt. Zu der Angabe, daß es sich dabei um ein MPEG1 Layer3 Format handelt, gehören noch Informationen über die Samplerate, die Bitrate und die Anzahl der Kanäle. Ziel dieser Arbeit besteht jetzt darin, alle relevanten Informationen der Formate eindeutig zu definieren und in einer hierarchischen Struktur übersichtlich einzuordnen. Hierzu werden die Formate in einem ersten Schritt in Kategorien eingeteilt, die nach intuitiven Gesichtspunkten gewählt und für den Anwender einfach zu überschauen sind (z. Bsp. Audio oder Video). Anschließend erfolgt eine genaue Definition mit Angabe aller notwendigen Eigenschaften mit entsprechender Ausprägung (z. Bsp. Auflösung: 1024 x 768).

Auf dieser Formatdefinition aufbauend soll ein Verfahren, die sogenannte For-matverhandlung entworfen werden, die die in einem Anwendungsfall spezifizierten NMM-Knoten automatisch zu einem Multimedia-Datenflußgraphen verbindet. Gene-

1.1. Ziel

rell lassen sich nur NMM-Knoten miteinander verbinden, deren Formate zusammenpassen. An dieser Stelle setzt die Formatverhandlung an und ermittelt gültige, zwischen allen Verbindungen passende Formate innerhalb des Multimedia-Datenflußgraphen. Falls keine mögliche Verbindung ermittelt werden kann, wird mit Hilfe eines Algorithmus versucht, zusätzliche NMM-Knoten in dem Datenflußgraphen zu integrieren, die durch Umwandlung von Formaten eine Verbindung zwischen den Knoten ermöglichen. Das Beispiel aus Abbildung 1.1 verdeutlicht dieses Konzept: Um einen Multimedia-Datenflußgraphen zwischen der Kamera und dem Display aufzubauen, muß ein weiterer Knoten integriert werden, der das Format der Kamera in ein von dem Display unterstütztes Format umwandelt.

Existierende Systeme besitzen einen solchen Mechanismus der Formatverhandlung nicht: Sie erfordern entweder die Angabe aller vom Anwender benutzten Geräte in dem Datenflussgraphen oder besitzen nur eine einfache Heuristik, um fehlende Komponenten zu ergänzen.

Die Formatverhandlung, die in dieser Arbeit entwickelt wurde, baut, im Gegensatz zu bisher existierenden Systemen, den Multimedia-Datenflußgraphen mit den eventuell zu ergänzenden Komponenten nicht Schritt für Schritt, sondern unter der Berücksichtigung der globalen Optimierungskriterien Qualität und Kosten auf. Dabei versteht man unter der Qualität bei Formaten Angaben, die qualifizierende Aussagen über die einzelnen Werte der Eigenschaften eines Formates zulassen. Beispielsweise kann die Auflösung der Kamera aus Abbildung 1.1 mit Werten 1024 x 768 als qualitativ besser gewertet werden als eine Auflösung von 800 x 600. Mit Kosten wird der allgemeine Ressourcenverbrauch (z. Bsp. Prozessorauslastung), der mit dem Einsatz eines bestimmten Formates auf einem Rechner verursacht wird, bezeichnet. Ergebnis der Formatverhandlung ist ein auf Formate konfigurierter Multimedia-Datenflußgraph mit allen spezifizierten und zusätzlich integrierten NMM-Knoten, die den geforderten Anwendungsfall realisieren kann.

Der Ansatz, der in dieser Arbeit verwendet wird, um das Problem der Format-verhandlung zwischen den NMM-Knoten zu lösen, basiert auf der Modellierung eines Graphen, in dem die NMM-Knoten abgebildet werden. Mit Hilfe einer modifizierten Version des Dijkstra-Algorithmus [30] für das Kürzeste-Wege-Problem wird in diesem Graphen die bestmögliche Verbindung zwischen zwei NMM-Knoten ermittelt (je nach Qualitäts- oder Kostenkriterien) und weitere benötigte NMM-Knoten automatisch gefunden und integriert. Ausgehend von diesem Graphen wird anschließend der Multimedia-Datenflußgraph aufgebaut. Die Formatverhandlung läuft in drei Schritten ab:

1. Ausgangspunkt einer Formatverhandlung ist eine Anfrage, die von einem Anwender oder einer Anwendung gestellt wird. Alle gewünschten Geräte d. h. NMM-Knoten werden in dieser Anfrage spezifiziert.

2. Aus der Anfrage abgeleitet wird ein Graph, der alle NMM-Knoten enthält. Mittels des Dijkstra-Algorithmus wird eine gültige Lösung nach Qualitäts- oder Kostenkriterien ermittelt und, falls notwendig, werden weitere Knoten automatisch integriert.

3. Anschließend wird der Multimedia-Datenflußgraph mit den zwischen den Kno-

ten ermittelten Formaten aufgebaut und die NMM-Knoten miteinander verbunden.

Zusammenfassend sollen in dieser Arbeit folgende Punkte behandelt werden: ¯ Ein intuitiver und eindeutiger Mechanismus zur Definition der unterstützten For-

mate im NMM-Projekt. Ein Format beschreibt dabei die Eigenschaften eines Datenstroms zwischen den NMM-Knoten.

¯ Auf der Formatdefinition aufbauend soll die Formatverhandlung entwickelt wer-

den, die einen Aufbau des Multimedia-Datenflußgraphen für einen Anwendungsfall erleichtert. Die NMM-Knoten werden dabei auf untereinander passende Formate konfiguriert.

¯ Passen die von einer Anwendung oder vom Anwender spezifizierten Geräte auf-

grund ihrer Formate nicht in dem Datenflußgraphen zusammen, soll die Format-verhandlung überprüfen, ob sich über zusätzliche NMM-Knoten, die die nicht passenden Formate umwandeln, eine Verbindung erzielen läßt. ¯ Stehen mehrere mögliche Formate für eine Verbindung zur Auswahl, soll eine

Entscheidung über das verwendete Format bezüglich eines noch zu definierenden Kosten- oder Qualitätsmaßes getroffen werden. ¯ Die Formatverhandlung endet mit einer Verbindung der NMM-Knoten in einem

Multimedia-Datenflußgraphen über die ermittelten Formate.

Die Abbildung 1.3 verdeutlicht die oben aufgeführten Punkte für den allgemeinen Fall einer Multimedia-Anwendung: Der Anwender sucht sich aus einer Reihe von gegebenen Geräten ein oder mehrere für seinen Anwendungsfall geeignete Geräte aus, z. Bsp.

eine Kamera. Vorraussetzung hierfür ist eine globale Instanz, die Registry, die Informationen über alle im NMM-Projekt registrierten NMM-Knoten enthält. Danach kann er sich die Eigenschaften dieses Gerätes ansehen. Dieses entspricht dem ersten Ziel dieser Arbeit, einem intuitiven und eindeutigen Mechanismus zur Formatdefinition. Der Anwender stellt dann Anfragen an die Formatverhandlung (Punkt 2). An dieser Stelle greift die Formatverhandlung ein (Punkt 3) und überprüft anhand der Formate, ob die spezifizierten NMM-Knoten sich miteinander verbinden lassen. Bei Bedarf werden weitere NMM-Knoten ermittelt, die durch Umwandlung von Formaten eine Verbindung ermöglichen. Zusätzlich können Qualitäts- oder Kostenmerkmale bei der Ermittlung einer Lösung berücksichtigt werden. Wird ein Ergebnis gefunden, können die Geräte des Multimedia-Datenflußgraphen miteinander verbunden (Punkt 4) und anschließend gestartet werden (Punkt 5).

1.2 Inhalt

Kapitel 2 gibt einen Überblick über einige mit dem NMM-Projekt verwandte Systeme und Projekte und geht besonders auf die dort definierten Formate und, soweit vorhanden, die Formatverhandlung ein. Kapitel 3 gibt eine kurze Einführung in das NMM-Projekt und stellt die zum Verständnis dieser Arbeit notwendigen Konzepte vor. Kapitel 4 führt einen Mechanismus zur Formatdefinition ein, der eine eindeutige und intuitive Definition der Formate ermöglicht. Im weiteren Verlauf dieses Kapitels wird ein Kosten- und Qualitätsmodell entwickelt, welches im Hinblick auf die Format-verhandlung Aussagen über die Qualität und die verbrauchten Ressourcen ermöglicht. Die Formatverhandlung, das zentrale Thema der vorliegenden Arbeit, wird in Kapitel 5 behandelt. Basierend auf der Formatdefinition wird ein Graphenmodell entwickelt, mit dessen Hilfe die oben genannten Probleme gelöst werden können. Der grundlegende Graphenalgorithmus wird vorgestellt und an das Modell der Formatdefinition angepaßt.

Kapitel 6 geht auf die wichtigsten Aspekte der Implementierung des Systems ein und stellt die verwendeten Technologien vor. Kapitel 7 zeigt anhand eines Beispiels, wie die entwickelte Formatdefinition und Formatverhandlung im NMM-Projekt eingesetzt wird. Kapitel 8 faßt die aus dieser Arbeit hervorgegangenen Resultate noch einmal zusammen und zeigt mögliche Erweiterungen des gewählten Ansatzes auf. Anhang A, B und geben einen Überblick über die zum aktuellen Zeitpunkt des Projektes verwendeten Formate und Parameter.

5

Kapitel 2

Verwandte Projekte und Systeme

Im folgenden wird ein Überblick über die dem NMM-Projekt verwandten Systeme und Projekte gegeben, die die vorliegende Arbeit beeinflußt haben. Im einzelnen sind dies Microsoft DirectShow, die Digital Media Library von SGI und GStreamer. Stellvertretend für eine Reihe von Multimedia-Heimnetzwerken wird ein Überblick über HAVi gegeben.

Neben einer kurzen Übersicht über diese Systeme wird vor allem auf die zentrale Frage dieser Arbeit, eine intuitive und eindeutige Formatdefinition und einer Format-verhandlung, eingegangen. Ein kurzer Einblick in Ansätze für eine Formatverhandlung aus der Forschung schließt das Kapitel.

2.1 DirectX

DirectX [43, 48] ist eine von Microsoft entwickelte Multimedia-Infrastruktur für Win-dows-Plattformen, die eine breite Unterstützung für fast alle Arten von Multimedia-Geräten bietet. DirectX entstand mit der Einführung von Windows 95 und liegt mittlerweile in der Version 8.0 für alle aktuellen Windowsversionen vor.

2.1.1 Übersicht DirectX

Die von DirectX zur Verfügung gestellten Schnittstellen bieten einerseits einen abstrakten Zugriff auf Low-Level-Hardware-Funktionen, auch als DirectX Foundation bezeichnet, andererseits darauf aufbauende High-Level-Dienste, der DirectX Media Layer, der zur generellen Verarbeitung von Multimedia-Daten dient, an. Abbildung 2.1 zeigt die Komponenten beider Ebenen.

Die DirectX Foundation umfaßt die Schnittstellenspezifikation für folgende Arten von Hardware-Geräten:

¯ DirectX Graphics mit DirectDraw für Funktionen zur 2D-Grafikausgabe und

Direct3D für dreidimensionale Darstellungen,

¯ DirectX Audio mit DirectSound und DirectMusic für die Wiedergabe von Au-

diodaten und

¯ DirectInput für den Zugriff auf Benutzerinteraktionsgeräte wie Maus, Tastatur

oder Joystick.

6

Abbildung 2.1: Die Microsoft DirectX API ist unterteilt in Low-Level-Schnittstellen zur Ansteuerung von Hardware (DirectX Foundation) und in darauf aufbauende High-Level-Dienste (DirectX Media Layer).

Aufbauend auf diesen Low-Level-Funktionen bietet der DirectX Media Layer zusätzliche High-Level-Dienste zur generellen Verarbeitung von Multimedia-Daten, wie Animation, Streaming ¹ und Synchronisation, an. Hierfür enthält der DirectX Media Layer die Komponenten

¯ DirectShow für die Wiedergabe oder das Aufnehmen von Multimedia-Daten-

strömen,

¯ DirectAnimation zur Bildung von Animationen aus verschiedenen Medientypen

(Bilder, Musik etc.), ¯ Direct3D Retained Mode für 3D-Umgebungen und

¯ DirectPlay für Multiplayer Netzwerk-Spiele.

Nachfolgend wird in dieser Arbeit nur eine Übersicht über DirectShow gegeben. Eine detaillierte Betrachtung aller Komponenten findet sich beispielsweise in [43].

2.1.2 Übersicht DirectShow

Das Microsoft DirectShow SDK (Software Developer Kit) ermöglicht Softwareentwicklern Zugriff auf DirectShow Dienste zum Abspielen, Konvertieren und Aufnehmen von Multimedia-Datenströmen. Die Palette der unterstützten Formate reicht dabei von verschiedenen Streaming-Formaten, z. Bsp. Advanced Streaming Format (ASF), Video-Formaten wie Motion Picture Experts Group (MPEG) bis zu einer großen Anzahl an Audio-Formaten wie MPEG Audio Layer-3 (MP3). DirectShow basiert auf einem modularen System bestehend aus verknüpfbaren Komponenten, welche Filter genannt werden und in einem sogenannten Filtergraphen arrangiert werden. Die durch diesen Filtergraphen fließenden Datenströme können manipuliert und kontrolliert werden. Abbildung 2.2 zeigt ein Beispiel für eine typische Anwendung, ein Software-DVD-Player, der auf DirectShow basiert. Die Anwendung kontrolliert die Aktivität des Filtergraphen, indem sie mit dem Filtergraph-Manager kommuniziert. Der Filtergraph-Manager ist für die verknüpften Filter zuständig und

¹ Unter Streaming versteht man eine Technologie, die es ermöglicht, empfangene Audio- oder Video-Daten bereits abzuspielen, ohne das hierfür die komplette Datei geladen werden muß [53].

7

2.1. DirectX

Abbildung 2.2: Einsatz von DirectShow: Anwendungen greifen über den Filtergraph-Manager von DirectShow auf die verknüpften Filter zu.

Abbildung 2.3: Die verknüpften Filter im DirectShow Filtergraphen werden über input- und output-pins miteinander verbunden. Diese symbolisieren die Ein- und Ausgänge der Komponenten und besitzen festgelegte Formateigenschaften.

benutzt seinerseits Schnittstellen der darunterliegenden DirectX-Ebene. Die Daten fließen von der Media Source am Source filter über den verbundenen Filter (Transform Filter) bis zur Media Destination mit dem Renderer filter. Abbildung 2.3 zeigt eine detailliertere Ansicht eines solchen Filtergraphen. Die beteiligten Filter werden dabei über ihre Pins miteinander verbunden. Diese Pins entsprechen den Ein- und Ausgängen der jeweiligen Filter und haben festgelegte Formateigenschaften. Diese werden im folgenden Abschnitt besprochen.

2.1.3 Formate in DirectShow

Formate in DirectShow werden durch einen Media Type definiert. Dieser Media Type setzt sich aus dem major type, dem minor type, dem format type und eventuell noch zusätzlichen Feldern zusammen. Tabelle 2.1 gibt einen Überblick über einige Media Types.

Der major type stellt die Oberklasse für die Formateinteilung dar, während die minor types eine feinere Unterteilung in den jeweiligen Oberklassen definieren. Die Angaben des format type und weiterer optionaler Felder ermöglichen eine genauere Beschreibung, wie z. Bsp. die Angabe der Kompressionsrate. Wie sich aus Tabelle 2.1 entnehmen läßt, ist die Formateinteilung zwar eindeutig und läßt sich mittels des format type und optionalen Feldern noch verfeinern, ist für den Anwender aber nicht sehr übersichtlich. Am Beispiel der verschiedenen Audio-Formate ist erkennbar, daß die major types mit der fortlaufenden Entwicklung von DirectX einfach erweitert wurden. Anstatt alle Formate, die in irgendeiner Form Audio-Informationen beschreiben,

8

AnalogVideo AnalogVideo_NTSC_M Analoges Video mit NTSC Norm

Tabelle 2.1: Die Microsoft Media Types beschreiben die Formate in DirectX und bestehen aus dem major type und dem minor type.

in eine gemeinsame Kategorie zu stellen, wurden neu hinzukommende Formate nach anderen Eigenschaften, wie z. Bsp. Streaming, in neue Kategorien eingeteilt. Im Hinblick auf die Frage nach einer automatischen Formatverhandlung gibt es seitens DirectShow einige erkennbare Ansätze. Microsoft bezeichnet diese Eigenschaft als intelligente Verbindung. Beim Aufbau des oben beschriebenen Filtergraphen kann dem Anwendungsprogrammierer die Arbeit in der Richtung erleichtert werden, daß automatisch passende Filter in den Graphen integriert werden. Da sich alle DirectShow-kompatiblen Filter in der Windows Registry mit ihrem major- und minor type anmelden, kann mittels der Methode EnumMatchingFilter( ) ein Filter mit passendem Media Type am input pin gefunden und integriert werden. Ausgehend von diesem neuen Filter wird dann die Registry wieder durchsucht, bis der Filtergraph komplett ist und den Fluß der Daten ermöglicht. Diese Vorgehensweise ermöglicht allerdings nicht, komplexere Graphen automatisch zu vervollständigen. Eine andere Möglichkeit einen Filtergraphen zu erhalten liegt in der Verwendung von vordefinierten Templates, die die Anordngung der Filter im Graphen für bestimmte Anwendungsfälle spezifizieren.

9

2.2. GStreamer

Abbildung 2.4: Die Komponenten von GStreamer, die GstElements, werden über ihre Ein- und Ausgänge (Pads) zu einer Pipeline verbunden. Je nach Anzahl und Anordnung der Pads eines GstElements wird zwischen Quellen, die nur ein Ausgangs-Pad, Senken, die nur ein Eingangs-Pad, und Filtern, die beides besitzen, unterschieden.

2.2 GStreamer

GStreamer [57] ist ein Framework für Multimedia-Anwendungen unter Linux, die mit Multimedia-Daten arbeiten. Ziel dieses Projektes ist es, den Rückstand von Linux bezüglich Multimedia-Architekturen im Vergleich zu anderen Betriebssystemen wie Microsoft Windows mit DirectX (s. Abschnitt 2.1) oder Apples MacOS mit Quicktime [7], auszugleichen. GStreamer orientiert sich dabei unter anderem an Direct-Show (s. Abschnitt 2.1.2).

2.2.1 Übersicht GStreamer

Hauptmerkmal der Architektur ist ein Plugin-Konzept, welches die Plugins, auch als GstElement bezeichnet, je nach benötigter Funktionalität, z. Bsp. mp3-Encodierung, zu einer Pipeline zusammenstellt. Diese Pipeline definiert den Datenfluß durch die Plugins und kann mit einer graphischen Oberfläche verändert und zur Wiederverwendung in einer Datei abgespeichert werden. Auf diese Weise läßt sich ein Medienplayer erstellen, der eine Vielzahl von Formaten unterstützt und auch die Integration weiterer Plugins vorsieht, beispielsweise der Einsatz von Effekten auf dem zugrundeliegenden Datenstrom.

Wichtigster Bestandteil von GStreamer beim Aufbau der Pipeline ist das GstElement. Diese Basiseinheit stellt sozusagen die Oberklasse der Plugins dar und symbolisiert sowohl physikalische Geräte als auch reine Softwarekomponenten wie Effekt-Filter. Pads stellen die Verbindungen eines GstElements nach außen dar. Sie sind für die Annahme und Weitergabe der Puffer in der Pipeline zuständig. Dabei wird zwischen den Ein- und Ausgangs-Pads unterschieden. Beim Aufbau der Pipeline werden die jeweils zusammenpassenden Ein- und Ausgangs-Pads miteinander verbunden. Abbildung 2.4 zeigt ein Beispiel für eine solche Pipeline.

2.2.2 GStreamer und Formate

In GStreamer stellen die Pads der GstElements die Verbindung einer Komponente nach außen dar. Um sicherzustellen, daß nur Pads mit dem gleichen Format verbunden werden, wird jedem Pad eine Capability zugeordnet, die die Informationen des unterstützten Formates speichert (s. Abbildung 2.5). Diese Capability setzt sich zusammen aus

10

2.2. GStreamer

Abbildung 2.5: Jedem Pad sind Capabilitys zugeordnet, bestehend aus dem MIME-Typ und weiteren Zusatzinformationen, den sogenannten Propertys. Die Capabilitys speichern das unterstützte Format ab. .

Datentyp eines Schlüssels Beschreibung

Tabelle 2.2: Die Propertys in GStreamer speichern Zusatzinformationen zu einem MIME-Typ ab. Der Wert dieser Informationen kann dabei verschiedene Datentypen annehmen.

¯ einem MIME-Typ (Multipurpose Internet Mail Extension) ² und

¯ den Propertys, die das jeweilige Format genauer beschreiben. Die Propertys

speichern Zusatzinformationen zur Ergänzung des MIME-Typs ab. Diese Zu-satzinformationen bestehen aus einem Schlüssel mit zugehörigem Wert. Tabelle 2.2 listet alle möglichen Datentypen eines Schlüssels auf.

Sinn der Capabilitys ist zum einem die Überprüfung einer Pipeline, um festzustellen, ob verbundene Pads exakt dieselben Formate beherrschen, und zum anderen ein Autoplugging-Mechanismus [57], der automatisch Plugins zum Ergänzen einer Pipeline findet.

Die hier beschriebene Formateinteilung nach MIME-Typ und zusätzlichen Informationen in den Propertys stellt eine eindeutige und zugleich intuitive Beschreibung von Formaten dar. Kritikpunkt an diesem Konzept sind die eingeschränkten Möglichkeiten bezüglich der Wahl eines Datentyps eines Schlüssels (s. Abbildung 2.2). Eine Erweiterung an dieser Stelle auf weitere Datentypen erscheint sinnvoll. Der oben angesprochene Autoplugging-Mechanismus erinnert stark an ein Konzept der Formatverhandlung, wie sie in dieser Arbeit entwickelt werden soll. Der Mechanismus bei GStreamer beschränkt sich allerdings nur auf das Vervollständigen einer Pipeline, d.h. bei Angabe einer Quelle und einer Senke werden aufgrund der Capabilitys alle registrierten Plugins durchsucht und bei Übereinstimmung eingebaut. Es wird

² Der MIME-Typ [12, 45] ist eine Erweiterung des Internet E-Mail-Protokolls und ermöglicht die Differenzierung weiterer Daten wie Video-, Audio- und Bildformate etc. zusätzlich zu dem Text.

2.3. Digital Media Library

Abbildung 2.6: Digital Media Library von SGI (Abbildung aus [15]).

in [55] extra darauf hingewiesen, daß dieser Mechanismus nur für einfache Aufgaben gedacht ist und somit das Ziel dieser Arbeit, auch komplexere Beziehungen zu modellieren, nicht erfüllt. Auch gibt es bei diesem Mechanismus keine Optimierung nach den benötigten Ressourcen oder einem Qualitätsmaße.

2.3 Digital Media Library

Die Digital Media Library von Silicon Graphics ist eine Sammlung von Bibliotheken, die ein umfangreiches API (Application Programming Interface) zur Verarbeitung von Multimedia-Daten bietet. Dazu gehören unter anderem die Beschreibung von Formaten, Funktionen zum Abspielen, Bearbeiten und Umwandeln von Audio-und Videoströmen und Dateioperationen.

Abbildung 2.6 gibt einen Überblick über sämtliche unterstützte Funktionen und Formate in der Digital Media Library. Im folgenden werden nur die Digital Media Parameters beschrieben, eine Übersicht der gesamten Funktionalität mit API kann im Digital Media Programming Guide [15, 52] nachgelesen werden.

2.3.1 Übersicht Digital Media Parameters

Die Digital Media Parameters [15] dienen der Definition von digitalen Inhalten innerhalb der Digital Media Library von SGI.

Die Idee der Formatdefinition in der Digital Media Library ist die Zusammenfassung von einzelnen Parametern zu einer sogenannten Digital Media Parameter List.

12

2.3. Digital Media Library

Tabelle 2.3: Mögliche Einteilung einer Digital Media Parameter List in der Digital Media Library durch Angabe eines DM_MEDIUM.

DM_TYPE_FLOAT_ARRAY

DM_TYPE_FLOAT_RANGE Bruch DM_TYPE_FRACTION

DM_TYPE_FRACTION_ARRAY DM_TYPE_FRACTION_RANGE

DM_TYPE_INT DM_TYPE_INT_ARRAY DM_TYPE_INT_RANGE DM_TYPE_LONG_LONG

Tabelle 2.4: Alle möglichen Datentypen der Digital Media Parameter.

Diese Liste ist durch ihre enthaltenen Parameter definiert und kann durch die zusätzliche Angabe eines DM_MEDIUM in eine Kategorie eingeteilt werden. Tabelle 2.3 zeigt alle möglichen Kategorien. Die Parameter ihrerseits bestehen aus einem sie identifizierenden Namen und einem zugeordneten Wert. Tabelle 2.4 zeigt alle möglichen Datentypen, die diese Parameterwerte annehmen können. Diese Art der Beschreibung von Formaten, wie sie von SGI vorgenommen wird, zeigt sich als sehr flexibel und durch die Vielzahl an unterstützten Datentypen (s. Tabelle 2.4) erweiterbar. Große Einschränkung an dieser Stelle bleibt aber die flache Hierarchie durch das DM_MEDIUM: Die vorgegebenen Ausprägungen sind nicht ausreichend, um für eine große Anzahl von Formaten eine intuitive Einteilung zu erhalten. Auch ist die Definition eines Formates nur anhand einer Parameterliste für den Anwender nicht sehr übersichtlich. Formatverhandlungen werden in der Digital Media Library nicht unterstützt.

2.4. Multimedia-Heimnetzwerke

2.4 Multimedia-Heimnetzwerke

Verteilte Multimedia-Systeme aus dem Heimbereich wie HAVi [35], Jini [54, 23] oder UPnP (Universal Plug and Play) [42] besitzen zwar Schnittstellen zum Suchen von Komponenten nach bestimmten Eigenschaften, aber nur HP JetSend Technology ³ [37] sieht ein Konzept der Formatverhandlung zwischen Multimedia-Geräten vor: Die Geräte können Präferenzen für ein bevorzugtes Format innerhalb ihrer unterstützten Formate abspeichern. In der Verhandlung entscheiden dann die Geräte aufgrund ihrer Präferenzen über eine mögliche Verbindung. Im Hinblick auf die netzwerkübergreifende Architektur des NMM-Projektes erweisen sich diese lokalen Entscheidungen aber als nicht ausreichend, da kein zugrundeliegendes Qualitäts- oder Kostenmaß verwendet wird.

Stellvertretend für diese Multimedia-Heimnetzwerke wird im folgenden HAVi näher betrachtet und auf den darin verwendeten Mechanismus zur Formatdefinition eingegangen.

2.4.1 HAVi

HAVi (Home Audio/Video interoperability Architecture) [35] ist ein Standard, der Anfang des Jahres 2000 von namhaften Herstellern der Unterhaltungselektronik wie Sony, Philips und Toshiba, ins Leben gerufen wurde. Diese Initiative hat sich zum Ziel gesetzt, einen einheitlichen Standard für elektronische Unterhaltungsgeräte im Heimbereich zu definieren, um über ein von allen Geräten gemeinsam genutztes Netzwerk einen hohen Komfort an Bedienbarkeit und integrierter Nutzbarkeit zu erreichen.

2.4.2 Übersicht HAVi

Aktuelle Geräte wie DVD-Player oder DV-Camcorder sind zwar mit verschiedenen Anschlüssen für unterschiedliche Standards versehen, doch die Möglichkeit die Geräte wie in einem Netzwerk zu verbinden, anzusteuern und zu nutzen, fehlte bisher. An diesem Punkt setzt die HAVi-Architektur an und definiert basierend auf dem IEEE 1394 Standard ⁴ (auch als i.LINK oder FireWire bekannt) das sogenannte Heimnetzwerk. In diesem Heimnetzwerk können Anwendungen nach dem HAVi-Standard die angeschlossenen Geräte gleichzeitig kontrollieren und koordinieren. Dabei werden sowohl Kontrollinformationen (Kommandos für Start, Stop etc.) als auch Audio/Video-Daten übertragen.

Das Heimnetzwerk dient gewissermaßen als verteilte Plattform, und die HAVi-Architektur garantiert, daß die angeschlossenen Geräte unterschiedlicher Hersteller über das Netzwerk miteinander kommunizieren und Daten austauschen können. Abbildung 2.7 zeigt ein Beispiel für ein solches Heimnetzwerk. Darin werden folgende Geräte unterstützt: Tuner, Videorekorder, Uhren, Kameras, CD-Player, Bildschirme, Verstärker, Modems und Webproxys. Die zwischen den Geräten ausgetauschten Kon-

³ DieEntwicklung der JetSend Technology wurde mittlerweile von HP eingestellt.

⁴ Der IEEE 1394 Standard [4, 40] spezifiziert einen seriellen Bus, an dem bis zu 63 Geräte mit einer maximalen Transferrate von z. Zt. bis zu 400 Mbit angeschlossen werden können.

14