Diplomarbeit

INTEGRATION VON ECHTZEIT - MEDIENSTRÖMEN IN VERTEILTE SYNCHRONE GROUPWARE

bearbeitet von

Niels Baumbach

Geboren am 30.01.1980 in Wolfen

TECHNISCHE UNIVERSITÄT DRESDEN

FAKULTÄT INFORMATIK INSTITUT FÜR SYSTEMARCHITEKTUR PROFESSUR RECHNERNETZE

Betreuender Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Betreuer: Dr. - Ing. Daniel Schuster Dipl. Inf. Sascha Kümmel - Vidsoft GmbH Eingereicht am: 20.12.2007

Inhaltsverzeichnis

INHALTSVERZEICHNIS

Inhaltsverzeichnis ...... 3 1. Einleitung ...... 5 2. Grundlagen ...... 7 2.1 Groupware und Multimedia-Systeme ...... 7 2.1.1 Klassifizierung von Groupware ...... 8 2.1.2 Multimedia und Multimedia-Systeme ...... 9 2.1.3 Anforderungen an verteilte Multimedia-Systeme ...... 9 2.2 Multimediaformate ...... 11 2.2.1 Funktionsweise und Kenngrößen von Mediencodecs ...... 12 2.2.2 Audiocodecs ...... 13 2.2.3 Videocodecs ...... 16 2.2.4 Containerformate ...... 19 2.2.5 Zusammenfassung ...... 23 2.3 Streaming - Architekturen ...... 24 2.3.1 Klassisches Client-Server Streaming ...... 24 2.3.2 Kollaboratives Streaming ...... 25 2.3.3 Network-Integrated Multimedia Middleware ...... 28 2.4 Echtzeit - Protokolle ...... 30 2.4.1 Realtime Transport Protocol ...... 31 2.4.2 Real-time Control Protocol ...... 32 2.4.3 Real-time Streaming Protocol ...... 33 2.5 Multimedia-Frameworks: Microsoft DirectShow ...... 34 2.5.1 Architektur ...... 35 2.5.2 Anwendungsbeispiel ...... 36 2.5.3 Streaming in DirectShow ...... 38 2.6 Streaming in Konferenzsystemen: WebEx ...... 39 2.6.1 Grundfunktionalität ...... 40 2.6.2 Streaming von multimedialen Inhalten ...... 41 2.7 Zusammenfassung ...... 42 3. Analyse...... 43 3.1 Szenario ...... 43 3.2 Anforderungen ...... 45 3.2.1 Wiedergabe ...... 45 3.2.2 Wiedergabeformate ...... 46 3.2.3 Heterogenität ...... 47 3.2.4 Synchronisation ...... 47 3.2.5 Datenübertragung ...... 48

3 Inhaltsverzeichnis

3.2.6 Import von Medienströmen ...... 48 3.2.7 Technische Anforderungen ...... 49 3.2.8 Sonstige Anforderungen ...... 49 3.3 Muss- und Kannkriterien ...... 50 4. Entwurf ...... 53 4.1 Entwurfsentscheidungen ...... 53 4.2 Rollenmodell ...... 56 4.2.1 Multimedia Streaming Clients ...... 57 4.2.2 Multimedia Streaming Server ...... 58 4.3 Beschreibungsformate ...... 59 4.3.1 Multimedia Streaming - Session Description Format ...... 60 4.3.2 Weitere Beschreibungsformate ...... 62 4.4 Integration von Multimedia Streaming in das CSP ...... 64 4.5 Protokollentwurf ...... 67 4.5.1 Nachrichten für kollaboratives Multimedia-Streaming ...... 68 4.5.2 Session-Setup und Buffering ...... 70 4.5.3 Kontrolle der Streaming Sitzung ...... 72 4.6 MTP Containerformat ...... 79 4.6.1 Adaption durch Block-Header ...... 80 4.6.2 Serialisierung von MTP-Datenströmen ...... 81 4.6.3 Echtzeitübertragung ...... 81 4.7 Zusammenfassung ...... 81 5. Implementierung und Validierung ...... 83 5.1 Technische Rahmenbedingungen ...... 83 5.2 Import lokaler Mediendateien ...... 85 5.2.1 Integration in die Oberfläche ...... 85 5.2.2 Importstrategien ...... 86 5.2.3 Transcoding lokaler Medienströme ...... 89 5.3 Umsetzung der MSP-Funktionalität ...... 91 5.4 Umsetzung der MCP-Funktionalität ...... 93 5.5 Transport von Medienströmen ...... 96 5.6 Zusammenfassung und offene Arbeiten ...... 96 6. Bewertung und Ausblick ...... 99 6.1 Bewertung der Arbeit ...... 99 6.2 Ausblick ...... 101 Literaturverzeichnis ...... 105 Abkürzungsverzeichnis ...... 109 Abbildungsverzeichnis ...... 111 Tabellenverzeichnis ...... 113 Selbständigkeitserklärung ...... 115

4 1. Einleitung

1. EINLEITUNG

In der heutigen, globalisierten Welt werden computergestützte Systeme wie Audio- und Videokonferenzen in vielen Bereichen der Wissenschaft und Wirtschaft eingesetzt, um eine kostengünstige, leistungsfähige und benutzerfreundliche Kommunikation zwischen entfernten Anwendern zu realisieren. Diese Kommunikationssysteme dienen aber nicht nur als Alternativen und Ersatz klassischer Kommunikationsformen, sondern bieten dem Endanwender auch zusätzliche Funktionen: die Koordination und Kooperation innerhalb einer Gruppe wird zunehmend unterstützt. Aktuelle Konferenzsysteme bieten neben der Echtzeit-Kommunikation über Audio- und Videokanäle Funktionen an, die es einer Gruppe von Teilnehmern ermöglicht, kollaborativ und zeitgleich Inhalte zu betrachten (Shared-Viewing) oder diese gemeinsam zu bearbeiten (Shared- Editing). Diese Funktionalität wird in der Literatur unter dem Begriff Data-Conferencing zusammengefasst. Heutige Data-Conferencing Applikation bieten dabei zumeist nur die Möglichkeit, statische Inhalte in einer Gruppe zu präsentieren oder zu editieren. Ein typisches Anwendungsbeispiel ist das moderierte und kollaborative Betrachten einer Folienpräsentation. Durch den stetigen Ausbau der Infrastruktur heutiger Kommunikationsnetzwerke wie dem Internet sind darüber hinaus auch Szenarien denkbar, in denen hochqualitative und dynamische Inhalte wie Video- oder Audioaufzeichnungen in digitalisierter Form kollaborativ betrachtet werden sollen. Im Zuge dieser Arbeit soll daher am Beispiel eines bereits produktiv eingesetzten Konferenz- systems untersucht werden, wie dynamische Inhaltsobjekte in Form von Medienströmen innerhalb eines Shared-Viewing Szenarios behandelt und eingebunden werden können. Zunächst wir hierzu im Kapitel 2 ein Überblick über die Thematiken und Technologien geboten, die zur Lösung der Aufgabenstellung hilfreich sein können. In diesem Grundlagenkapitel werden Begrifflichkeiten für die weitere Arbeit definiert und bereits existierende Formate für die Beschreibung multimedialer Daten, Architekturen sowie Protokolle zur Übertragung von Medienströmen einführend vorgestellt. Eine umfassende Anforderungsanalyse der Aufgabenstellung folgt in Kapitel 3. Hier werden anhand eines Szenarios Kriterien an eine Anwendung definiert, die die integrierte, kollaborative Wiedergabe von Medienströmen realisiert. Entsprechende Lösungsansätze werden im nachfolgenden Entwurfskapitel zusammengefasst. Dabei sollen in Kapitel 4 auch Alternativen der Konzeption diskutiert und getroffene Entscheidungen begründet werden. Kapitel 5 dokumentiert den praktischen Teil der Arbeit und zeigt, wie die im Entwurf vorgeschlagenen Komponenten prototypisch in einen bestehenden Applikationsrahmen integriert wurden. In Kapitel 6 werden die vorangegangen Abschnitte der Arbeit und die dadurch aufgezeigte Lösung der Aufgabenstellung abschließend diskutiert. Die eigene Bewertung der Arbeit wird durch einen Ausblick ergänzt, der Hinweise auf noch notwendige Untersuchungen und Vertiefungen der Thematik bietet.

5

2. Grundlagen

2. GRUNDLAGEN

Im Zuge der Arbeit soll die Integration von Medienströmen in synchrone Groupware untersucht werden. Hierzu wird zuerst ein Überblick über grundlegende Begriffe wie Groupware und Multimediasysteme geboten. Eine Gegenüberstellung aktueller und gängiger Multimedia- Formate und deren Besonderheiten schließt sich diesen Ausführungen an. Möglichkeiten zur Paketisierung und Übertragung dieser Formate sollen dabei mit im Vordergrund stehen. Nachdem verschiedene Streaming-Architekturen vorgestellt wurden, werden konkrete Protokolle zur Echtzeit-Verteilung von multimedialen Daten untersucht. Der letzte Abschnitt des Kapitels führt die gewonnen Erkenntnisse zusammen und stellt mit WebEx eine Groupware vor, die bereits Funktionen eines Multimedia-Streamings integriert.

2.1 Groupware und Multimedia-Systeme

Für die Bearbeitung der Aufgabenstellung muss zunächst untersucht werden, was im folgendem unter Groupware oder kollaborativer Software zu verstehen ist. [EGR91] definiert Groupware als:

„… computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment.”

Groupware unterstützt also einer Gruppe von Anwendern dabei, eine gemeinsame Aufgabenstellung zu bearbeiten und ein definiertes Ziel zu erreichen. Dabei stellt das rechnergestützte System für alle Mitglieder der Gruppe eine Schnittstelle zu einer gemeinsam genutzten Umgebung bereit. Diese Definition lässt noch offen, was unter einer Gruppe und einer gemeinsam genutzten Umgebung zu verstehen ist. Im Kontext der Groupware wollen wir nicht von sozialen Gruppen ausgehen, sondern vielmehr von der Gruppe als Team. [SDF90] beschreibt Teams als:

„ ... small groups of interdependent individuals who share responsibility for outcomes for their organisations”

Teams sind somit kleine soziale Gruppen, die in gemeinsamer Verantwortlichkeit versuchen, Ergebnisse für Organisationen zu erreichen. In der Arbeit wird auf eine genauere Unterscheidung von sozialer Gruppe und sozialem Team verzichtet und beide Begriffe als Synonym verwendet. Mitglieder einer Gruppe können durchaus verschiedene Rollen annehmen.

7 2. Grundlagen

So kann ein Teilnehmer mit der Rolle des Moderators eine Sitzung leiten und in einer Shared- Viewing Applikation als Referenz für eine Synchronisierung innerhalb der Gruppe dienen.

2.1.1 Klassifizierung von Groupware

Die Einordnung von Groupware soll dabei helfen, Eigenschaften verschiedener Systeme besser zu verdeutlichen und schließlich genaue Anforderung an diese zu definieren. Als erster Ansatz bietet sich die Unterscheidung nach Raum und Zeit an. Die Frage könnte also lauten: Wo und wann findet die kooperative Arbeit statt?

GLEICHER ZEITPUNKT VERSCHIEDENE (SYNCHRON) ZEITPUNKTE (ASYNCHRON) Face-to-Face Arbeit an Klassisches Schwarzes Brett, GLEICHER RAUM Desktopanwendungen, z.B. Arbeitsraum Brainstormingunterstützung Videokonferenzen, Email, Gruppenportale, ENTFERNTE RÄUME kooperatives Editieren von Wikis, CMS, WebBlogs (VERTEILTES Dokumenten / SYSTEM) Softwareentwicklung

Tabelle 1: Raum-Zeit-Matrix nach [JOH91]

In Tabelle 1 ist die Raum-Zeit-Taxonomie nach [JOH91] als 2x2 Matrix dargestellt. Arbeitet eine Gruppe zu einem gleichen Zeitpunkt an einer Aufgabe, kann von von synchroner Groupware gesprochen werden. Die Einordnung von Groupware nach dem Raum deren Nutzung ist im Kontext der Arbeit weniger relevant und soll nicht diskutiert werden. Wir gehen weiterhin von einer verteilten Architektur aus. Hierbei können nicht nur Systemkomponenten, sondern auch Arbeitsartefakte verteilt werden: eine Videodatei kann durchaus an verschiedenen Quellen repliziert vorliegen. Soll diese beispielsweise bei einer Konferenz zu einem Teilnehmer übertragen werden, können mehrere Quellen einbezogen werden. Es bietet sich ebenfalls an, nach der Art der Interaktion im System zu klassifizieren und diese Einordnung nicht zu starr, sondern fließend zu gestalten. Interaktion innerhalb von Groupware- Lösungen besteht nach [TSM+95] im Wesentlichem aus drei Komponenten: Kommunikation, Koordination und Kooperation. Aus diesen zusätzlichen Eigenschaften lässt sich nun eine Definition für verteilte synchrone Groupware ableiten:

Definition 1: Unter verteilter synchroner Groupware versteht man computergestützte Anwendersysteme, deren Komponenten und Arbeitsartefakte in einem Netzwerk verteilt sind und in denen Mitglieder einer Gruppe untereinander oder mit Arbeitsartefakten interagieren. Ziel dieser Interaktion ist die Bewältigung einer vorher definierten Aufgabe.

8 2. Grundlagen

2.1.2 Multimedia und Multimedia-Systeme

Der Begriff Multimedia kann innerhalb von kollaborativer Software an verschiedenen Stellen auftreten. Multimediale Daten können in Form von Videokonferenzen als Hilfsmittel zur Kommunikation unter Teilnehmern eingesetzt werden oder der Gegenstand der gemeinsamen Arbeit ist selbst ein multimediales Format. In diesem Abschnitt sollen elementare Grundlagen und Anforderungen an Multimediaformate und -systeme diskutiert werden. In der Literatur wird ein multimediales System oft als Anwender-System definiert, das mehr als zwei Medientypen unterstützt. Multimedia ist somit die Kombination von zumindest zwei Medientypen. Mit dieser Definition können auch Systeme als multimedial angesehen werden, die an dieser Stelle ausgeklammert werden sollten: ein illustrierter Zeitschriftenartikel ist multimedial, da er zwei Medientypen beinhaltet - Texte und Bilder. Eine genauere Abgrenzung ist hier notwendig. Medien können allgemein anhand ihrer Zeitabhängigkeit unterschieden werden. Texte und unbewegte Bilder gelten als zeitdiskrete Medien. Die für den Nutzer enthaltenen Informationen werden statisch präsentiert. Audio- und Videoströme hingegen sind zeitkontinuierliche Medien. Die dargebotene Information ändert sich zur Laufzeit der Präsentation. Neben klassischen Medien gewinnen gerade im Internet Animationen zunehmend an Bedeutung. Beispiele solcher Formate sind Adobe Flash und Scalable Vector Graphics (SVG). Im Kontext dieser Arbeit sollen unter dem Begriff Animationsformate moderne, auf Vektorgraphiken basierende Medienformate zusammengefasst werden. Abschließend soll die Definition eines multimedialen Systems auf verteilte Architekturen erweitert werden.

Definition 2: Verteilte Multimedia-Systeme sind vernetzte Anwendungen, die multimediale Formate unterstützen. Instanzen dieser Anwendungen kommunizieren über computergestützte Netzwerke miteinander und tauschen so zeitdiskrete und zeitkontinuierliche Daten aus.

2.1.3 Anforderungen an verteilte Multimedia-Systeme

In der Definition eines verteilten Multimedia-Systems in Abschnitt 2.1.2 ist eine Anforderung an multimediale Systeme, die Unterstützung multipler Medienformate, bereits eingeflossen. Nach [MAN03] lassen sich verschiedene allgemeine Anforderungen für Multimedia-Systeme festhalten:

• Kombination von Medien: Verschieden Arten von Medientypen und Formaten sollten integriert werden. • Unabhängigkeit: Die integrierten Medienformate und Medienströme sollten unabhängig voneinander verarbeitbar sein. • Kommunikationsunterstützung: Moderne Kommunikationsformen müssen unterstützt werden, um den effektiven Datenaustausch mit anderen multimedialen Systemen zu gewährleisten. Dabei sollen diskrete Daten übermittelt werden (z.B. Text via Email) oder auch kontinuierliche Datenströme (z.B. die Übertragung Audiodatei mit Streaming-Methoden).

9 2. Grundlagen

Die Kommunikationsunterstützung ist im Fall eines verteilten Systems eine zentrale Anforderung. Neben der Übermittlung der Daten ist bei heterogenen Zielsystemen eventuell auch eine Datenadaption bzw. Datentransformation notwendig. Diese Anpassungen dürfen dabei die Echtzeit-Anforderungen im System nicht verletzten. Der Begriff Echtzeit wird nach DIN 44300 wie folgt definiert:

Definition 3: Echtzeitbetrieb ist ein Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig derart betriebsbereit sind, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind.

Echtzeit ist also ein durchaus dehnbarer Begriff. Die Zeitspanne kann dabei über Deadlines festgelegt sein. Diese geben nach [SN04] das höchste akzeptable Zeitlimit für die Präsentation eines Ergebnisses der Verarbeitung oder der Kommunikation an. Deadlines dienen uns im Kontext der Echtzeit also zur Definition von Zeitschranken und somit für die Abschätzung, ob ein Prozess oder ein System in Echtzeit arbeitet oder nicht. Hierbei kann noch eine Unterscheidung in Soft-Deadlines und Hard-Deadlines getroffen werden. Soft- Deadlines werden mit einer bestimmten Toleranz geprüft und sind möglicherweise nicht genau festlegbar. Eine Überschreitung führt nicht in jedem Falle zu einem Systemfehler. Hard- Deadlines werden für kritische Prozesse definiert und führen in jedem Fall zu der Einordnung, dass ein System die Echtzeitanforderung nicht erfüllt und somit fehlerhaft ist. In multimedialen Systemen können Echtzeitanforderungen als Qualitätsanforderungen (engl. Quality of Service - kurz QoS) eingeordnet werden. [SN04] beschreibt zwei grundlegende Ansätze zur Sicherstellung von QoS in multimedialen Systemen:

• Skalierung und Adaption der Medien-Qualität: Die Medien werden während oder nach der Übertragung an die technischen Ressourcen und QoS-Definitionen der Zielplattform angepasst. • Reservierung von Ressourcen: Die benötigten Kapazitäten zur Übertragung und Darstellung der Medien wird auf dem Zielsystem noch vor der Kommunikation und vor der Verarbeitung bereitgestellt.

In verteilten Multimedia-Systemen muss hierbei nicht nur die heterogene Zielplattform, sondern auch die unterschiedlichen Kommunikationswege und Bandbreiten berücksichtigt werden: mobile Clients verfügen in der Regel noch nicht über einen breitbandigen Zugriff auf die Infrastruktur des Internets. Eine Anpassung von Datenströmen kann aufgrund des Zugangs zum verteilten System oder auch spezielle technische Anforderungen (z.B. niedriger Energieverbrauch) notwendig sein. Es kann festgehalten werden, dass als zentrale Herausforderung in verteilten Multimedia- Systemen die Heterogenität der Zielplattformen und Kommunikationswege herauszustellen ist. Diese Heterogenität erfordert Datenadaption und Transformation, um eine qualitativ hochwertige Darstellung der Medien auf möglichst vielen Zielplattformen zu ermöglichen. Definierte QoS-Parameter wie die Einhaltung von Echtzeitanforderungen während der Übertragung zeitkontinuierlicher Medien müssen dabei weiterhin berücksichtigt werden.

10 2. Grundlagen

2.2 Multimediaformate

Im vorangegangenen Abschnitt wurden die Grundlagen des Begriffes Multimedia diskutiert und Anforderungen an Systeme definiert, die multimediale Formate unterstützen. Nun soll zunächst eine genauere Sicht auf gängige Standards und Formate zur Verarbeitung von zeitkontinuierlichen Mediendaten geboten werden. Die nachfolgenden Ausführungen konzentrieren sich auf weit verbreitete Formate für Multimedia und deren Struktur. Eine Strukturierung ist notwendig, um eine Zuordnung einzelner Segmente zu einer Wiedergabeposition zu ermöglichen. Auch die Synchronisierung verschiedener logischer Datenströme kann durch das Format realisiert werden. Ein Anwendungsbeispiel hierfür ist eine Videoaufzeichnung, die in einem Format mit alternativen Audioströmen abgelegt wurde. Abbildung 1 veranschaulicht hierzu exemplarisch die mögliche Struktur und den Inhalt eines Multimediaformats.

Metainformationen

Videostrom

...

Audiostrom 1 ... Multimediale Inhalte

Audiostrom 2 Videosamples ... Audiosamples

Abbildung 1: Prinzipieller Aufbau eines Multimediaformats

Ein Schwerpunkt bei der Vorstellung von Medienformaten soll dabei das Streaming der beinhalteten Daten bilden:

Definition 4: Der Begriff Streaming umschreibt einen Vorgang, bei dem Inhalte von einer Quelle zu einem Ziel übertragen und dort zeitnah dargestellt werden. Der Inhalt wird dabei schon nach dem Vorausladen einer Teilmenge des Datenstroms am Ziel dargestellt. Während der Darstellung werden Segmente des Inhalts kontinuierlich weiter zwischen Quelle und Ziel übertragen, um die weitere Wiedergabe sicherzustellen.

Das Streaming von Inhalten wird insbesondere dann notwendig, wenn umfangreiche Inhalte wie zeitkontinuierliche und multimediale Daten zwischen Teilnehmern verteilt und zeitnah wiedergegeben werden sollen.

11 2. Grundlagen

2.2.1 Funktionsweise und Kenngrößen von Mediencodecs

In diesem Abschnitt wird der Begriff Codec eingeführt, der wie folgt definiert werden kann:

Definition 5: Als Codec (Kunstwort aus engl. coder und decoder) bezeichnet man ein Verfahren oder Programm, das Daten oder Signale digital codiert beziehungsweise decodiert.

Heute existiert eine Fülle von Codecs und Formaten, die analoge Signale in digitaler Form aufbereiten und so deren computergestützte Verarbeitung ermöglichen. Details zu einzelnen Kodierungsverfahren sollen in dieser Arbeit nicht vertieft werden. Ein Mediencodec kodiert oder dekodiert multimediale Inhalte. Dabei werden üblicherweise komplexe Algorithmen genutzt, um die Datenmenge eines Eingangssignals zu verringern und dieses in strukturierter, digitalisierter Form abzulegen. Hierdurch wird die computergestützte Verarbeitung sowie der Transport innerhalb IP-basierter Netzwerke ermöglicht. Im Umkehrschluss werden Mediencodecs ebenfalls dazu verwendet, um zuvor komprimierte Inhalte zu dekodieren und schließlich an Ausgabegeräten einer Zielplattform darzustellen. Nachfolgend sollen einige Kenngrößen der Kodierung und Dekodierung mit Mediencodecs beschrieben werden. Somit wird die Grundlage für die Beschreibung und Bewertung einzelner Medienformate gelegt.

2.2.1.1 Bitrate

Die Bitrate gibt an, welche Datenmenge in einer bestimmten Zeitspanne kodiert und somit übertragen werden muss, um das Quellsignal am Ziel wiedergeben zu können. Je höher die Bitrate eines digitalisierten Signals, desto besser ist üblicherweise dessen Wiedergabequalität. Eine niedrige Bitrate ist wiederum für den störungsfreien Transport der Daten über schmalbandige Transportkanäle notwendig.

2.2.1.2 Delay

Die Verzögerung bei der Verarbeitung von Mediensignalen ist gerade bei Anwendungen zu beachten, die eine Kommunikation in Echtzeit ermöglichen sollen (z.B. Audiokonferenzen oder Voice over IP). Hier spielt die Framelänge eine entscheidende Rolle.

Definition 6: Als Framelänge bezeichnen wir im Kontext von Audio- und Videoverarbeitung die (Abspiel-) Dauer eines Fragments des digitalisierten Signals.

Die minimale zeitliche Verzögerung bei der Digitalisierung eines Audiosignals liegt normalerweise bei der drei- bis vierfachen Länge eines Frames [SCH99]. Dieser Wert kommt unter Anderem durch die verwendeten Algorithmen zustande, die einen gewissen Datenvorlauf benötigen, um das Signal effektiv zu kodieren. Definiert ein Audioformat eine Framelänge von 20ms, wird mit obiger Annahme eine reine algorithmische Verzögerung von 60-80ms erreicht. Neben dieser algorithmischen Verzögerung bei der Wandlung des Eingangssignals kann es zu weiteren Formen des Delays kommen. Ausführlich erläutert werden diese Delays in [CIS07].

12 2. Grundlagen

In der Literatur zur Thematik wird häufig ein Schwellenwert von 300ms genannt: übersteigt die Gesamtdauer der Verzögerungen in einem Echtzeitszenario diesen Schwellenwert, nehmen Anwender dies als störend wahr.

2.2.1.3 Komplexität

Die Komplexität eines Kodierungsverfahrens wirkt sich auf verschiedene Aspekte der Anwendung aus. Stellt ein Verfahren zu hohe Anforderungen an die Hardware des Systems, kann es zu Einschränkungen bei den möglichen Zielplattformen der Applikation kommen. Heterogene Zielplattformen verfügen unter Umständen nicht über die gleichen technischen Kapazitäten. Die Komplexität eines Kodierungsverfahrens und dessen Delay hängen eng zusammen. Eine Verarbeitung ohne spezialisierte Hardware (Hardware-Dekoder) erfordert zusätzlich Rechenleistung durch den Prozessor. Häufig sind Codecs zu komplex, um für einfache Anwendungen selbst implementiert zu werden. Um einen gewissen Abstraktionsgrad zu erlangen und die Entwicklung zu vereinfachen, nutzen Entwickler Software Developer Kits (SDKs) oder ganze Multimedia Frameworks (bspw. Microsoft DirectShow), um die Verfahren zu implementieren. Hierdurch wird die Prozessorlast bei der Kodierung unter Umständen weiter erhöht.

2.2.1.4 Qualität

Die Qualität eines Codecs lässt sich subjektiv (durch den Endanwender) und objektiv beurteilen. Die Qualität der Darstellung des Multimediastroms kann als subjektives Merkmal eingeordnet werden. Hierbei werden in der Literatur zumeist Vergleiche zu bereits bekannten Medien gezogen. Bei der Komprimierung von beliebigen Audiosignalen (z.B.: Musik) wird eine gute bis sehr gute Wiedergabequalität beispielsweise mit der Qualität einer Audio-CD gleichgesetzt. Erreicht wird eine hohe Qualität durch eine möglichst hohe Abtastrate und Abtasttiefe. Die für uns relevanten und objektiven Qualitätsmerkmale wurden bereits erläutert: durch die Bitrate und die beim Codec entstehenden Verzögerungen können wir die Verfahren einordnen und daraus deren Eignung für verteilte Anwendungen ableiten.

2.2.1.5 Robustheit

Für den verteilten Anwendungsfall muss neben der Verzögerung auch der Robustheit besondere Aufmerksamkeit geschenkt werden: im Fehlerfall, also beispielsweise dem Verlust einzelner Frames eines Medienstroms während der Übertragung, muss das Format als Ganzes abspielbar bleiben.

2.2.2 Audiocodecs

Zwei Arten der Kodierung auditiver Daten können unterschieden werden: die Sprachkodierung und die Kodierung von quasi beliebigen Signalen. Diese nutzen verschiedene algorithmische Ansätze, um analoge Quellsignale möglichst effektiv zu komprimieren. Näheres zur Theorie der dabei zugrunde liegenden Verfahren lässt sich in [SMB07] und [UHV+04] nachlesen. Für die Aufgabenstellung ist eine Vertiefung der effektiven Kodierung von beliebigen Audiosignalen weitaus interessanter: Sprachcodecs sind in Konferenzsystemen zumeist schon integriert, um eine Echtzeit-Kommunikation innerhalb einer Gruppe zu ermöglichen. Deshalb soll der folgende Abschnitt nur kurz in diese Thematik einführen.

13 2. Grundlagen

2.2.2.1 Sprachkodierung

Sprachcodecs werden für die Kodierung von menschlicher Sprache im Bereich der Festnetz- Telephonie und in mobilen Netzen genutzt. Darüber hinaus können sie auch in IP-basierten Protokollen (z.B. Voice over IP) zum Einsatz kommen. Die Codecs sind dabei hochspezialisiert und eignen sich daher üblicherweise nicht zur Kodierung beliebiger Audioströme wie Musik. Die ITU (International Telecommunication Union) schlägt verschiedene Codecs zur Kodierung von Sprachinformationen vor. Exemplarisch seien hier G.711 und G.729 als Vertreter genannt. Typischerweise erreicht ein G.711-Signal eine Bitrate von 64 Kbps und eine sehr gute Qualität der Sprachübertragung. Im Vergleich zu G.711 verringert G.729 die benötigte Bitrate stark: 8 Kbps werden durch sehr rechenaufwendige Algorithmen erreicht. Tabelle 2 zeigt weitere technische Details einiger ITU Sprachcodecs, ohne dabei Anspruch auf Vollständigkeit zu erheben.

CODEC BITRATE SAMPLINGRATE FRAMELÄNGE DELAY QUALITÄT IN KBPS IN KHZ G.711 48, 56, 64 3 125 μs < 1 ms Sehr gut G.723.1 5.3, 6.4 3 30 ms 97 ms Ausreichend G.728 16 3 625 μs < 2 ms Ausreichend bis Gut G.729 8 3 10 ms 35 ms Gut Tabelle 2: ITU Sprachcodecs (nach [SCH04] und [SCH99])

Sprachcodecs der MPEG-4 Protokollfamilie bieten weitergehende Funktionen und niedrigere Bitraten als die bereits vorgestellten ITU-Codecs, und das bei ähnlich einzuschätzender Wiedergabequalität. Die Bitrate des kodierten Audiostroms (diese kann zwischen 2 und 24 Kbps liegen) und die Komplexität der Codierverfahren ist skalierbar. Das heißt die Qualität der Codierung kann zur Laufzeit an die verfügbaren Ressourcen angepasst werden. Die Qualität eines MPEG-4 Sprachsignals bei 2 Kbps kann als „Kommunikationsqualität“ eingestuft werden und ist für reine Sprachkonversationen ausreichend ([TPM98]). Als Vertreter patentfreier Sprachcodecs soll abschließend Speex vorgestellt werden und somit auch eine Sicht auf rechtliche und wirtschaftliche Aspekt von Codecs bieten. Die bisher genannten Verfahren sind üblicherweise mit Patenten versehen, für deren Nutzung der Anwendungsentwickler Lizenzgebühren entrichten muss. Ein Entwurfziel von Speex ist die Patentfreiheit und Quelloffenheit der zugrunde liegenden Sprachverarbeitung. Dabei erreicht der Codec in Punkto Funktionsumfang, Kompressionsraten und Wiedergabequalität die Güte der MPEG-4 Sprachcodecs. Die Bitrate eines mit Speex kodierten Audiostroms kann dabei in einem Bereich von 2 bis zu 44 Kbps liegen. Durch diese Wertebereiche können Audioströme in Speex-Kodierung eine sehr gute Wiedergabequalität bei einem Delay von etwa 30 ms erreichen.

14 2. Grundlagen

2.2.2.2 MPEG-1 Audio Layer 3 (MP3)

MPEG-1 ist wie der bereits angesprochene MPEG-4 Standard ein von der Motion Picture Expert Group vorgeschlagener, mehrteiliger ISO/IEC-Standard. Mit MPEG-1 Audio wird darin auch ein Audiostandard vorgestellt, der für beliebige Audiosignale hohe Kompressionsraten bei vergleichsweise guter Wiedergabequalität bietet. Erreicht wird dieses gute Verhältnis durch leistungsstarke Kompressionsalgorithmen, die auch psychoakustische Besonderheiten des menschlichen Gehörs in ihren Berechnungen beachten. Vereinfacht gesagt werden von Menschen „unhörbare“ Informationen einfach aus dem Signal entfernt. MPEG-1 Audio schlägt 3 Stufen, so genannte Layer, in der Verarbeitung unkomprimierter Audiosignale vor. Layer können als Kompressionsstufen verstanden werden, die sich in Komplexität und mögliche Kompressionsraten unterscheiden. Der komplexe und leistungsstarke dritte Layer ist gleichzeitig Namensgeber des MPEG-1 Audio Layer III-Formats (kurz MP3). Eine detaillierte Beschreibung der Kodierung und Dekodierung von MPEG-1 Audiodaten findet sich beispielsweise in [MAN03]. MP3 Audioströme werden mit einer Bitrate von 32 bis 320 Kbps kodiert, wobei mit einem Wert zwischen 128 und 192 Kbps eine sehr gute Wiedergabequalität erreicht wird. Der Delay liegt für einen typischen MP3-Strom (128 Kbps Bitrate und 48kHz Abtastsrate) bei verschiedenen Anwendungsszenarien zwischen 107 und 142 ms ([LSG+04]). Dieser Wert kann sich ohne Korrekturen im verteilten Anwendungsfall noch weiter erhöhen (vgl. hierzu siehe [AKE07]).

2.2.2.3 MPEG-4 AAC Low Delay

Advanced Audio Coding (AAC) Algorithmen gelten als Nachfolger des MP3 Kompressionsverfahrens. AAC ist dabei als Kodierungsschema zu verstehen: es beschreibt Methoden und Richtlinien für die Implementierung von Musikcodecs. MPEG-4 AAC bietet im Vergleich zu MP3 niedrigere Bitraten bei mindestens gleicher Wiedergabequalität: schon ab einer Bitrate von 80 Kbps kann von einer guten Qualität der Wiedergabe gesprochen werden. Mit dem MPEG-4 Low Delay Audiocodec (kurz: AAC-LD) sei hier eine Variante genannt, die ähnlich niedrige algorithmische Verzögerungen wie Sprachcodecs bietet und somit für eine Echtzeitübertragung in Betracht kommt. In der Praxis wird durch AAC-LD ein Delay zwischen 24 und 44 ms erreicht ([LSG+04]).

2.2.2.4 Vorbis

Analog zu den Betrachtungen zum Speex Sprachcodecs soll mit Vorbis abschließend ein patentfreier und quelloffener Musikcodec genannt werden. Vorbis bietet theoretisch Bitraten von 45 bis zu 500 Kbps. Diese Zahlen sind als Richtwerte zu verstehen, da Vorbis komplett auf die Möglichkeit einer Kodierung des gesamten Audiostroms mit einer konstanten Bitrate (CBR) verzichtet. Vorbis schreibt eine variable Bitrate bei der Kodierung einzelner Audioframes vor (VBR), das heißt für jeden Frame wird die Bitrate neu ermittelt und festgelegt. Das Ziel der Entwicklung von Vorbis ist die Ablösung von MP3 als Quasi-Standard für Musikkodierung für den Massenmarkt. Tests zeigen, dass Vorbis MP3 in Punkto Wiedergabequalität in vielen gängigen Szenarien übertrifft [XIP07]. In typischen Einstellungen zur hochqualitativen Kodierung (Samplingrate 44.1 kHz, 4096 Samples pro Frame) benötigt das Verfahren im Minimum einen Vorlauf von 96ms. Für Echtzeitanwendungen ist es daher nicht ohne Einbußen bei der Wiedergabequalität einsetzbar.

15 2. Grundlagen

2.2.2.5 Zusammenfassende Bewertung

Einsatzgebiete für Sprachcodecs sind Anwendungen, in denen menschliche Sprache möglichst effektiv kodiert und verteilt werden muss (Festnetz- und Video-Telefonie oder Voice-Over-IP). Für die Aufgabenstellung weit wichtiger sind Audioformate, die auch beliebige Signale (in guter Qualität) kodieren können. Musikcodecs bietet diese Funktionalität, verlangen aber zumeist nach höheren Bitraten und ergeben durch algorithmische Delays vergleichsweise hohe Verzögerungen bei der Verarbeitung. Es existieren jedoch Entwicklungen, die diese Schwachpunkte aufgreifen (vgl. 2.2.2.3). Somit können heute bereits Verfahren integriert werden, bei denen beliebige Audiosignale in guter Qualität und unter Echtzeitbedingungen verteilt werden können.

2.2.3 Videocodecs

In einer allgemeinen Betrachtung multimedialer Daten müssen visuelle Signale ebenfalls aufgenommen werden. Diese ergeben digitalisiert sehr große Datenmengen, wenn Sie nicht entsprechend komprimiert werden: für die Rohdaten eines Bildes mit einer Auflösung von 768 × 576 Bildpunkten (PAL) und einer Farbtiefe von 32bit benötigt man unkomprimiert rund 1,69 Megabyte Speicherplatz. Videos setzen sich aus Einzelbildern, so genannte Frames, zusammen. Die Framerate bei bewegten visuellen Signalen gibt an, wie viele Einzelbilder pro Sekunde dargestellt werden. Typischerweise kann hier von Werten um die 25 Frame pro Sekunde ausgegangen werden. Bei obigem Beispiel ergäbe sich so eine Datenrate von rund 42,2 Megabyte pro Sekunde, ein Wert, der für eine Übertragung in verteilten Systemen nicht akzeptabel ist. Videocodecs verringern die Datenraten für Videosignale derart, dass sogar eine Streaming- Übertragung über ältere Transportkanäle wie ISDN möglich ist. Hierbei sind natürlich Qualitätseinbußen hinzunehmen. Die Verarbeitung visueller Daten erfordert neben hohen Datenübertragungsraten auch leistungsstarke Client- und Serverplattformen. Die effektive Codierung gestaltet sich aufgrund der hohen Datenmengen komplizierter als bei Audiosignalen. Nachfolgend sollen einige Videocodecs in ihren Grundzügen erläutert werden.

2.2.3.1 MPEG-1 Video

MPEG-1 wurde bereits im Zusammenhang mit der Kompression von Audiosignalen vorgestellt. An dieser Stelle soll ein weiterer Teil des MPEG-1 Standards, MPEG-1 Video, als Beispiel für einen Video-Kompressionsstandard diskutiert werden. Jeder MPEG-1-Videostrom besteht aus einer Folge von Group of Pictures (GOP) bzw. Group of Frames, also eine Folge von Einzelbildern. Eine GOP startet und endet jeweils mit einem I- Frame. I-Frames sind hierbei Referenzbilder, auf die sich andere Typen von Frames beziehen können. Insgesamt unterscheidet MPEG-1 Video drei Arten von Videoframes:

• Der bereits vorgestellt I-Frame (von „Intra Coded“) enthält keine Referenzen zu anderen Frames. Er dient als Referenzframe und kann als eine Art Standbild verstanden werden. Andere Frametypen können sich auf einen I-Frame beziehen und nur die Änderungen zum letzten I-Frame beinhalten.

16 2. Grundlagen

• Ein P-Frame (von “Predicted Coded“) enthält Schätzung bezogen auf den letzten I- Frame oder P-Frame. Das heißt, es werden nur die Veränderungen zum letzten Frame in einem P-Frame abgelegt. • Ein B-Frame (von „Bidirectional Predicted Coded“) kann Referenzen zu vorherigen oder zukünftigen I- oder P-Frames enthalten und wird nie als Referenzframe genutzt. Er beschreibt den Unterschied des vorherigen und des nachfolgenden Frames.

Ein I-Frame bietet nur geringe Kompressionsraten, P- und B-Frame bieten eine vergleichsweise effektive Kompressionen an: hier werden vereinfacht gesagt nur die Veränderung zu vorherigen oder zukünftigen Frames kodiert.

Abbildung 2: MPEG-1 Videostrom Struktur nach [LU,96]

Abbildung 2 zeigt die Einordnung von GOP in die Gesamtstruktur eines MPEG-1 Videostroms. Detailliert soll der Aufbau hier nicht erläutert werden. An dieser Stelle genügt es festzuhalten, das ein eine Videosequenz aus mehreren GOP besteht, die wiederum in verschieden Frames und tiefere logische Einheiten unterteilt werden können. Eine GOP enthält dabei mindestens einen I- Frame, der als Referenz- und Einstiegspunkt bei der Wiedergabe des Videostroms dient. Ausführliche Informationen zur Datenstruktur bietet [LU,96] und die MPEG-1 Spezifikation [ISO05]. MPEG-1 wurde mit dem Ziel entwickelt, Videosignale mit einer Datenrate von rund 1,5 Mbit/s zu kodieren. Maximal sind hier 1,86 Mbit/s bei einer Auflösung von 720x576 Pixel möglich. Bei heutigen Maßstäben ist hiermit also eine mittelmäßige bis gute Videoqualität zu erreichen. Streaming ist aufgrund der üblicherweise relativ hohen Datenraten nur über leistungsfähige Transportkanäle realisierbar.

2.2.3.2 MPEG-2

MPEG-2 nutzt prinzipiell die gleichen Strukturen und Verfahren wie MPEG-1 und enthält ebenfalls separate Spezifikationen für Audio und Video. Es werden jedoch einige wichtige Erweiterungen eingeführt. So sind in MPEG-2 Strömen theoretisch Bildgrößen von 16.383 x 16.383 Pixel möglich. Auch skalierbare Videoströme sind denkbar. Hierbei werden die Bilddaten in 4 Schichten kodiert, welche verschiedene Qualitätsabstufungen bieten. Die dadurch „geschichteten“ Videodaten können zusätzlich priorisiert werden. Durch diese Methoden ist es möglich, Videoströme vor der Wiedergabe an eventuell unterschiedliche Ausgabemedien

17 2. Grundlagen anzupassen. Beinhaltet eine MPEG-2-Datei beispielsweise eine Filmsequenz, kann diese für normale TV-Ausgabegeräte (Main-Level Schicht) und für HDTV-Geräte codiert werden (High- Level Schicht). Bei der Wiedergabe an einem HDTV-Gerät werden High-Level Daten höher priorisiert und somit standardmäßig wiedergegeben. Kommt es bei der Wiedergabe eines Einzelbildes zu Fehlern in dieser Schicht, könnte die Anwendung auf die qualitativ schlechter codierte Main-Level Schicht zurückgreifen und diese Daten wiedergeben. Tabelle 3 zeigt die komplette Liste der im MPEG-2 möglichen Qualitäts-Level Schichten.

SCHICHT MAXIMALE MAXIMALE MERKMALE AUFLÖSUNG BITRATE LOW-LEVEL 352 x 240 4 Mbit/s VHS Qualität MAIN-LEVEL 720 x 480 15 Mbit/s Studio TV HIGH-LEVEL 1.440 x 1.152 60 Mbit/s Endverbraucher HDTV (1440) HIGH-LEVEL 1.920 x 1.080 80 Mbit/s SMPTE 240M Standard

Tabelle 3: MPEG-2 Video Level Spezifikation nach [Lu,96]

MPEG-2 Video zielt auf hochauflösende Videoanwendungen ab: DVD und HDTV sind Beispiele für den Einsatzbereich des Standards. Die Möglichkeiten des Streamings sind im Vergleich zu MPEG-1 besser einzuschätzen. Durch skalierbare Kodierung lassen sich Videodaten besser an heterogene Zielplattformen anpassen. Zusätzlich lassen sich MPEG-2- Daten in zwei verschiedenen Arten ausliefern: als Programm- oder Transportstrom. Ein Programmstrom kombiniert Audio- und Videodaten und ist somit für Umgebungen ausgelegt, die relativ fehlerfrei arbeiten können. Transportströme hingegen trennen einzelne Datenströme und ermöglichen so eine bessere Übertragung über fehleranfällige Transportprotokolle.

2.2.3.3 H.263

H.263 ist ein schon 1995 vom ITU-T vorgeschlagener Standard zur Kompression von Videoströmen auf niedrige Bitraten. Einsatzgebiete sind IP-basierte Videokonferenzen und Videotelephonie. H.263 beschreibt die Struktur eines codierten Videostroms und somit nur die Anforderung an Instanzen zum Kodieren und Dekodieren des übermittelten Datenstroms. Daher werden H.263-Daten in übergeordneten Protokollen und Container-Formaten eingebettet. Das später zu diskutierende FLV-1 nutzt beispielsweise hauptsächlich ein auf H.263 basierenden Codec, um Videodaten zu komprimieren. Besonderheiten der Algorithmen zur Kompression der Rohdaten sollen hier nicht näher diskutiert werden und können in [ITU05] nachgelesen werden. Es genügt an dieser Stelle festzuhalten, das Videodaten auf Bitraten ab 20kBit/s komprimiert werden können und dadurch eine Übertragung in Echtzeit ermöglicht wird. Weitere Anforderungen zur Echtzeitkommunikation und deren Behandlung im H.263-Standard werden folgend beschrieben:

• Kontrolle der Bitrate: Die Bitraten müssen eventuell auf die Gegebenheiten des Transportsystems angepasst werden. Beim Kodieren der Daten wird die erreichte Bitrate überwacht. Übersteigt diese den maximalen Wert für die Zielplattform oder des genutzten Transportkanals (beispielsweise bei dauerhafter starker Bewegung auf dem Bild), muss die Kompressionsrate beim Kodieren kurzzeitig erhöht werden. Dies führt kurzzeitig zu einer geringeren Qualität der Ausgabe, sichert aber die Übertragung der Videodaten in Echtzeit.

18 2. Grundlagen

• Synchronisierung: H.263-Daten enthalten umfangreiche Metainformationen zu kodierten Daten. Hieraus kann die Zugehörigkeit bestimmter Videoframes und deren zeitlicher Bezug beim Dekodieren abgelesen werden. Encoder und Decoder nutzen diese Informationen, um untereinander synchron zu arbeiten.

Üblicherweise werden bei Videokonferenzen auch Audiodaten übertragen. Zur (Inter-Stream-) Synchronisation dieser Audioströme mit den H.263-Strömen auf Empfängerseite können ebenfalls Metainformationen einbezogen werden. Details hierzu werden in H.263 nicht genannt, eingesetzte abstraktere Container-Formate sollen die benötigte Funktionalität zur Verfügung stellen. H.263 bietet bei geringer Bewegung im kodierten Bild sehr gut Kompressionsraten bei vergleichsweise hoher Qualität.

2.2.3.4 Zusammenfassende Bewertung

Analog zu den Betrachten von Audiosignalen wurde in diesen Abschnitt aufgezeigt, dass für die Echtzeitübertragung spezialisierte Verfahren zur Kompression von visuellen Signalen existieren. Aufgrund ihrer Beschaffenheit müssen visuelle Daten meist stärker komprimiert werden, um sie effektiv in Netzwerke verteilen zu können. Zusammen mit den zuletzt vorgestellten Verfahren ermöglichen heutige Netzanbindungen bereits Videokonferenzen in guter bis sehr guter Qualität. Auch aktuelle Web- und Unterhaltungsplattformen, die Videos quasi in Echtzeit an Anwender ausliefern, bieten eine gute Wiedergabequalität.

2.2.4 Containerformate

Daten, die mit den vorgestellten Mediencodecs kodiert wurden, werden üblicherweise in Containerformate eingebettet. Diese Containerformate können neben den eigentlichen Rohdaten Metainformationen beinhalten, die für eine Übertragung der digitalen Signale über WANs und die Dekodierung auf Empfängerseite hilfreich sind. Diese Informationen können beispielsweise für die Beschreibung der beinhalteten Medienströme oder die Zuordnung einzelner Mediensamples zu Wiedergabepositionen genutzt werden. Nachfolgend sollen einige weitverbreitete Containerformate für Audio- und Videodaten vorgestellt und ihre Eignung für ein Streaming diskutiert werden.

2.2.4.1 Ogg Containerformat

Das Ogg Containerformat wird üblicherweise in Verbindung mit den schon vorgestellten freien Codecs Speex und Vorbis verwendet. Im Gegensatz zu später vorgestellten Formaten verzichtet Ogg auf eine abstrakte logische Struktur, sondern organisiert Datenströme in Form von Bitströmen. Diese beinhalten Pages, die wiederum Meta- und Rohdaten zu den kodierten Frames der verwendeten Verfahren aufnehmen. Eine Page bietet dabei genügend Informationen, um die darin enthaltenen Daten zu extrahieren und wiederzugeben. Weitere Informationen aus anderen Pages des Bitstroms werden hierzu nicht benötigt. Einige Metadaten aus dem Header einer Ogg-Page sollen nachfolgend vorgestellt werden:

• Bitstream Serial Number: Ermöglicht einen Zuordnung der physischen Daten, falls multiple Ströme im Ogg-Container vorhanden sind (logische Bitströme).

19 2. Grundlagen

• Page Sequence Number: Für die Synchronisation einzelner logischer Bitströme im Container genutzte fortlaufende ID der Page. Hierdurch können Aussagen über Verluste von Pages während der Übertragung oder Wiedergabe gemacht werden. • CRC Checksum: Zur Fehlerbehandlung werden CRC Prüfsummen angeboten.

Die genannten Metainformationen zeigen, dass Ogg-Container eine gewisse Robustheit bieten und verschiedene Verfahren zur Fehlerbehandlung implementiert werden können. Weiterführende Informationen zum Aufbau eines Page-Headers und allgemein zum Ogg- Containerformat bietet [PFE03].

2.2.4.2 Advanced System Format

Das Advanced System Format (ASF) definiert ein Containerformat zur Speicherung von koordinierten, digitalen und multimedialen Daten. Ursprünglich wurde ASF als Advanced Streaming Format eingeführt. In der Literatur ist diese Bezeichnung auch heute noch zu finden und deutet auf das hauptsächliche Einsatzgebiet des Datenformats hin: die sequentielle Übertragung von zeitkontinuierlichen Daten in verteilten Systemen. ASF definiert dabei nur die Struktur der abgelegten Daten, prinzipiell können beliebig komprimierte oder unkomprimierte Datenströme aufgenommen werden. In [MIC04] werden die wichtigsten Entwurfsziele von Microsoft zusammengefasst:

• Unterstützung von effektiver Wiedergabe von Media - Servern, HTTP - Servern, und lokalen Speichermedien. • Unterstützung von skalierbaren, digitalen Medientypen wie Audio und Video. Eine digitale Komposition soll auf verschiedenen Zielplattformen präsentierbar sein (z.B. bei verschiedenen Bandbreiten). • Autoren sollen Kontrolle über Beziehungen zwischen digitalen Medienströmen haben. • Das Format soll unabhängig von Plattformen, Kommunikationsprotokollen oder Betriebssystemen einsatzfähig sein.

Abbildung 3 zeigt die Top-Level Struktur eines ASF-Containers. Hierbei wird der Objektorientierte Ansatz beim Entwurf des Formats deutlich: getypte Objekte enthalten Metainformationen oder Rohdaten der Datenströme.

20 2. Grundlagen

File Properties Object Header Stream Properties Object Object Header Extension Object

Weitere Objects (optional) Data Paket 1

Data Data Paket 2 Object ... Data Paket n Index Object 1 Optionale Index Object 2 Top-Level Objects ... Index Object k

Abbildung 3: Struktur eines ASF Containers

Digitalisierte Daten werden in Form von Datenpaketen im nur einmalig vorhandenen ASF- Daten-Objekt abgelegt. Datenpakete beinhalten üblicherweise digitalisierte Signale eines Medienstroms, können aber auch Daten verschiedener Ströme bereithalten. Die Sortierung der Pakete innerhalb des Daten-Objekts basiert auf dem Zeitpunkt, wann die Pakete abgespielt bzw. gesendet werden sollen, der so genannten Send Time. Der Inhalt eines Datenobjektes wird zusammenfassend in Tabelle 4 dargestellt.

FELD BESCHREIBUNG GRÖßE Object ID Die ID des ASF Objekts, in diesem Fall 16 Byte „ASF_Data_Object“ Object Size Größe des Datenobjekts, in Spezialfällen auch 0 für 8 Byte „unbekannt“ möglich File ID Eindeutige ID für die Datei 16 Byte Total Data Packets Anzahl der Datenpakete 8 Byte Reserved Reserviertes Feld 2 Byte Data Packets Die Liste der Datenpakete Variabel Tabelle 4: ASF Daten-Objekt

Informationen zur Fehlerkorrektur schließen sich Beschreibungen der eigentlichen Nutzlast des Datenpakets an. Hier werden beispielsweise die Paketlänge, die Send Time und die Wiedergabedauer der Rohdaten angegeben. Nach dieser Sequenz von Metadaten folgen mit dem Feld Payload Data die Nutzdaten des Datenpakets. Hier werden neben weiteren Informationen wie der ID des Datenstroms schließlich die Mediendaten in Form eines Byte- Feldes gespeichert. Es gibt diverse Möglichkeiten, Audiosamples und Videoframes in Payloads abzulegen. Die ASF Spezifikation bietet hier genauso wie für detaillierte Feldinformationen genügend Informationen zur Vertiefung an. Es wird empfohlen, für Datenströme Top-Level Index Objekte anzulegen. Diese enthalten Steuerinformationen zur Wiedergabe der Daten. Vereinfacht gesagt werden in Index-Objekten Paket-IDs auf die Präsentationszeit abgebildet. ASF ist beliebig erweiterbar. Durch den Objektorientierten Ansatz und Bereitstellung von reservierten Feldern können eigenen Erweiterungen eingebracht werden, ohne die Spezifikation zu verletzen. Metainformationen zu Datenströmen werden in verschiedene Strukturen bereitgehalten. Allgemeine Informationen zum Inhalt der Datenströme können auf einer oberen Ebene über eigene Objekte bereitgestellt werden.

21 2. Grundlagen

Mittels ASF können Inhalte für verschiedene Zielplattformen angepasst werden. Ein über ein verteiltes System wie das Internet darzustellende Audiopräsentation kann beispielsweise mit Audiocodecs in verschiedenen Bitraten kodiert und gebündelt in einer Datei auf einem Streaming-Server abgelegt werden. Bei Abspielen der Datei hat die Client-Applikation nun die Möglichkeit, den für sie günstigsten Datenstrom auszuwählen. In einer ASF-Datei besteht theoretisch die Möglichkeit, 127 verschiedene Datenströme zu speichern.

2.2.4.3 Flash Video Format

Abschließend zu den Betrachtungen verschiedener Containerformaten soll das derzeit im Internet häufig genutzte Flash Video Format in Version 1 (FLV-1) vorgestellt werden. Abbildung 4 zeigt die grundlegende Struktur von FLV-1.

Abbildung 4: FLV-1 Struktur und FLV - Tags

Das Feld Data Offset gibt die Größe des Headers an. Aus diesem Wert lässt sich folglich das Startbit der Daten ablesen. In der obersten logischen Ebene werden Daten in Form von Tags dargestellt. Diese können als Datenpakete verstanden werden. FLV-Tags enthalten zunächst Metainformationen zu den enthaltenen Rohdaten. Neben dem Typ (bspw. Audio oder Video) und der Größe des Pakets können über die Felder Timestamp und Timestamp Extended Informationen zur Wiedergabeposition der Pakete angegeben werden. Diese Werte beziehen sich immer auf die Wiedergabeposition des ersten FLV-Tags. Das Attribut StreamID ermöglicht perspektivisch das Ablegen multipler Audio- oder Videoströme. In FLV-1 wird dieses Feld aber noch nicht genutzt. Das Daten-Feld innerhalb eines FLV-Tags enthält neben den Rohdaten noch zusätzlich benötigte Informationen, beispielsweise zu den verwendeten Kompressionsverfahren. FLV-1 unterstützt eine Reihe von Audio- und Videocodecs. Als Beispiele seien hier MP3 beziehungsweise Sorenson H.263 genannt. Letzterer ist ein auf den bereits vorgestellten Standard H.263 basierender Videocodec. FLV gewinnt heute zunehmend an Bedeutung. Die bereits hohe Reichweite des proprietären Formats wird durch zahlreiche Mehrwertdienste für Internet-Anwender weiter gesteigert: kostenfreie Video Plattformen wie YouTube oder Google Video nutzen FLV als Medium zur Verbreitung von Videoströmen. Bei FLV handelt es sich um ein bedingt quelloffenes Containerformat. Die Fähigkeiten des Streamings hängen von den verwendeten Codecs der einzelnen Datenströme ab. Die Ausrichtung ist aber klar abzusehen und wird durch die derzeitigen praktischen Einsatzgebiete deutlich: FLV soll eine effektive Übertragung multimedialen Daten über verteilte Netze realisieren. Durch die Verwendung von Sorenson

22 2. Grundlagen

H.263 und MP3 zur Kodierung sind niedrige Datenraten bei guter Qualität möglich. Problematisch für Entwickler ist mitunter die Lizenzierungspolitik von Adobe: ohne entsprechende Rechte ist es praktisch nicht möglich, Applikationen zu entwickeln, die Flash (und somit auch FLV) verarbeiten können. Für das Streaming von Medien mittels FLV bietet Adobe eine eigene Client-Server Lösung: der Flash-Media-Server kann Daten an Clients ausliefern, die Flash lokal unterstützen.

2.2.4.4 Zusammenfassende Bewertung

Containerformate ermöglichen das Einbetten und die Beschreibung multimedialer Datenströme. Dabei existieren Entwicklungen wie ASF, die auch die Möglichkeit bieten, Endanwender alternative Audio- bzw. Videoströme zu offerieren. Die Komplexität der Formate spielt dabei bei der effektiven Übertragung in verteilten Systemen eine Rolle. Mit FLV-1 wurde ein abschließend ein Containerformat vorgestellt, das eine einfache Struktur und somit geringen Overhead bei einem Transport bietet. Die bereits erwähnten und aktuell sehr erfolgreichen Unterhaltungsplattformen im World-Wide-Web wie YouTube oder Google-Video nutzen FLV innerhalb ihrer Architektur zur Realisierung ihrer Dienste.

2.2.5 Zusammenfassung

In diesem Abschnitt wurde versucht, ein Einblick in die Thematik der Multimedia-Formate zu bieten. Eine vollständige Betrachtung des Themengebiets ist aufgrund der sich bietenden Fülle von Codecs und Formaten im Zuge der Bearbeitung dieser Aufgabenstellung nahezu unmöglich. Es bleibt herauszustellen, dass für eine Echtzeitkommunikation in Audio- und Videokonferenzen zumeist spezialisierte Verfahren eingesetzt werden. Auditive Signale werden in diesen Anwendungen üblicherweise mit Sprachcodecs kodiert. Diese bieten eine unzureichende Wiedergabequalität bei beliebigen Audiosignalen wie Musik. Analog verhält es sich bei Videosignalen: auch in Videokonferenzen werden hauptsächlich spezialisierte Codecs eingesetzt, die auf eine geringe Variation der Einzelbilder eines Videostroms ausgelegt sind. Aktuelle Entwicklungen bieten jedoch die Möglichkeit, auch qualitativ hochwertige und beliebige visuelle Daten zu verteilen. Containerformat enthalten üblicherweise mit Audio- und Videocodecs komprimierte Datenströme. Sie beschreiben diese umfassend und ermöglichen so eine rechnergestützte Verarbeitung. Diese Verarbeitung besteht bspw. aus der Zuordnung einzelner Pakete eines Datenstroms zu einer Wiedergabeposition. Auch die Synchronisierung unter logisch verknüpften Medienströmen wird so ermöglicht. Zusätzlich bieten Containerformate die Möglichkeit, Anwendern alternative Datenströme anzubieten. Die Anwendung zur Wiedergabe des Formats kann hier entscheiden, welcher der Datenströme mit den bereitstehenden Ressourcen auf dem lokalen System optimal wiedergegeben werden kann. Dies führt zum einem zu einer Steigerung des Nutzererlebnisses und umgeht eine zeitaufwendige Adaption des Medienstroms (und somit eine hohe Antwortzeit nach Anforderung des Clients). Die Thematik der Adaption bei einem Streaming von Medienströmen soll im nachfolgenden Abschnitt noch vertieft werden. Dieser soll auch in bestehende Architekturen und Ansätze zur Integration von Streaming einführen.

23 2. Grundlagen

2.3 Streaming - Architekturen

Das Streaming von Mediendaten wurde bisher eher intuitiv behandelt und weniger im Detail erläutert. In diesem Abschnitt werden nun entsprechende Architekturen vorgestellt und Beispiele für Streaming Anwendungen aufgezeigt.

2.3.1 Klassisches Client-Server Streaming

Unter klassischem Streaming wird im Kontext dieses Dokuments der Client-Server Ansatz bei der Übertragung von Datenströmen unter Echtzeitbedingungen verstanden. Ein Streaming- Server (in der Literatur auch häufig „Media-Server“) bietet multimediale Daten in Form von Datenströmen an. Clients, die diese Daten abrufen möchten, melden sich am entsprechenden Server an und starten über bestimmte Aufrufe bzw. Befehle die Übertragung. Im Kontext des Streamings müssen noch einige andere Punkte durchlaufen werden. So müssen QoS-Parameter definiert und ausgehandelt werden. Diese QoS-Parameter müssen regelmäßig während der Übertragung auf ihren Bestand kontrolliert werden. Tritt beispielsweise ein zu hoher Paketverlust bei der Übermittlung des Datenstroms auf, muss der Client dies dem Server zeitnah mitteilen können.

Streaming Server

Datenhaltung

Auslieferung

Management

Kommunikation Aushandlung Transport Steuerung

Client Client

Abbildung 5: Vereinfachte Architektur klassisches Mediastreaming

Eine vereinfachte Architektur eines Streamingszenarios zwischen Server und Client zeigt Abbildung 5. Zentrale Aufgaben der Aushandlung des Medienstreamings zu Beginn einer Sitzung sind die Übermittlung von Informationen zu den hinterlegten Daten und die Aushandlung von QoS-Parametern. Während der Übertragung (Transport) sollten neben den Paketen des Medienstroms Statusinformationen ausgetauscht werden, um den Erfolg der Verbindung zu überprüfen. Später werden Systeme vorgestellt, die diesen

24 2. Grundlagen

Informationsaustausch auch bidirektional implementieren. Auch Server können so Informationen an verbundene Clients senden.

Definition 7: Eine Streaming-Session beschreibt eine zustandsbehafttete und zeitlich begrenzte Verbindung zwischen zwei Kommunikationspartnern, bei der neben Metainformationen zeitkontinuierliche Daten über ein Streaming ausgetauscht werden.

Um ein effektives Streaming zu realisieren, müssen Informationen zum Zustand der Session abgelegt werden. QoS-Parameter und andere Metainformationen müssten ohne Zustandsspeicherung bei jeder Anforderung von Datenpaketen neu ausgehandelt werden: der Overhead wäre in diesem Falle zu groß. Mögliche zu speichernde Informationen lassen sich aus den bisherigen Ausführungen ableiten: bei der Übertragung eines Videostroms kann der Server beispielsweise die Bildschirmauflösung oder die unterstützten Codecs beziehungsweise Medienformate des Zielsystems ablegen. Klassisches Client-Server Streaming ist aktuell weit verbreitet. Heutige Anwendungen, die auf der Infrastruktur des World-Wide-Webs aufbauen, nutzen diese Form der Datenübertragung, um multimediale Datenströme an Endnutzer auszuliefern, die die Inhalte dann ohne größere Verzögerungen darstellen können. Beispiele hierfür sind Internet-Radio-Systeme wie SHOUTcast und Videoplattformen wie Youtube (vgl. 2.2.4.3). Ersteres nutzt das in 2.2.2.2 vorgestellte MP3 zur Verteilung von Musikströmen. Die Bereitstellung einer zentralen Instanz bietet den Vorteil der Bündelung von Anwendungslogik. Für den Fall des Ausfalls des Servers müssen natürlich weitgreifende Maßnahmen eingeplant werden. Hier können beispielsweise hochspezialisierte Content Delivery Networks (CDN) zum Einsatz kommen, um die Daten effektiv zu replizieren. Um die Funktionalität des klassischen Streamings näher zu erläutern, gibt Abschnitt 2.4 einen Überblick über hierfür verwendete Transport- und Kontrollprotkolle.

2.3.2 Kollaboratives Streaming

Kollaboratives Streaming erweitert den bisher geprägten Streaming-Begriff um den Aspekt der gemeinsamen Verwendung von Sitzungen und multimedialen Datenströmen innerhalb einer Gruppe von Anwendern. Es sind Szenarien und Anwendungen denkbar, in denen eine Mehrzahl von Anwendern zeitgleich einen Medienstrom betrachten möchte. Auch der Transfer des lokalen Zustands eines Teilnehmers innerhalb der Gruppe ist vorstellbar: in einem Late-Join Szenario könnte ein definierter Referenzzustand der kollaborativen Streaming-Sitzung an den neuen Teilnehmer transferiert werden, woraufhin dieser mit dem aktuellen Zustand der Gruppe synchronisiert wird.

Definition 8: Eine kollaborative Streaming-Session erweitert den klassischen Begriff der Streaming-Sitzung um die Möglichkeit, beliebig viele Kommunikationspartner aufzunehmen. Dabei werden lokale Zustände der Teilnehmer zumeist unter Zuhilfenahme eines Referenzzustandes synchronisiert, um einen gemeinsamen Zustand innerhalb der Gruppe zu ermöglichen.

25 2. Grundlagen

Abbildung 6: Architektur kollaboratives Streaming aus [KBW06]

Abbildung 6 zeigt die grundlegende Architektur eines in [KBW06] vorgestellten Systems, das kollaboratives Streaming ermöglicht. Eine im Vergleich zu klassischem Streaming neu eingeführte Instanz, der Collaborative Streaming Service (CoSS), sorgt für die Vermittlung von Medienströmen bzw. Informationen über Zustände der Streaming-Sitzung unter den verbundenen Clients. Dieser Service dient als Proxy zwischen einem klassischem Streaming- Server und Client und liefert beispielsweise Methoden zur Steuerung des Streamings, zum Gruppenmanagement und der Adaption von Datenströmen. Diese bereitgestellten Methoden behandeln bereits im Abschnitt 2.1 definierte Anforderungen an verteilte Multimedia-System bzw. verteilte synchrone Groupware und sind somit im Laufe der Arbeit weiter zu betrachten. Im folgendem sollen die Hauptaufgaben des CoSS erläutert werden, die letztendlich die Verwaltung eines gemeinsamen Zustandes und somit ein kollaboratives Streaming innerhalb einer Gruppe von Teilnehmern ermöglichen.

2.3.2.1 Session-Control

Mit dem Begriff Session-Control wird die Kontrolle des Zustandes einer Streaming-Session beschrieben. Im Vergleich zu individuellem Streaming sind im kollaborativen Fall zusätzliche Anforderungen zu erfüllen:

• Gruppenunterstützung und Identifikation: Verschiedene Rollen müssen definiert werden, um eine Ordnung innerhalb der Gruppe abzubilden. Hierbei ist es notwendig, nicht nur den Nutzer selbst identifizieren zu können, auch Informationen über verschiedene Ressourcen und Ausgabegeräte sollten abrufbar sein. • Definition eines gemeinsamen Zustandes: Für alle Mitglieder eines kollaborativen Streaming Systems muss ein globaler Zustand definiert werden. Dieser wird beispielsweise durch den Moderator der Sitzung gesteuert. • Late-Join Unterstützung: Das Beitreten einer Sitzung nach deren Start muss unterstützt und entsprechend behandelt werden.

26 2. Grundlagen

• Datenadaption: Der Datenstrom muss an die verschiedenen Umgebungen der Nutzer anpassbar sein. Abbildung 6 zeigt diese Datenadaption durch die verschiedene Größe der übermittelten Datenpakete an die verbundenen Clients • Konfliktmanagement: Konkurrierende Zugriffe auf Inhalte müssen effektiv behandelt werden

Vorraussetzung für die Kontrolle von Streaming-Sitzungen ist deren adäquate Beschreibung. Nur so können Zustände repliziert und letztendlich transferiert werden. Mit dem Transfer einer Sitzung soll im nächsten Abschnitt die zweite Kernfunktion des CoSS vertieft werden.

2.3.2.2 Session-Transfer

Zwei grundsätzliche Möglichkeiten zum Transfer von Sitzungen können unterschieden werden: entweder der Besitzer einer Session möchte diese an andere Teilnehmer übertragen (Push) oder der Transfer einer Session wird von Teilnehmern angefordert (Pull). In beiden Fällen muss entschieden werden, ob die Session kopiert oder verschoben werden soll. Im letzteren Fall wird die Session und somit die Wiedergabe beim ursprünglichen Besitzer gestoppt und beim neuen Besitzer an der letzten festgehaltenen Stelle fortgesetzt. Unter dem Begriff Session versteht man in diesem Kontext eher die Beschreibung der Streaming-Sitzung: neben der Quelle des Datenstroms werden beispielsweise die aktuelle Wiedergabeposition der Gruppe übertragen. Somit kann ein neuer beigetretener Teilnehmer die Sitzung an entsprechender Stelle der Wiedergabe fortführen.

27 2. Grundlagen

2.3.2.3 Zusammenfassung

Durch die aufgezeigten Funktionen ist es möglich, Sitzungsinformationen von Teilnehmern zu verwalten und auszutauschen. Somit wird ein kollaboratives Streaming realisierbar. Im Vergleich zum klassischen Streaming synchronisieren sich Teilnehmer nicht autark über eine zentrale Instanz wie einen Streaming-Server, sondern können über den CoSS Zustände anderer Teilnehmer adaptieren und so in bestehende Sitzungen eintreten. Dabei können Teilnehmer mit bestimmten Rollen (bspw. ein Moderator) als Referenzen zur Ermittlung eines gemeinsamen Session-Zustandes dienen. Mit dem in [KBW06] vorgestelltem System wird somit gezeigt, wie eine Architektur für die Integration von Medienstreaming unter Berücksichtigung eines gemeinsamen Zustands einer Sitzung mit multiplen Teilnehmern realisiert werden kann. Dabei nutzt das System Methoden und Protokolle eines klassischen Streamings, um Teilaufgaben wie die Übertragung der Medienströme oder die Steuerung der Wiedergabe zu realisieren. Einige dieser Protokolle sollen in Abschnitt 2.4 erläutert werden, um einen tieferen Einblick in die für ein Medienstreaming benötigte Funktionalität zu bieten.

2.3.3 Network-Integrated Multimedia Middleware

Der Transfer von Streaming-Sessions wurde im letzten Abschnitt als ein Ansatz zur Realisierung eines kollaborativen Streamings vorgestellt. Zusätzlich existieren Systeme, die den Zustand einer Streaming-Sitzung feingranularer abzubilden: Komponenten der Verarbeitung von multimedialen Datenströmen können in Netzwerken verteilt und synchronisiert werden. Als ein Vertreter dieser Systeme soll an dieser Stelle die Network-Integrated Multimedia Middleware (NMM) und die darin enthaltenen Ansätze zur Realisierung eines synchronisierten Streamings in verteilten Systemen vorgestellt werden.

2.3.3.1 Verteilte Flussgraphen

Abbildung 7: Verteilter Flussgraph für die Wiedergabe einer MP3-Datei (aus [LOH05])

Abbildung 7 zeigt Komponenten und die Konzeption der NMM am Beispiel der Wiedergabe einer MP3-Datei. Die Kernkomponenten eines Flussgraphen (Nodes) sind dabei für

28 2. Grundlagen

Teilaufgaben einer Verarbeitung zuständig und können über so genannte Jacks mit benachbarten Knoten kommunizieren und Datenströme weiterleiten. An der in der Abbildung dargestellten Wiedergabe der MP3-Datei sind drei Klassen von Nodes beteiligt:

• Generic Read Node: Diese Komponente liest den Medienstrom ein und leitet die komprimierten Audiosamples einen benachbarten Node weiter. • MPEG Audio Decode Node: Dieser Node dekodiert empfangene MPEG-Audioströme. • Playback Node: Der finale Node ist für die Wiedergabe des Audiostroms zuständig.

Die Architektur der NMM erlaubt es, Komponenten eines Flussgraphen im Netzwerk zu verteilen: in der Abbildung wird beispielsweise die Quelle auf Host 1 eingelesen, die weitere Verarbeitung findet auf Host 3 statt. Die Steuerung der der einzelnen Komponenten wird über Interfaces (INode) durch die Applikation auf Host 2 vorgenommen.

2.3.3.2 Synchronisierung verteilter Flussgraphen

Das Beispiel in Abbildung 7 zeigt das prinzipielle Konzept eines verteilten Flussgraphen zur Verarbeitung eines Medienstroms. Ein im Zusammenhang mit dieser Arbeit besonders interessanter Aspekt ist die Synchronisierung einzelner Nodes.

Abbildung 8: Synchronisierung von Nodes in der NMM (aus [LRS03])

In Abbildung 8 ist das Prinzip der Intra- sowie Inter-Stream-Synchronisierung innerhalb der NMM dargestellt. Die Idee der Synchronisierung in der NMM beruht darauf, Datenströme mit Timestamps zu versehen. Diese zeigen an, wann der entsprechende Inhalt dargeboten werden soll. Interne Controller eines Sink-Nodes (bspw. ein Node, der Audiodaten wiedergibt) gleichen nun die eingehenden Daten und entsprechende Timestamps mit der lokalen Zeit ab und können entscheiden, ob eine Anpassung der Darstellung vorgenommen werden muss. Hierzu wird die reale Latenz der Übertragung berechnet und mit einem vordefinierten Wert (theoretische Latenz) abgeglichen. Für eine Inter-Stream-Synchronisierung kommunizieren die lokalen Controller mit einem Synchronizer und können so zusätzliche Anpassungen der Darbietung vornehmen. Wie Abbildung 7 zeigt, können Nodes auch im Netzwerk verteilt werden. Das beschriebene Konzept der Synchronisierung kann also prinzipiell auf den verteilten

29 2. Grundlagen

Anwendungsfall ausgeweitet werden. Hierbei sind weitere Randbedingungen zu beachten, die ausführlich in [LRS03] beschrieben werden. An dieser Stelle genügt es festzuhalten, dass die NMM für verteilte Anwendungen auch Konzepte wie die Verwaltung einer gemeinsamen Sitzung und deren automatische Verteilung bereithält (Session-Sharing).

2.4 Echtzeit - Protokolle

Klassische Transportprotokolle wie TCP/IP sind für eine Übertragung multimedialer Daten schlecht geeignet. Ein Grund ist die fehlende Betrachtung von Anforderungen an die Übertragung multimediale Daten beim Entwurf dieser Protokolle: der Fokus liegt bei TCP/IP beispielsweise auf einer verbindungslosen und fehlerlosen Übertragung von Hypertext- Dokumenten von einem Server zu einem Client. Eine schnelle Antwortzeit durch den Server ist natürlich von Vorteil, steht aber nicht im Vordergrund. Im Kontrast dazu ist bei der Übertragung von multimedialen Daten der Begriff Echtzeit von hoher Bedeutung. Mit der RTP- Protokollfamilie sollen in diesem Abschnitt Protokolle vorgestellt werden, die heute bei der Echtzeitübertragung von umfangreichen und multimedialen Inhalten eingesetzt werden. In Abbildung 9 sind diese Protokolle einführend dargestellt. Sie definieren Nachrichten und Abläufe für die nachfolgenden Aufgaben:

• Transport von Mediendaten (RTP) • Steuerung der Übertragung und Wiedergabe (RTSP) • Kontrolle der Übertragung (RTCP) • Reservieren von Ressourcen (RSVP)

Abbildung 9: RTP und assoziierte Protokolle in der Übersicht

RSVP steht für Resource Reservation Protocol und wird in dieser Arbeit nicht detailliert erläutert. Es hat vereinfach gesagt die Aufgabe, weiterführende QoS-Parameter vor dem Streaming auszuhandeln und entsprechende Ressourcen freizugeben. Näheres zu diesem Protokoll kann in [BZB+97] nachgelesen werden.

30 2. Grundlagen

2.4.1 Realtime Transport Protocol

Das Realtime Transport Protocol (RTP) definiert ein Paketformat für die Übertragung von Medienströmen. RTP ist eine Entwicklung der Internet Engineering Task Force (IETF) und liegt seit 2003 in einer überarbeiteten Form vor ([SCF+03]). Einige wichtige Funktionen, die RTP bietet, sollen nachfolgend aufgezählt werden:

• Identifikation von Payload-Typen: In RTP-Paketen sind Informationen über den Inhalt der Rohdaten zugänglich. • Sequenz Nummerierung: Die Protocol Data Units (PDUs), also die logischen Datenpakete, können sequentiell nummeriert werden. Hierdurch wird beispielsweise das Erkennen und die Behandlung von Pakteverlusten während der Übertragung ermöglicht. • Timestamps: Durch die Angabe von Zeitmarken der Pakete ist eine Synchronisierung multipler Datenströme (bspw. eines Audio- und Videostroms) möglich. Eine Timestamp repräsentiert den Zeitpunkt der Aufnahme der ersten Informationseinheit innerhalb des Pakets. • Monitoring: Es wird die Möglichkeit geboten, die Auslieferung der Datenpakete zu überwachen.

Diese Funktionen sind durch die Struktur einer RTP-PDU erkennbar. Aufbauend auf der zugrunde liegenden Spezifikation soll diese nun anhand einer Abbildung beschrieben werden.

Version Padding Extension # CSRC-IDs Marker Payload Typ Sequenz Nummer

Timestamp

SSRC-ID

CSRC-ID (optional)

Erweiterungen (optional)

DATEN

Abbildung 10: RTP Header mit anschließendem Datenpaket

Abbildung 10 zeigt die Struktur einer RTP-PDU. Die folgende Beschreibung der Felder beschränkt sich auf für die Aufgabenstellung zentrale Punkte. Eine ausführliche Beschreibung der RTP-Pakete bietet die bereits erwähnte Spezifikation. Die Funktion der Sequenznummer und der Timestamp wurde bereits erläutert: hiermit kann die Zuordnung der Datenpakte zu Wiedergabepositionen und somit eine Synchronisierung der Pakete realisiert werden. Über den Payload Typ können Aussagen zum eigentlichen Inhalt der Datenpakete getroffen werden. Zur Synchronisation kann eine sogenannte Synchronisation Source (SSRC)-ID angegeben werden. Diese ist nichts anderes als die Quelle des zum jeweiligen RTP-Paket zugehörigen Datenstroms. Nach den Header-Informationen folgt

31 2. Grundlagen schließlich der Payload, also die Rohdaten des Datenpakets, die die eigentlichen Mediensamples enthalten. Die Kodierung dieses Payloads kann dabei variieren: RTP spezifiziert nicht, welche Formate als Payload abgelegt und wie diese kodiert werden können. Hierzu sind zusätzliche Spezifikationen notwendig: so werden beispielsweise in [HFG+98] und [FIN01] Payload- Formate für MPEG Audio- und Videoformate beschrieben. Auch wenn die Benennung „Real-time Transport Protocol“ Anderes vermuten lässt, wird RTP wird innerhalb des ISO/OSI Schichtenmodells der Anwendungsschicht zugeordnet. In der Praxis wird zumeist das User Datagram Protocol (UDP) als verbindungsloses Protokoll in der Transportschicht genutzt. Der Verbindungsaufbau zwischen Server und Client läuft also nach Vorgaben anderer Protokolle ab. Durch die Nutzung von RTP sind noch keine QoS Garantien ableitbar. Es werden keine Mechanismen für ein rechtzeitiges oder zeitlich korrektes Versenden von Paketen definiert. Hierzu müssen zusätzliche Protokolle wie Reservation- oder Kontrollprotokolle eingesetzt werden. Einige dieser Protokolle, die in der Praxis in Verbindung mit RTP eingesetzt werden, werden folgend diskutiert.

2.4.2 Real-time Control Protocol

Das Real-time Control Protocol (RTCP) wird wie RTP in [SCF+03] spezifiziert. Es führt Funktionen zur Kontrolle von RTP-Übertragungen und somit Methoden zur Realisierung von QoS innerhalb von RTP Sitzungen ein. In der Spezifikation werden vier Hauptaufgaben von RTCP definiert:

• Distribution Feedback: RTCP bietet Funktionen, die die Kontrolle der Übertragung von RTP-Paketen ermöglichen. Dabei werden Rückmeldungen sowohl durch den Sender als auch durch den Empfänger der Daten realisiert. Mit diesen Informationen kann beispielsweise im Zuge eine Fehlerbehandlung durch den Sender bestimmt werden, ob ein globaler Übertragungsfehler vorliegt oder ein Fehlverhalten nur bei einzelnen Empfängern vorliegt. • Persistente IDs für Sender: Im Fehlerfall kann sich die SSRC - ID eines Senders ändern. RTCP hält für diesen Fall eine für die Dauer der RTP-Sitzung persistente Canonical Name-ID (CNAME-ID) bereit. Hiermit ist es auch nach Wiederaufnahme einer Datenübertragung und somit Neuvergabe einer SSRC-ID möglich, Teilnehmer einer Sitzung eindeutig zu identifizieren. • Send Rate: Um Punkte 1 und 2 effektiv nutzen zu können, müssen alle Teilnehmer einer Sitzung RTCP Pakete austauschen. Bei Szenarien mit vielen Teilnehmern kann es so zu einem regen Austausch von Kontrollinformation kommen. RTCP beschreibt Methoden zur Anpassung des Kontrollflusses in solchen Szenarien. • Minimale Kontrollinformationen: Es ist nicht immer für alle Anwendungen nötig oder sinnvoll, alle vorherigen Funktionen zu integrieren. Eine formlose und für jedermann offene Audiokonferenz benötigt mitunter keine persistenten IDs zu jedem Teilnehmer. Eine RTCP-Instanz könnte in solchen Szenarien beispielsweise nur das Feedback zur Übertragung kontrollieren.

Um diese genannten Funktionen zu realisieren, definiert RTCP verschiedene Datenpakete. Exemplarisch sollen hier die Inhalte der Pakete RTCP-Sender Report (RTCP-SR) und RTCP- Receiver Report (RTCP-RR) vorgestellt werden.

32 2. Grundlagen

INHALT BESCHREIBUNG SSRC-ID SSRC-ID des Senders des kontrollierten RTP-Stroms Timestamp Zeitmarke, wann das Paket versendet wurde (im Network Time Protocol Format) Packet Count Anzahl der Pakete, die versendet wurden Octet Count Anzahl der Payload-Oktetts, die versendet wurden Tabelle 5: Inhalt eines RTCP-SR Pakets nach [BK06]

Die wichtigsten Felder eines RTCP-SR Pakets sind in Tabelle 5 dargestellt. Diese Pakete werden von der Quelle eines Datenstroms in regelmäßigen Abständen an die Empfänger übermittelt. Hiermit ist eine Einschätzung der erreichten Übertragungsqualität an den Endpunkten der RTP-Sitzung möglich. Die Timestamp ist dabei im Network Time Protocol (NTP) Format kodiert. Näheres zu diesem Protokoll lässt sich in [MIL92] nachlesen.

INHALT BESCHREIBUNG SSRC - ID SSRC-ID des Senders des kontrollierten RTP-Stroms Paket Lost Anzahl der verlorenen Pakete seit dem letzten RTCP-RR-Pakets. Highest Sequence Die höchste erhaltene Sequenznummer des RTP- Datenstroms. Number LSR Zeitmarke, wann das letzte RTCP-SR Paket erhalten wurde. DLSR Zeitdifferenz zwischen der Timestamp des letzten RTCP-SR Pakets und dessen Erhalt. Tabelle 6: Inhalt eines RTCP-RR Pakets nach [BK06]

Tabelle 6 listet einige der wichtigsten Informationen innerhalb eines RTCP-RR Pakets auf. Sie dienen der Quelle des RTP-Datenstroms als Kontrolle der erreichten Qualität auf Empfängerseite. Die Felder LSR und DLSR werden dabei wiederum mittels NTP beschrieben und ermöglichen direkte die Kontrolle von Echtzeiteigenschaften der Datenübertragung. Alle durch RTCP austauschbaren Pakete und somit Informationen lassen sich in der Spezifikationen nachlesen. Hier soll ein grober Überblick genügen, um die Möglichkeiten der Kontrolle von RTP-Datenströmen mittels RTCP aufzuzeigen. RTCP ist dabei im ISO/OSI Schichtenmodell der selben Schicht wie RTP zuzuordnen. Es wird also logisch parallel zu RTP betrieben und nutzt ähnliche Transportwege.

2.4.3 Real-time Streaming Protocol

Das Real-time Streaming Protocol (RTSP) ist ebenso wie RTP eine Entwicklung der IETF. Das Protokoll liegt standardisiert als RFC 2326 vor (vgl. [SRL98]) und beschreibt Mechanismen zur Kontrolle von Datenübertragungen mit Echtzeiteigenschaften. RTSP wird logisch noch über Protokollen wie RTP angesiedelt. RTSP ähnelt im Aufbau und der verwendeten Syntax dem Hypertext Transport Protocol (HTTP). Durch die Verwendung der Syntax von HTTP ist RTSP leicht verarbeit- und erweiterbar. Tabelle 7 zeigt einige in RTSP definierten Nachrichten und ihre Bedeutung im Zusammenhang mit der Kontrolle von Streaming-Sitzungen. Hier wird vom Standpunkt einer vom Client initiierten Anfrage ausgegangen.

33 2. Grundlagen

NACHRICHT BESCHREIBUNG OPTIONS Fragt Einstellungen des Servers ab und enthält benötigte Einstellungen des Clients. DESCRIBE Fordert eine Beschreibung des Inhaltes einer RTSP URL an. Dabei kann der Client auch Informationen über unterstützte Medienformate an den Server übergeben. SETUP Mit SETUP werden Einzelheiten zur Übertragung der Daten ausgehandelt. Hier werden beispielsweise das genutzte Protokoll zur Datenbeschreibung (RTP) oder die Ports angegeben, welche auf Empfängerseite zur Verfügung stehen. PLAY Nach einem erfolgreichen Austausch von SETUP Request und Response kann mit PLAY die Übertragung des Datenstroms durch den Client angefordert werden. Hierbei sind auch Zeitangaben (in Sekunden) möglich, um beispielsweise die Wiedergabe zu einem bestimmten Zeitpunkt im Datenstrom zu starten. PAUSE Die Übertragung des Datenstroms wird pausiert. RECORD Hiermit können aufgenommene Datenströme an RTSP-URLs übermittelt werden. Ein Server kann so eingehende Datenströme aufzeichnen und weiterleiten. TEARDOWN Alle Übertragungen werden gestoppt und die Verbindung wird abgebaut. Tabelle 7: RTSP-Requests (Auszug)

Auf eine komplette Betrachtung aller Requests soll hier verzichtet werden. In [SRL98] sind sämtliche Methoden mit Beispielen und dazugehörigen Antworten detailliert beschrieben. Es bleibt festzuhalten, dass RTSP zur Anforderung von Datenströmen, der Aushandlung von Optionen vor deren Transport und schließlich der Steuerung einer Sitzung Verwendung findet.

2.5 Multimedia-Frameworks: Microsoft DirectShow

Die automatisierte Verarbeitung multimedialer Daten erfordert Erfahrung und Kenntnisse komplexer Algorithmen, die beispielsweise bei Kompression innerhalb von Multimediaformate zum Einsatz kommen. Multimedia-Frameworks analysieren typische Aufgaben im Umgang mit multimedialen Daten und bieten dem Entwickler abstraktere Schnittstellen und Methoden an. Eine Low-Level Programmierung von Aufgaben wie die Wiedergabe einer Audiodatei über die Ausgabegeräte am speziellen System ist nicht mehr notwendig. Programmierfehler in der Implementierung können durch den geringeren Aufwand und die überschaubare Komplexität minimiert werden. Diese Methodik entlastet nicht nur Softwareentwickler, auch Anbieter von Hardware können speziell für Multimediaframeworks optimierte Geräte entwickeln. Mit DirectShow soll an dieser Stelle ein Multimedia Framework und Application Programming Interface (API) aus Sicht der Entwicklung multimedialer Anwendungen für Windows- Plattformen vorgestellt werden.

34 2. Grundlagen

2.5.1 Architektur

DirectShow basiert auf dem Component Object Model (COM) von Microsoft. Hierbei handelt es sich um ein proprietäres Modell zur Entwicklung von Softwarekomponenten. Ein COM- Objekt ist eine solche Softwarekomponente und stellt definierte Schnittstellen, Dienste und Methoden zur Verfügung. So standardisierte Komponenten können effizient und unkompliziert untereinander kommunizieren und interagieren. Innerhalb des DirectShow Frameworks treten so genannte Filter als Komponenten auf. Diese bieten dem Entwickler verschiedene Funktionalitäten. Abbildung 11 zeigt den Verbund verschiedener Filter zur Wiedergabe einer AVI-Datei. Diese Kombination von Filtern zur Verarbeitung eines Quellmediums in DirectShow wird als Filtergraph bezeichnet.

Abbildung 11: DirectShow Filtergraph aus [MIC07]

Im Beispiel sind bereits vier mögliche Funktionen von Filtern erkennbar:

• File Source-Filter lesen multimediale Daten aus der angegebenen Quelle als Bytestrom ein. • Splitter-Filter teilen den eingehenden Bytestrom in verschiedene Ausgabeströme. Eine Datei im AVI-Format beinhaltet üblicherweise getrennte Audio- und Videoströme. In Abbildung 11 werden diese durch einen AVI-Splitter voneinander losgelöst und getrennt weiter verarbeitet. • Transform-Filter komprimieren oder dekomprimieren Dateiformate. Hier kommt ein AVI-Decompressor zum Einsatz, um die Videodaten aus der eingelesenen AVI-Datei zu verarbeiten. • Rendering-Filter sorgen schließlich für die Ausgabe der Daten auf Ausgabegeräten oder behandeln Schreiboperationen auf dem Dateisystem.

Analog zum Splitter-Filter können auch die hier nicht dargestellten Mux-Filter als eine Gruppe von Filter-Komponenten aufgeführt werden. Diese kombinieren mehrere Eingabeströme zu einem Ausgabestrom. Ein Anwendungsbeispiel für Mux-Filter ist die getrennte Aufnahme von Audio- und Videosignalen bei anschließender Speicherung in einem Datencontainer. In diesem Szenario kommen auch Wrapper-Filter zum Einsatz: diese repräsentieren Aufnahmegeräte und nehmen die Daten in Form von Byteströmen auf. Anwendungsentwickler können diese Filter durch standardisierte Schnittstellen und Methoden unkompliziert erstellen, ansprechen und miteinander kombinieren. Eine aus Sicht des Entwicklers komplexe Aufgabe wie die Wiedergabe von Informationen aus AVI-Containern kann so durch wenige Codezeilen implementiert werden. Besonderheiten der Ausgabegeräte

35 2. Grundlagen können durch Device-Filter angesprochen werden. Im Beispiel wird bei der Audioausgabe darauf verzichtet und ein standardisierter DirectSound Device-Filter verwendet. Diese Softwarekomponente gibt nun die auditiven Daten am standardmäßig eingestellten DirectSound-Ausgabegerät wieder. DirectSound ist Bestandteil des DirectX-SDK und eine eigene Softwarekomponente, die einen komfortablen Zugriff von Applikationen auf Audio- Hardware ermöglicht. Der in Abbildung 11 dargestellte Filtergraph nutzt also DirectSound zur Audioausgabe, für Bilddaten kann ein weiterer Bestandteil von DirectX verwendet werden: DirectDraw. Dieses Prinzip ermöglicht das Ausnutzen spezieller Eigenschaften von Hardware-Komponenten auf dem Zielsystem bei vergleichsweise geringem Aufwand. Sind keine DirectX-Ressourcen vorhanden, nutzt DirectShow das Graphical Device Interface (GDI) zur Ausgabe visueller- und WaveOut zur Wiedergabe auditiver Datenströme. GDI und WaveOut sind Grundbestandteile jeder Windows-Plattform und ermöglichen so in jedem Falle die Wiedergabe multimedialer Rohdaten. Vorraussetzung bleibt die erfolgreiche Umwandlung von Dateiformaten in Datenströme, die die Komponenten verarbeiten können. DirectShow unterstützt standardmäßig eine große Anzahl von Containerformaten, und Kompressionsverfahren. Die anschließende Liste erhebt keinen Anspruch auf Vollständigkeit und soll diese breite Unterstützung verdeutlichen:

• Windows Media Audio • Windows Media Video • MPEG Video und Audio • MPEG Audio Layer-3 (MP3, nur Dekompression) • Advanced Systems Format (ASF) • Audio-Video Interleaved (AVI) • Andere: MPEG-4, WAV, AIFF, AU, SND, MIDI

Dem Entwickler wird zusätzlich die Möglichkeit geboten, eigene DirectShow-Filter zu implementieren. Somit ist beispielsweise die nahtlose Einbindung eigener Kompressionsverfahren oder Routinen zu Behandlung spezieller Ausgabegeräte möglich. Durch die konsequente modellbasierte Architektur können diese Komponenten leicht wieder verwendet und mit Standard-Filtern kombiniert werden.

2.5.2 Anwendungsbeispiel

Wie bereits erwähnt, kann unter einem Filtergraph die Kombination mehrer Filter zur Lösung einer Aufgabe im Umgang mit multimedialen Datenströmen verstanden werden. DirectShow bietet die Möglichkeit, komplette Filter-Graphen (beispielsweise zur Wiedergabe einer Datei) automatisch zu erstellen. Realisiert wird diese automatische Erstellung komplexer Strukturen beispielsweise durch die Methode RenderFile der Klasse FilterGraphManager.

36 2. Grundlagen bool SimplePlayer::Play(CString filepath) { // init COM HRESULT hr = CoInitialize(NULL);

// create IGraphBuilder hr = CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER, IID_IGraphBuilder, (void **)&pGraph);

hr = pGraph->QueryInterface(IID_IMediaControl, (void**)&pControl); hr = pGraph->QueryInterface(IID_IMediaEvent, (void **)&pEvent);

// autocreate FilterGraph for file @ filepath hr = pGraph->RenderFile(LPCTSTR(filepath), NULL); if (SUCCEEDED(hr)) { // run FilterGraph hr = pControl->Run(); if (SUCCEEDED(hr)) { // wait for completition long evCode; pEvent->WaitForCompletion(INFINITE, &evCode); } } // release ressources … return true; } Listing 1: Konstruktion eines Filtergraphen mit RenderFile

Eine Methode zur Wiedergabe von Medienströmen wird in Listing 1 dargestellt. Zur Vereinfachung wurden auf Fehlerbehandlungsroutinen bei der Initialisierung der COM- Bibliothek und des FilterGraphManagers verzichtet. Durch den Aufruf pGraph- >RenderFile(LPCTSTR(filepath), NULL) wird der Filtergraph zur Wiedergabe der Datei unter dem Pfad filepath erstellt. Dabei kann es sich um einen lokalen Pfad oder eine URL handeln. Auch das Format des Medienstroms muss vom Entwickler vorerst nicht beachtet werden: der FilterGraphManager versucht mit den vorhandenen Informationen, die passenden Filter zur Wiedergabe des Stroms zu erstellen und zu kombinieren. Befinden sich auf dem System die dafür notwendigen Ressourcen, lässt sich das Playback durch den Aufruf der Methode Run() des Interfaces IID_IMediaControl starten. Die Klasse FilterGraphManager implementiert Methoden der Schnittstellen IID_IMediaControl und IID_IMediaEvent. Letztere bietet Methoden zur Überwachung des Filtergraphen an. In diesem einfachen Beispiel wird nach dem Start der Wiedergabe bis zu deren Ende gewartet (pEvent->WaitForCompletion(INFINITE, &evCode)). Dieses Anwendungsbeispiel soll aufzeigen, dass sich die Wiedergabe eines Medienstroms für Entwickler mit Hilfe der DirectShow-SDK durchaus unkompliziert gestalten kann. Für komplexere Anwendungen ist es aber üblicherweise notwendig, Filter von Hand zu initialisieren und zu einem Filtergraphen zu verbinden. Das DirectShow-SDK bietet hierzu mit GraphEdit ein Tool an, mit welchem sich die Kombinationen von verschieden Filtern zu Verarbeitung einer Datei vor der eigentlichen Umsetzung in Quellcode testen lassen kann. Zusätzlich kann es zum Entwurf und zur Visualisierung komplexer Verarbeitungsschritte dienen.

37 2. Grundlagen

Abbildung 12: Filtergraph in GraphEdit

Abbildung 12 zeigt ein durch das Tool GraphEdit erzeugten Filtergraph zur Wiedergabe eines ASF-Containers. Der Datenstrom ist entfernt abgelegt und enthält Videodaten in Form von WMV- und Audiodaten in Form von WMA-Strömen. Zu Beginn wird der entfernte ASF-Strom mit dem des WM ASF Reader-Filter unter Angabe einer URL lokalisiert, eingelesen und in jeweils einen Audio- und Videostrom aufgeteilt. Diese werden mit entsprechenden Filtern (WMVideo Decoder DMO - und WMAudioDecoder DMO - Filter) dekodiert und an assoziierte Renderer-Filter gesendet. Diese sorgen dann für die Wiedergabe der Daten am entsprechenden Ausgabegerät. Der VideoRenderer-Filter sendet das dekodierte Videosignal in diesem Fall an den ebenfalls dargestellten ActiveMovie-Dialog. Die Soundausgabe wird durch den AudioRender-Filter an das DirectSound-Ausgabegerät der Plattform gesendet. Um dieses Wiedergabeszenario in Quellcode umzusetzen, genügt die in Listing 1 aufgezeigte Methode: der Parameter filepath innerhalb der Funktion SimplePlayer::Play() muss hier nur auf die URL des entfernten ASF-Containers zeigen. Im obigen Beispiel sind auch die Schnittstellen zur Kommunikationen einzelner Filter dargestellt: Pins ermöglichen es, Datenströme von einem Filter an andere verbundene Filter weiterzugeben. Zusätzlich sind Informationen über die zu erwartenden Daten an einzelnen Pins abrufbar. Setzt man den Filtergraph manuell um, müssen nach der Erstellung der benötigten Filter die Ausgabe- und Eingabe-Pins mit entsprechenden Befehlen verbunden werden. DirectShow bietet hier neben der konkreten Methode ConnectDirect() der Klasse FilterGraphManager auch eine abstraktere Möglichkeit an. Kann ein Ausgabe- und ein Eingabe-Pin nicht direkt verbunden werden, ergänzt das System den Filtergraph beim Aufruf von FilterGraphManager::Connect() um die fehlenden Filter.

2.5.3 Streaming in DirectShow

Die vorangegangenen Betrachtungen beschreiben grundlegende Methoden zur Lokalisierung, Verarbeitung und Wiedergabe von Mediendaten innerhalb des DirectShow-SDK. Nachfolgend

38 2. Grundlagen soll genauer auf die Anforderungen und benötigten Ressourcen für ein Streaming von multimedialen Daten eingegangen werden.

2.5.3.1 Einlesen entfernter Quellen

Im Vergleich zur Wiedergabe einer Datei von lokalen Datenträgern wird beim Streaming von Medienströmen üblicherweise auf entfernte Datenquellen zugegriffen. Die bisher vorgestellten Source-Filter müssen durch Filter ersetzt werden, die auch Datenströme einlesen können, die durch URLs adressiert sind. DirectShow bietet hierzu auch Standard-Filter an. Der File Source (URL)-Filter liest entfernt abgelegte Formate wie AVI, MPEG und WAV asynchron ein. Für Formate, die auf ASF basieren, bietet sich die Nutzung des WM ASF Reader-Filter an.

2.5.3.2 Transcoding

Die Datenadaption wurde als eine Anforderung an verteilte und heterogene Multimedia- Systeme genannt. Die Bereitstellung verschiedener Datenströme für heterogene Zielplattformen kann beispielsweise durch ASF-Container und entsprechend hierarchisch kodierte Medienströme gewährleistet werden. Liegt nur ein kodierter Datenstrom vor, muss dieser eventuell vor der Wiedergabe umgewandelt, also transkodiert, werden. Im DirectShow-SDK können hierfür diverse Transform-Filter genutzt werden. Der in Abbildung 12 dargestellte WMAudioDecoder DMO - Filter kann beispielsweise ohne Weiteres mit einem MPEG-Layer-3- Compression-Filter verbunden werden, um den WMA-Audiostrom nach dem Dekodieren in das MP3-Format umzuwandeln. Es sind auch eigene Tansform-Filter denkbar, die die Umwandlung von Datenströmen in definierte Formate und Qualitätsstufen bündeln.

2.5.3.3 Synchronisierung

Eine Schwierigkeit bei der Übertragung und anschließenden Wiedergabe von Multimediaströmen ist die Sicherstellung der internen Synchronität einzelner Datenströme (Intra-Stream-Synchronisierung). Diese wird üblicherweise intern von DirectShow gewährleistet: hierbei kann ein definierter Filter als Referenz, also als eine Art interne Uhr, genutzt werden. In Abbildung 12 dient der Audio-Renderer-Filter als Referenz zur Synchronisierung von Audio- und Videostrom.

2.6 Streaming in Konferenzsystemen: WebEx

Mit dem WebEx Meeting Center (kurz WebEx) soll in diesem Abschnitt ein Konferenzsystem vorgestellt werden, das bereits die kollaborative Wiedergabe multimedialer Medien unterstützt. WebEx ist eine Internetkonferenz-Lösung der Firma WebEx Communications. Nach [FLA04] konnte die Organisation im Jahr 2004 mit 57% Marktanteil die Marktführerschaft im Bereich der Internetkonferenz-Applikationen übernehmen. WebEx bietet dem Nutzer umfangreiche Funktionen und nutzt dabei die Infrastruktur des Internets und modernste Entwicklungen im Bereich der Softwareergonomie und Benutzerschnittstellen. Die grundlegenden Funktionen der Applikation sollen im folgendem aufgezeigt werden.

39 2. Grundlagen

2.6.1 Grundfunktionalität

WebEx wurde als Konferenzsystem vorgestellt. Die Software erlaubt in erster Linie eine Konferenz unter verschiedenen entfernten Teilnehmern abzuhalten und bietet dabei Funktionen zur Kommunikation, Koordination und Kooperation. In der zugrunde liegenden Ausführung sind beispielsweise Module zur Kommunikation via Video- und Audiokonferenz integriert. Darüber hinaus werden Funktionen zum Shared-Viewing von (statischen und dynamischen) Inhalten oder des gesamtes Desktops des Teilnehmers geboten (Desktop-Sharing). Einige dieser Funktionen sollen nachfolgend anhand einer Abbildung genauer beschrieben werden.

Abbildung 13: WebEx-MC Content Sharing (Screenshot Live-Demo [WEB07]).)

Die Kombination von Aspekten der Kommunikation, Kooperation und Koordination wird in Abbildung 13 gezeigt. In diesem Beispiel wird eine Folienpräsentation von Nutzer „Bob“ geleitet. Dieser präsentiert anderen Teilnehmern Inhalte und kann diese durch integrierte Kommunikationsmodule kommentieren (dargestellt ist eine parallele visuelle Kommunikation). Funktionen eines Whiteboards werden ebenfalls angeboten: Nutzer können Notizen auf Folien hinterlassen oder Teile eines Dokuments durch Markierungen hervorheben. Für den Kontext der Arbeit ist die Realisierung der dargestellten Funktionen nicht vorrangig, soll aber auf den Umstand hinweisen, dass üblicherweise multiple Daten innerhalb existierender Konferenz-Sitzungen ausgetauscht werden. Entsprechende Wechselwirkungen sind auch bei der Bearbeitung der Aufgabenstellung zu berücksichtigen. Da das Ziel der Arbeit die Integration von Medienströmen in verteilter synchroner Groupware ist, soll nachfolgend ein Blick auf entsprechende Funktionen in WebEx geboten werden.

40 2. Grundlagen

2.6.2 Streaming von multimedialen Inhalten

Praktisch in jedem Anwendungsfall von WebEx kann ein Streaming von audiovisuellen Daten angestoßen werden: so wird in Abbildung 13 eine Live-Quelle (von einer Webcam) als Videostrom von Bob übertragen und bei dem lokalem Nutzer dargestellt. Diese Form von Streaming wird heute zumeist von Konferenzsystemen geboten, um einen benutzerfreundliche Kommunikation zu ermöglichen und somit den Grundstein für eine Kooperation einer Gruppe zu legen. Für die weitere Arbeit weitaus interessanter ist das Streaming beliebiger multimedialer Inhalte innerhalb des Shared-Viewing Moduls von WebEx.

Abbildung 14: kollaborative Wiedergabe eines Videos in WebEx

In Abbildung 14 werden zwei WebEx-Frontends von verschiedenen Nutzern bei der kollaborativen Wiedergabe eines Videos gezeigt. Das linke Fenster stellt den Moderator und somit den präsentierenden Teilnehmer innerhalb der Konferenz dar. Zur kollaborativen Wiedergabe werden in der Applikation folgende Aktionen durchlaufen:

1. Der Moderator importiert den Medienstrom, das heißt er öffnet über einen Dialog eine lokale Mediendatei. 2. Ein Wiedergabefenster wird daraufhin in die Applikation integriert. Im Falle von WebEx wird ein eingebetteter Windows Media Player zur Wiedergabe verwendet. 3. Möchte der Moderator eine synchronisierte Wiedergabe starten, wird die Datei komplett an entsprechende verbundene Teilnehmer übertragen. 4. Erst nach vollständiger Übertragung kann die Wiedergabe bei entfernten Teilnehmern und Moderator beginnen.

41 2. Grundlagen

Dieser Ablauf verdeutlicht, dass WebEx kein Streaming von beliebigen Inhalten im üblichen Sinne bietet (vgl. Definition Streaming in 0): der Datenstrom muss zunächst komplett übertragen werden, bevor die Wiedergabe einsetzen kann. Für Szenarien, in denen beliebig großen Mediendateien verteilt werden müssen, ist damit eine zeitnahe und somit benutzerfreundliche Wiedergabe praktisch unmöglich. Dennoch kann die dargestellte Funktionalität als Orientierung für eine mögliche Integration der kollaborativen Wiedergabe in die Benutzeroberfläche eines Konferenzsystems dienen.

2.7 Zusammenfassung

In diesem Kapitel wurden die Grundlagen für die Analyse und die sich anschließende praktische Bearbeitung der Aufgabenstellung gelegt. Es wurde definiert, was in diesem Dokument unter verteilter synchroner Groupware und Multimediasystem zu verstehen ist und welche allgemeinen Anforderungen entsprechende Applikationen erfüllen müssen. Diese Betrachtungen helfen bei der Analyse der Aufgabenstellung und dem Entwurf von eigenen Lösungsansätzen. Um das Streaming multimedialer Inhalte effektiv realisieren zu können, wurden verschiedene Medienformate vorgestellt und auf Ihre Besonderheiten in Bezug auf Struktur, Kompressionsraten und ihre Eignung für eine Übertragung in verteilten Netzwerken untersucht. Neben dem klassischem Client-Server-Streaming wurden mit dem kollaborativen Streaming einen mögliche Architekturen für ein Streaming von multimedialen Daten in verteilter, synchroner Groupware vorgestellt. In diesem Zusammenhang wurde auch ein Einblick auf spezialisierte Streaming-Protokolle geboten. Hier wurden mit RTP zur Definition der Paketstruktur und RTCP bzw. RTSP zur Kontrolle bzw. Steuerung der Paketübertragung wichtige Vertreter diskutiert und eingeordnet. Schließlich wurde mit WebEx ein umfangreiches Konferenzsystem und eine verteilte Groupware vorgestellt, die neben Modulen zur Kommunikation eine umfangreiche Unterstützung für Content-Sharing bietet. Hier werden multimediale Datenströme in Teile der Gesamtanwendung integriert und unter mehreren Teilnehmern einer Sitzung verteilt. Bei dem Shared-Viewing von zeitkontinuierlichen Multimedia-Formaten wird in WebEx eine kollaborative Wiedergabe innerhalb einer Gruppe realisiert, ohne ein echtes Streaming der Medien zu bieten.

42 3. Analyse

3. ANALYSE

Nachdem Kapitel 2 versucht, ein grundlegendes Verständnis für Begriffe wie Groupware, Multimedia und kollaboratives Streaming zu vermitteln und einige technische Heraus- forderungen im Umgang mit entsprechenden Applikationen aufzeigt, sollen in Kapitel 3 konkrete Anforderungen an ein System identifiziert werden, das multimediale Datenströme in verteilte synchrone Groupware-Anwendungen integriert. Hierbei soll zunächst ein Szenario den möglichen Ablauf eines Streamings verbal beschreiben. Aus dieser allgemeinen Beschreibung lassen sich konkrete Anforderungen an obig beschriebenes System ableiten.

3.1 Szenario

Zur genaueren Definition der Anforderungen wird nachfolgend ein Szenario beschrieben. Hiermit soll die grundsätzliche Funktionalität einer kollaborativen Wiedergabe multimedialer Daten in einer verteilten synchronen Groupware abgebildet werden. Abbildung 15 stellt das Szenario graphisch dar, um die folgenden Ausführungen zu veranschaulichen.

[1]

Arthur Bill [3] [1] [2]

[4] Charles Damia

Zugriffsarten synchron wahlfrei

Abbildung 15: Szenario kollaborative Wiedergabe multimedialer Daten

43 3. Analyse

Ausgangssituation In einem weltweit agierenden Softwareunternehmen wird ein Groupware-System für Meetings in kleineren Gruppen genutzt. Die Groupware bietet zur Kommunikation der Nutzer Video- und Audio-Conferencing sowie den Austausch von Textnachrichten an (Chat und Instant Messaging). Zusätzlich sind Module für die kollaborative Präsentation und Bearbeitung von Inhalten vorhanden (Content Sharing und Application Sharing). Beim Transport der Daten kommen IP-basierte Protokolle zum Einsatz. Die Groupware wird im Unternehmen für Meetings einzelner Projektteams genutzt. Arthur ist Projektleiter eines kleinen Teams und hat eine Sitzung mit allen Teammitgliedern einberufen. Zu Beginn dieses Szenarios ist die Sitzung bereits mit Arthur, Bill und Charles eröffnet worden. Arthur stellt über das Content Sharing das Protokoll der letzten Sitzung vor. Hierbei kommunizieren die Teilnehmer über die vorhandenen Kommunikationskanäle. Später soll dem Meeting noch ein weiteres Teammitglied beitreten: Damia. Vorbereitung und Start des Streamings Während der Session möchte Arthur ein lokal abgespeichertes Audiomemo synchronisiert präsentieren. Synchronisiert bedeutet hier, das die Wiedergabe des Audiostroms bei allen Teilnehmern zeitgleich startet und möglichst auch im Verlauf der Sitzung in einem gewissen Rahmen der Vorgabe von Arthur folgt. Arthur öffnet die entsprechende Audiodatei in der Oberfläche der Groupware und startet deren Wiedergabe. Daraufhin wird das Audiomemo bei Arthur lokal abgespielt und eine Übertragung der Audiodaten zu Bill und Charles initiiert. Bei diesen entfernten Teilnehmern startet ebenfalls die Wiedergabe [1]. Pause und Seek Nach einer Minute der Wiedergabe erinnert sich Arthur daran, dass das Audiomemo in den nächsten Minuten für das Meeting nur irrelevante Informationen bietet. Daraufhin pausiert er die Wiedergabe und springt 3 Minuten vor. Da Bill und Charles einen mit Arthur abgestimmten Zustand anstreben, wird auch bei ihnen nach entsprechender Meldung von Arthur die Wiedergabe ab Minute 4 fortgesetzt. Synchronisation während der Übertragung Bei Charles kommt es während der Übertragung zu Verbindungssproblemen. Die Wiedergabe des Audiomemos gerät dadurch ins Stocken und Charles verlässt den synchronen Zustand der Gruppe. Das System synchronisiert ihn daraufhin mit dem Zustand des aktuellen Presenters der Sitzung (Arthur): die lokale Wiedergabe wird gestoppt und die Übertragung des Audiomemos mit einem gewissen Offset neu initiiert. Im Laufe der Sitzung kommt es erneut zu dieser Situation. Charles lehnt nun die Synchronisierung ab, da er einen zu großen Informationsverlust durch die erneute Unterbrechung der Wiedergabe befürchtet. Er greift nun wahlfrei auf den Medienstrom zu [2]. Late-Join und wahlfreie Wiedergabe Im weiteren Verlauf der Sitzung tritt Damia der Sitzung bei. Die Übertragung des Audiostroms setzt bei Damia schnellstmöglich bei der zuletzt übermittelten Wiedergabeposition von Arthur ein [3]. Damia möchte der Gruppe zusätzlich eine lokal abgelegte Videoaufnahme zur Verfügung stellen. Diesen möchte sie aber nicht synchronisiert wiedergeben: Teilnehmer der Sitzung sollen wahlfrei auf diesen Inhalt zugreifen können, ohne dass Damia selbst den Videostrom wiedergeben muss. Charles greift in der Folge wahlfrei auf den von Damia offerierten Videostrom zu [4].

44 3. Analyse

Wechsel des Presenters Arthur wird während der Session am Telefon verlangt. Daraufhin will er die Rolle des Presenters an einen der anderen Teilnehmer weitergeben und die Sitzung kurzzeitig verlassen. Aus Zeitgründen verzichtet er auf eine konkrete Auswahl und überlässt es dem System, einen Nachfolger zu bestimmen. Daraufhin wird Bill als neuer Presenter ausgewählt. Der Audiostrom wird folgend nach Vorgaben von Bill gesteuert und synchronisiert. Ende der Session Nachdem die Wiedergabe des Audiomemos bei Bill beendet wurde, möchte dieser beginnen, andere Punkte der Tagesordnung abzuarbeiten. Aus den gesammelten Statusinformationen weiß er, dass ein Teilnehmer wahlfrei auf das Audiomemo zugreift: die Wiedergabe bei Charles hat sich im Vergleich zum Presenter mittlerweile um 30 Sekunden verzögert. Bill kündigt über die schon vor dem Streaming aktiven Kommunikationskanäle an, dass die Sitzung nun fortgesetzt wird. Charles pausiert das aktuelle Streaming, um das Meeting weiter verfolgen zu können. Später wird er das Streaming ggf. an der letzten Position fortsetzen oder wiederaufnehmen können.

3.2 Anforderungen

Nachfolgend werden Anforderungen an ein System für die Integration von Medienströmen in eine verteilte synchrone Groupware beschrieben. Einige dieser Anforderungen lassen sich direkt aus dem in Abschnitt 3.1 beschriebenen Szenario ableiten, andere wurden bereits im Grundlagenkapitel angedeutet und sollen nun konkretisiert werden. Die Kriterien werden dabei zur besseren Übersicht nach Bereichen geordnet und jeweils kurz erläutert. Eine Segmentierung nach Muss- und Kannkriterien wird in einer zusammenfassenden Tabelle im Abschnitt 3.3 vorgenommen.

3.2.1 Wiedergabe

/R1/ Wiedergabe von multimedialen Datenströmen Innerhalb der Applikation soll es möglich sein, zeitkontinuierliche Medienströme auf den Endsystemen der Teilnehmer wiederzugeben. Eine genauere Unterscheidung der Formate, die dabei unterstützt werden sollen, wird in Abschnitt 3.2.2 geboten. /R2/ Wahlfreier Zugriff auf Medienströme Stellt ein Teilnehmer innerhalb einer Sitzung Medien zur Verfügung, sollen andere Nutzer wahlfrei auf diese Ressourcen zugreifen können. Eine individuelle Wiedergabe von entfernten Medienströmen soll so ermöglicht werden. /R3/ Synchroner Zugriff auf Medienströme Innerhalb einer Konferenz soll es einer Gruppe von Anwendern möglich sein, multimediale Inhalte kollaborativ wiederzugeben. Das heißt, die lokalen Zustände der Wiedergabe bei Teilnehmern verhalten sich im Normalfall untereinander synchron.

45 3. Analyse

/R4/ Steuerung der Wiedergabe Dem Nutzer müssen zur Steuerung der Wiedergabe grundlegende Funktionen eines typischen Mediaplayers zur Verfügung stehen. Teilnehmer sollen die Wiedergabe pausieren und auf bestimmte Positionen im Medienstrom springen können. /R5/ Integrierte Wiedergabe Die Wiedergabe von multimedialen Daten soll in die bestehende Applikation integriert werden. Dabei ist auf Besonderheiten der gebotenen Benutzeroberfläche zu achten: eine Wiedergabe von Medienströmen soll möglichst in der selben Art und Weise integriert werden wie das Darbieten statischer Inhalte. /R6/ Status der Wiedergabe Es muss möglich sein, Informationen über den Zustand der Wiedergabe abzufragen. Tritt ein Nutzer als Quelle einer Übertragung auf, können zusätzliche Informationen zum Status der Wiedergabe bei entfernten Clients geboten werden.

3.2.2 Wiedergabeformate

/R7/ Wiedergabe von einheitlichen Medienformaten Teilnehmer sollen zumindest ein einheitliches Format zur Wiedergabe von auditiven und visuellen Daten unterstützen. /R8/ Unterstützung gängiger Audioformate Gängige Audioformate zur Wiedergabe sollen unterstützt werden: Windows Media Audio; MPEG Audio Layer-3; MPEG AAC und Ogg-Vorbis. Ebenfalls zu berücksichtigen sind entsprechende Containerformate zur Einbettung der kodierten Audiodaten. /R9/ Unterstützung gängiger Videoformate Gängige Formate zur Kodierung und Wiedergabe von Videodaten sollen unterstützt werden: MPEG-1 Video; MPEG-2 Video; H.263; Windows Media Video und ISO MPEG-4 Video Version 1.0. Ebenfalls zu berücksichtigen sind entsprechende Containerformate zur Einbettung der kodierten Videodaten. /R10/ Erweiterbarkeit Teilnehmern soll die Möglichkeit geboten werden, neue Formate und Verfahren zur Kodierung und Wiedergabe von multimedialen Daten in die Applikation zu integrieren. /R11/ Wiedergabe von Animationsformaten Es soll in der Anwendung möglich sein, auch Animationen in Form von Flash-Videos (FLV) wiederzugeben.

46 3. Analyse

3.2.3 Heterogenität

/R12/ Heterogene Plattformen Beim Entwurf muss von heterogenen Zielplattformen ausgegangen werden: es existiert eine Fülle von verschiedenen Medienformaten und assoziierte Kompressionsverfahren, die möglicherweise nicht von allen Client-Systemen unterstützt werden können. Die technischen Gegebenheiten der Teilnehmer sind auch für eine Datenübertragung zu beachten (bspw. Bandbreiten der Transportkanäle). Es besteht durchaus die Möglichkeit, dass Teilnehmer offerierte Inhalte nicht wiedergeben können. Für diesen Fall ist eventuell die Anpassung des Inhalts notwendig. /R13/ Datenadaption Unterstützt ein Teilnehmer ein bestimmtes Medienformat nicht oder können Mindestanforderungen an den störungsfreien Transport der Daten nicht garantiert werden, kann eine Adaption des Datenstroms veranlasst werden. Hierbei wird die Ressource in ein für den Client empfang- und abspielbares Format konvertiert. /R14/ Wiederverwendung von adaptierten Ressourcen Wurde eine Datenadaption einer Ressource durchgeführt, bietet es sich an, diese auch für eine spätere Verwendung abzulegen und entsprechend zu verwalten. Tritt im weiteren Verlauf einer Sitzung ein Client mit ähnlichen technischen Voraussetzungen an den Host heran, kann evtl. eine vormals adaptierte Ressource wiederverwendet werden. /R15/ Transcoding in ein einheitliches Format Neben der Datenadaption nach Vorgaben des Clients kann eine Adaption noch vor Initialisierung der Streaming-Session stattfinden. Die Quelle kann beispielsweise „exotische“ Medienformate in gängige Formate umwandeln um möglichst viele bzw. alle möglichen Eigenschaften von Teilnehmern abzudecken. Hierbei ist auch eine generelle Umwandlung in einheitliche Formate denkbar, die alle Teilnehmer zwingend beherschen müssen. /R16/ Dynamische Installation von Codecs Fehlen für eine Wiedergabe der Ressource bei Client die entsprechenden Codecs, ist ein weiterer Ansatz der Adaption denkbar: Clients können fehlende Codecs anfordern und entsprechend in Ihre Anwendung integrieren.

3.2.4 Synchronisation

/R17/ Synchronisation mit Presenter Für die Realisierung einer kollaborativen Wiedergabe müssen Clients untereinander synchronisiert werden. Als Bezugspunkt soll ein bestimmter Teilnehmer einer Sitzung dienen: der Presenter. Verschieden Arten der Synchronisation sind hierbei zu realisieren. /R18/ Late-Join Synchronisation Verbindet sich ein Teilnehmer zu einer bereits gestarteten synchronisierten Sitzung, soll er sofort mit dem aktuellen Zustand des Presenters synchronisiert werden.

47 3. Analyse

/R19/ Verlassen des synchronen Zustandes Teilnehmern muss es möglich gemacht werden, eine Synchronisierung abzulehnen und den synchronen Zustand einer kollaborativen Wiedergabe zu verlassen. /R20/ Wechsel des Presenters Der Wechsel des Presenters bei einer synchronisierten Wiedergabe soll jederzeit möglich sein. Im Fehlerfall (bspw. ein abrupter Verbindungsabbau des aktuellen Presenters) muss unter den Clients ein neuer Presenter ausgewählt werden.

3.2.5 Datenübertragung

/R21/ Buffering Vor der Wiedergabe einer Position muss auf Seite eines Teilnehmers eine bestimmte Menge von Datenpaketen vorausgeladen werden. Hierzu müssen geeignete Verfahren diskutiert und entworfen werden. /R22/ Prefetching Bringt ein Teilnehmer multimediale Inhalte in die Sitzung ein, ohne sie sofort wiedergeben zu wollen, ist ein Prefetching denkbar. Dabei laden Teilnehmer Pakete des Datenstroms mit niedriger Priorität voraus, falls Ressourcen hierfür vorhanden sind. Bei einer späteren Initiierung der Wiedergabe kann so die Reaktionszeit bis zur eigentlichen Wiedergabe verringert werden.

3.2.6 Import von Medienströmen

/R23/ Lokale Ressourcen Als einfachster Fall soll es für einen Teilnehmer möglich sein, ein lokal abgelegtes Medienobjekt anderen Teilnehmern der Sitzung anzubieten. /R24/ Eingebettete Ressourcen Medienströme können innerhalb der schon bestehenden Konferenz in bereits eingebrachten Inhalten vorkommen. Beispiele für das Content-Sharing sind Audiokommentare auf statischen Inhalten wie Bildern oder eingebettete Videos innerhalb einer kollaborativen Folienpräsentation. Auch Animationen können in Form von Folienübergängen auftreten. Es sind Methoden zur Behandlung und Verteilung solcher Ressourcen zu realisieren. /R25/ Entfernte Ressourcen Medienobjekte können auch auf entfernten Servern vorliegen. Es sind Funktionen zu implementieren, die diese entfernten Medienobjekte für ein kollaboratives Streaming zugänglich machen. /R26/ Zugriffsschutz Digital Rights Management (DRM) schütz Medienobjekte vor unerlaubtem Zugriff bzw. unerlaubter Weitergabe. Vorhandenen DRM-Beschränkungen sollten vor einer Wiedergabe geprüft werden.

48 3. Analyse

3.2.7 Technische Anforderungen

/R27/ Integration in bestehende Protokolle Die für die verschiedenen Funktionen notwendigen Teilprotokolle sollen nahtlos in schon bestehende Protokolle eines Konferenzsystems integriert werden. Bereits definierte Protokollabläufe und Datenstrukturen sollen wieder verwendet und ggf. um entsprechende Bestandteile erweitert werden. /R28/ Wechselwirkungen mit anderen Datenströmen Bei der Integration in schon bestehende Protokolle und Abläufe sind insbesondere die Wechselwirkungen mit anderen Datenströmen zu beachten. Entsprechende Funktionen und Definitionen zur Priorisierung des Streamings von Medien müssen realisiert werden. /R29/ Erhalten der Interaktivität während der Wiedergabe Während der Wiedergabe muss die Interaktivität der einzelnen Clients erhalten bleiben. Es muss ihnen im schon definierten Rahmen möglich sein, die eigene Sicht auf eine Präsentation zu ändern, ohne die Datenübertragung oder Wiedergabe selbst zu beeinflussen.

3.2.8 Sonstige Anforderungen

/R30/ Vorschau für Medienobjekte Für das integrierte Streaming von Medienobjekten ist eine Vorschau zu realisieren. Für Videodaten bietet sich das erste Einzelbild des Videostroms an, während für Audiodaten eine symbolische Darstellung gewählt werden muss. /R31/ Live-Wiedergabe Funktionen zur Integration einer Live-Wiedergabe sind zu implementieren. Hierbei sind vornehmlich visuelle Datenströme (bspw. Aufnahmen einer Webcam) zu berücksichtigen. /R32/ Serialisierung von Datenströmen Empfängt ein Teilnehmer einen entfernten Medienstrom, bietet es sich an, diesen auch lokal abzuspeichern. Funktionen und Formate hierzu müssen realisiert werden.

49 3. Analyse

3.3 Muss- und Kannkriterien

Abschließend sollen alle gestellten Anforderungen in Tabelle 9 zusammenfassend dargestellt werden. Hierbei werden die identifizierten Funktionalitäten in Muss- und Kannkriterien eingeteilt und die Anforderungen nach Entwurf und Implementierung unterschieden.

ID ANFORDERUNG ENTWURF IMPLEMENTIERUNG MUSS KANN MUSS KANN

- Wiedergabe - Wiedergabe von multimedialen /R1/ x x Datenströmen /R2/ Wahlfreier Zugriff auf Medienströme x x /R3/ Synchroner Zugriff auf Medienströme x x /R4/ Steuerung der Wiedergabe x x /R5/ Integrierte Wiedergabe x x /R6/ Status der Wiedergabe x x - Wiedergabeformate - Wiedergabe von einheitlichen /R7/ x x Medienformaten /R8/ Unterstützung gängiger Audioformate x x /R9/ Unterstützung gängiger Videoformate x x /R10/ Erweiterbarkeit x x /R11/ Wiedergabe von Animationsformaten x x - Heterogenität - /R12/ Heterogene Zielplattformen x x /R13/ Datenadaption x x Wiederverwendung von adaptierten /R14/ x x Ressourcen /R15/ Transcoding in ein einheitliches Format x x /R16/ Dynamische Installation von Codecs x x - Synchronisation - /R17/ Synchronisation mit Presenter x x /R18/ Late-Join Synchronisation x x /R19/ Verlassen des synchronen Zustandes x x /R20/ Wechsel des Presenters x x - Datenübertragung - /R21/ Buffering x x /R22/ Prefetching x x - Import von Medienobjekten - /R23/ Lokale Ressourcen x x /R24/ Eingebettete Ressourcen x x /R25/ Entfernte Ressourcen x x Tabelle 8: Zusammenfassung der Anforderungen

50 3. Analyse

ID ANFORDERUNG ENTWURF IMPLEMENTIERUNG MUSS KANN MUSS KANN /R26/ Zugriffsschutz x x - Technische Anforderungen - /R27/ Integration in bestehende Protokolle x x Wechselwirkungen mit anderen /R28/ x x Datenströmen /R29/ Interaktivität während der Wiedergabe x x - Sonstige Anforderungen - /R30/ Vorschau für Medienobjekte x x /R31/ Live-Wiedergabe x x /R32/ Serialisierung von Datenströmen x x Tabelle 9: Zusammenfassung der Anforderungen (Fortsetzung)

51

4. Entwurf

4. ENTWURF

Das Streaming von zeitkontinuierlichen Daten soll im Laufe der Arbeit in den Rahmen einer bestehenden Datenkonferenz eingebunden werden. Zunächst sollen hierzu die zugrunde liegende Entwurfsentscheidungen zusammenfassend aufgeführt und begründet werden. Die eigentliche Integration des Multimedia-Streamings in ein Konferenzsystem und die dafür notwendigen Neudefinitionen von Protokollen und Datenformaten werden in gesonderten Abschnitten des Kapitels betrachtet.

4.1 Entwurfsentscheidungen

Die zu Beginn des Entwurfes getroffenen allgemeinen Entwurfsentscheidungen sollen in diesem Abschnitt vorangestellt werden und einen Überblick zur Herangehensweise des Entwurfes bieten. Speziellere Entscheidungen werden in den entsprechenden Abschnitten dokumentiert. Folgende zentrale Fragen galt es zu Beginn des Entwurfes zu beantworten:

1. In welcher Art und Weise können Streaming-Funktionen in die Groupware integriert werden? 2. Wie kann das Streaming multimedialer Daten in die bestehende Topologie der Groupware eingebunden werden? 3. Welche Streaming Mechanismen sind für eine Integration in synchronen Groupware verwendbar? 4. Welche Eigenschaften müssen innerhalb eines kollaborativen Multimedia-Streamings beschrieben werden und wie findet diese Beschreibung statt? 5. Wie kann die mögliche Heterogenität der Teilnehmer gehandhabt werden? 6. Wie können Multimediaströme unter Teilnehmern einer synchronen Groupware übertragen werden?

In welcher Art und Weise können Streaming-Funktionen in ein bestehendes Konferenzsystem integriert werden? Im Laufe der Arbeit sollen Funktionen für ein Streaming multimedialer Daten in ein bereits produktiv eingesetztes Konferenzsystem eingebracht werden: VidSoft VidConference. Dieses Konferenzsystem beinhaltet bereits umfangreiche Komponenten der Bereiche Audio-, Video- und Data-Conferencing. Vor einer Integration in ein solches bestehendes System muss zunächst geprüft werden, inwieweit diese Systemkomponenten für den Entwurf und die spätere Implementierung wieder verwendet werden können. Ziel dabei ist, eine Maximierung des Nutzererlebnisses bei

53 4. Entwurf zeitgleicher Minimierung des Aufwandes einer späteren Implementierung und Wartung des Gesamtsystems zu erreichen. Während des Entwurfes wurde daher entschieden, das Data- Conferencing Modul um die notwendigen Funktionen für ein Multimedia-Streaming zu erweitern. Hier sind bereits wichtige Funktionen realisiert, die auch bei einem Multimedia- Streaming Anwendung finden können:

• Shared Viewing: gemeinsames Betrachten von statischen Inhalten in einer Gruppe von Anwendern • Session-Management: Verwaltung von Sitzungen der Datenkonferenz • Distribution: Offerieren, Verteilen und Übertragung von Inhaltsobjekten • Shared Workspace Management: Verwaltung einer gemeinsamen Arbeitsumgebung

Diese Funktionseinheiten sind dabei innerhalb eines umfangreichen und modularen Netzwerkprotokolls - dem Content Sharing Protocol (CSP) - in Form von Teilprotokollen realisiert. Es bietet sich daher an, das CSP durch eigene Teilprotokolle um die Funktionen eines Multimedia-Streamings zu erweitern. Einzelheiten zu den Kernfunktionen des CSP können in [SCH07a] nachgelesen werden. Im Abschnitt 4.4 dieses Kapitels werden die wieder verwendeten bzw. erweiterten Teilprotokolle des CSP noch näher diskutiert.

Wie kann das Streaming multimedialer Daten in die bestehende Topologie der Groupware eingebunden werden? Die Integration der Funktionen eines Multimedia-Streamings soll möglichst nahtlos und mit überschaubarem Aufwand erfolgen. Daher orientiert sich der Entwurf an bestehenden Architekturen. Es werden, wenn möglich, bestehende Protokolle zur Lösung von Teilaufgaben wieder verwendet. Im Fall des vorliegenden Systems und des CSP wird eine Client-Server Architektur verwendet, wobei der Server (CS-Server) viele Funktionen bündelt und eine vermittelnde Rolle unter Teilnehmern (CS-Clients) einnimmt. Die Funktionalität zur Realisierung eines Multimedia-Streamings soll in diese bestehenden Content-Sharing Komponenten als Multimedia Streaming Services integriert werden. Im Laufe des Kapitels werden diese Services zur besseren Abgrenzung zu den Begriffen Multimedia Streaming Client (MS-Client) für Services auf Seite des Clients bzw. Multimedia Streaming Server (MS-Server oder MSS) für serverseitige Funktionen zusammengefasst.

Welche Streaming Mechanismen sind für eine Integration in synchronen Groupware verwendbar? Eine Kernanforderung für die Integration von Streaming-Funktionen in synchrone Groupware ist die Verwaltung eines gemeinsamen Zustands innerhalb einer Gruppe von Anwendern (bspw. eine gemeinsame Wiedergabeposition). Klassische Streaming Ansätze (vgl. Abschnitt 2.3.1) bieten diese Möglichkeit nicht ohne entsprechende Erweiterungen. Sie sind für die unabhängige Verteilung eines Medienstroms an Teilnehmer ausgelegt. Für die Realisierung der Aufgabenstellung wird der Ansatz des kollaborativen Streamings (vgl. Abschnitt 2.3.2) verwendet und entsprechend angepasst bzw. erweitert. Hier übernimmt eine zentrale Instanz unter anderem Aufgaben, die die Verwaltung eines gemeinsamen Zustands in der Gruppe ermöglichen. Im nachfolgenden Entwurf übernimmt der bereits genannte MS-Server entsprechende Funktionen.

54 4. Entwurf

Welche Eigenschaften müssen innerhalb eines kollaborativen Multimedia-Streamings beschrieben werden und wie findet diese Beschreibung statt? Zur Realisierung eines Streamings multimedialer Inhalte innerhalb einer Gruppe ist eine detaillierte Beschreibung folgender Entitäten notwendig:

• Sitzung: Informationen zur Art der Sitzung (bspw. Art der Synchronisierung) • Medienströme: Beschreibung der vorliegende Medienformate und Kodierungen • Zustand: Beschreibung eines lokalen und des gemeinsamen Zustands der Streaming- Sitzung • Teilnehmer: Informationen zu unterstützten Formaten und Kodierungen bei Teil- nehmern und, falls vorhanden, entsprechende Präferenzen

Diese Informationen können im Laufe der Arbeit für die Lösung verschiedener Teilaufgaben verwendet werden: die Beschreibung der Sitzung und Medienströme ist beispielsweise bei der Aushandlung der Sitzung zwischen Teilnehmern von Bedeutung, während detaillierte Informationen zu unterstützten Medienformaten einzelner Teilnehmer für eine Adaption von Inhalten herangezogen werden können. Als Format für die angeführten Beschreibungen wird die Extensible Markup Language (XML) gewählt. Definitionen in Form von XML können unkompliziert erweitert werden, sind plattformunabhängig und können somit als zukunftssicher angesehen werden.

Wie kann eine mögliche Heterogenität der Teilnehmer innerhalb einer Sitzung gehandhabt werden? Die mögliche Heterogenität der Teilnehmer einer Streaming-Session muss im Entwurf Beachtung finden. Es soll möglich sein, Medienströme an die Anforderungen und Bedürfnisse der einzelnen Teilnehmer anzupassen. Wie im vorherigen Punkt beschrieben, sollen umfangreiche Informationen zu Teilnehmern und angebotenen Ressourcen gesammelt und verwaltet werden. Diese Informationen können zur Adaption von offerierten Medienströmen genutzt werden: unterstützt ein Teilnehmer das angebotene Format nicht, kann eine Anpassung vorgenommen werden. Dadurch können auch Teilnehmer in die Sitzung eingebunden werden, die beispielsweise durch Einschränkungen Ihrer Netzanbindung oder des Ausgabegerätes ohne Adaption ausgeschlossen wären.

Wie können Multimediaströme unter Teilnehmern einer synchronen Groupware übertragen werden? Für den Transport der Daten unter den Teilnehmern einer Session soll ein eigenes Paket- und Container-Format definiert werden. Letzteres beschreibt dabei nicht die Kodierung des eigentlichen Inhalts, sondern legt nur deren Struktur und Ordnung fest. Im Grundlagenkapitel dieser Arbeit wurden mit dem ASF- bzw. dem RTP-Format bereits vorhandene Lösungen für diese Problemstellung vorgestellt. Da die hier dargestellte Lösung der Aufgabenstellung eventuell in ein kommerzielles Produkt integriert werden soll, ergeben sich zusätzliche Anforderungen an die Formate. Das ASF-Containerformat kann aus patentrechtlichen Gründen nicht als Transportformat für den produktiven Einsatz verwendet werden. Durch zwei Maßgaben beim Entwurf des Transportverfahrens wurde auch das RTP-Paketformat ausgeschlossen: die Minimierung des Overheads während der Übertragung und die Möglichkeit, einen Datenstrom lokal abzuspeichern. In beiden Punkten weißt RTP Schwächen auf. Im Laufe des Entwurfs soll daher ein generisches Containerformat entworfen werden, das sowohl leichtgewichtig als auch frei von Patenten oder Lizenzen ist.

55 4. Entwurf

4.2 Rollenmodell

In diesem Abschnitt soll das im Entwurf festgelegte Rollenmodell einer Multimedia-Streaming Anwendung genauer beschrieben werden. Im Abschnitt 4.1 wurden mit den Begriffen MS- Client und MS-Server bereits die Kernkomponenten der definierten Streaming-Architektur benannt. Die möglichen Unterschiede dieser Komponenten sollen einführend anhand eines Beispielszenarios aufgezeigt werden.

Abbildung 16: Architektur Multimedia Streaming

Das Architekturbild in Abbildung 16 zeigt die im Entwurf identifizierten Rollen eines kollaborativen Multimedia-Streamings. Dargestellt ist ein n:m Streaming zwischen zwei Providern und zwei Viewern über eine zentrale Instanz, dem MS-Server. Provider stellen dabei Datenströme zur Verfügung, während Viewer diese entweder mit einem Presenter (ebenfalls ein MS-Client) synchronisiert wiedergeben oder wahlfrei auf entfernte Medienströme zugreifen. Auf die explizite Benennung der Presenter wurde in der Abbildung aus Gründen der Übersichtlichkeit versichtet. Es soll angenommen werden, dass im Szenario die Provider auch Presenter der jeweiligen Sitzung sind. Dargestellt sind drei Streaming-Sessions, die verbal folgendermaßen beschrieben werden können:

• Client A ÅÆ Client C: Zwischen den Teilnehmern wurde eine synchronisierte Wiedergabe ausgehandelt und eine entsprechende Sitzung aufgebaut. Das heißt die Wiedergabeposition bei Viewer 1 gleicht der eines anderen MS-Clients, dem Presenter der Session. Client C tritt in diesem Szenario als dieser Presenter auf. • Client A ÅÆ Client C: Client A gibt parallel zur ersten Session auch einen Medienstrom von Client D (Provider Video 2) wieder. Erneut wird mit einem Presenter synchronisiert, der in dieser Session ebenfalls durch Client D repräsentiert wird.

56 4. Entwurf

• Client B ÅÆ Client D: Client B greift wahlfrei auf Inhalte zu, die Client D zur Verfügung stellt. In diesem Fall ist der Viewer selbst Presenter der Session. Bei einem wahlfreien Zugriff muss die Wiedergabeposition des Viewer also nicht synchronisiert werden.

In der Abbildung wird auf die Darstellung von bidirektionalen Steuerströmen zwischen MS- Server und MS-Client verzichtet. Nur der Transport soll schematisch gezeigt werden, um einen Einblick in die Vermittlung durch den MS-Server zu geben. Genauere Informationen zur Funktionalität der dargestellten Entitäten und Rollen finden sich in den nachfolgenden Ausführungen.

4.2.1 Multimedia Streaming Clients

Die möglichen Rollen von MS-Clients wurden bereits in Abbildung 16 gezeigt und einführend beschrieben. Nachfolgend sollen diese noch detailliert erläutert werden.

4.2.1.1 Provider

Bei den Providern einer Multimedia-Streaming Session handelt es sich um MS-Clients, die Medienströme für eine synchronisierte Wiedergabe oder einen wahlfreien Zugriff anderer MS- Clients zur Verfügung stellen. Ein Provider ist also zunächst für die Datenhaltung zuständig und bringt Medienströme in die Sitzung ein. Provider sollen jedoch nicht als reine Media-Server verstanden werden: üblicherweise möchte ein Client lokale Inhalte, die er in eine Datenkonferenz einbringt, auch steuern und wiedergeben. Um diese Szenarien abzubilden, kann ein Provider auch die Rolle des Presenters der Session übernehmen.

4.2.1.2 Viewer

Viewer sind Teilnehmer einer Streaming Sitzung, die wahlfrei oder synchron auf entfernte Multimedia-Ressourcen einzelner Provider zugreifen und diese lokal wiedergeben. Vor einer Wiedergabe müssen üblicherweise bestimmte Mengen von Datenpaketen vorliegen (Buffering). Da diese Menge stark vom verwendeten Transport- und Kodierungsformat des Datenstroms abhängt, wird hierzu im Entwurf keine quantifizierte Aussage getroffen. Viewer können Informationen über den lokalen Zustand ihrer Wiedergabe an den MS-Server übermitteln (vgl. Abschnitt 4.2.2). Hierdurch wird eine zentrale Beschreibung und Verwaltung eines globalen Zustandes der Streaming-Session möglich.

4.2.1.3 Presenter

Der lokale Zustand des Presenters dient als Referenz für ein synchronisiertes Streaming innerhalb einer Gruppe. Im Falle einer synchronisierten Wiedergabe eines Medienstroms entspricht das der lokalen Wiedergabeposition eines Medienstroms beim Presenter. Es sind verschiedene Ansätze denkbar, wie ein Presenter den Zustand eines kollaborativen Streamings beeinflussen kann:

• Indirekt: der lokale Zustand des Presenters kann als Soll-Zustand der Session verstanden werden. Dieser Referenzzustand wird an andere Teilnehmer transferiert, die daraufhin entscheiden können, ob ihr lokaler Zustand (Ist-Zustand) zu stark vom Soll-

57 4. Entwurf

Zustand der Sitzung abweicht. Wen dem so ist müssen Maßnahmen zur Re- Synchronisierung eingeleitet werden. • Direkt: ein Presenter könnte die Wiedergabe innerhalb einer Gruppe direkt steuern. In diesem Fall müssen Steuernachrichten an Viewer der Session übermittelt werden, um den synchronen Zustand innerhalb der Gruppe auch nach einer lokalen Steueroperation des Presenters aufrecht zu erhalten.

Der Entwurf eines Mechanismus zur Synchronisierung von Zuständen einer Streaming-Sitzung soll in diesem Kapitel noch weiter vertieft werden: Abschnitt 4.5.3 diskutiert entsprechende Aspekte und verschiedene Lösungsansätze.

4.2.2 Multimedia Streaming Server

Die zentrale Komponente einer Streaming-Session ist der MS-Server. Er bündelt sämtliche Informationen über den aktuellen Zustand der Sitzung und somit der verbundenen Clients. Datenströme und Kontrollinformationen werden stets über den MS-Server übertragen: hierdurch wird eine zentrale Steuerung der Sitzung ermöglicht. Der MS-Server kann im Falle einer synchronisierten Wiedergabe auch als Controller verstanden werden: er sammelt nicht nur Informationen zum Zustand des Presenters der Sitzung, er übermittelt auf Basis dieser Informationen Steuernachtrichten, um asynchronen Viewer wieder in den synchronen Zustand zu versetzen. Abschnitt 4.5.3 diskutiert hierzu Alternativen, die während des Entwurfs in Betracht gezogen worden. Weitere Kernfunktionen des MS-Servers sollen nachfolgend zusammengefasst werden.

4.2.2.1 Buffering von offerierten Medienströmen Die von Providern angebotenen Medienströme werden immer über den MS-Server an Viewer übertragen. Ziel dieses Vorgehens ist die Ermöglichung einer effektiveren Verteilung der Daten innerhalb der Gruppe. Dabei wird vorausgesetzt, dass es sich beim MS-Server in Bezug auf Netzwerkanbindung und Rechenleistung um eine performante Komponente handelt. Während des Entwurfes wurde zunächst geprüft, inwieweit eine komplette Übertragung der Medien von Providern zu MS-Server möglich ist. Der Gedanke wurde im Laufe des Entwurfes verworfen: es wird angenommen, dass die zeitliche Verzögerung gerade bei umfangreichen Inhalten zu groß und für Endnutzer nicht zumutbar ist. Daher wird nachfolgend von einem Buffering der Medienströme beim MS-Server ausgegangen, das heißt es werden Daten zwischengespeichert und schließlich weiterverteilt, auch wenn der Medienstrom noch nicht komplett beim MS- Server vorliegt.

4.2.2.2 Capability Management Ein MS-Server soll Eigenschaften (Capabilities) und Präferenzen der verbundenen MS-Clients verwalten, um ggf. auf Besonderheiten und Wünsche einzelner Teilnehmer reagieren zu können. Auf die Notwendigkeit dieser Verwaltung wurde bereits in Abschnitt 4.1 hingewiesen. Zur Realisierung des Capability-Managements müssen zunächst Formate definiert werden, die Eigenschaften wie unterstützte oder präferierte Medienformate der Teilnehmer beschreiben. Der Entwurf dieser Formate wird in Abschnitt 4.3 vorgestellt.

58 4. Entwurf

4.2.2.3 Datenadaption Auf Basis der Beschreibung von Eigenschaften und Präferenzen eines MS-Clients kann auch eine Anpassung des Medienstroms für diesen vorgenommen werden. Im Entwurf wird nicht definiert, auf welche Art und Weise eine Datenadaption stattfinden kann. Es werden nur die notwendigen Formate und der mögliche Ablauf eines Austausches dieser Informationen zwischen MS-Client und MS-Server beschrieben und der MS-Server als Ort einer Adaption festgelegt.

4.2.2.4 Verteilung von Inhalten an Viewer Hat der MS-Server genügend Datenpakete vom Provider erhalten, kann der Medienstrom verbundenen Viewern offeriert und in einem späteren Schritt an diese übertragen werden. Vor dieser Übertragung kann die Möglichkeit einer Datenadaption für einzelne Clients geprüft werden – die mögliche Heterogenität der MS-Clients wird hierdurch handhabbar.

4.2.2.5 Session Management Der MS-Server eignet sich als zentrale Komponente auch zur Verwaltung von Informationen aktueller Sessions und deren Zustände. Beschreibungen der offerierten Medienströme können durch den MS-Server zentral gesammelt und im Laufe der Sitzung zur weiteren Vermittlung der Inhalte und deren spätere Steuerung verwendet werden. Im einführenden Absatz dieses Abschnittes wurde bereits auf die Kontrollfunktion des MS-Servers hingewiesen. Um diese zu ermöglichen, sind Beschreibungen von Session und Zuständen notwendig. Einzelheiten zum Entwurf dieser Formate findet sich in Abschnitt 4.3, während zentrale Abläufe des Session- Managements noch im Protokollentwurf (vgl. Abschnitt 4.5) vertieft werden.

4.3 Beschreibungsformate

Wie in den vorangegangenen Abschnitten herausgestellt, müssen für die Realisierung der Aufgabenstellung verschiedene Beschreibungsformate definiert werden. Folgende Informationen zu Sitzung und Teilnehmern müssen durch entsprechende Definitionen abgebildet werden:

1. Eigenschaften der Streaming-Session a. Metainformationen zur Session (Name der Sitzung, Provider, …) b. Angaben zum Medienstrom (enthaltene Kodierungen, Transportformate, …) c. Informationen zur Steuerung (initiale Wiedergabeposition, Synchronisierungsart, …) d. Zustandsbeschreibungen 2. Unterstützte Multimedia- und Transportformate eines Teilnehmers 3. Präferenzen eines Teilnehmers

Die im Entwurf definierten Beschreibungsformate bieten diese Informationen. Nachfolgend sollen diese genauer anhand von Beispielen vorgestellt werden.

59 4. Entwurf

4.3.1 Multimedia Streaming - Session Description Format

Exemplarisch soll hier das MS-SDF detailliert vorgestellt werden. Das MS-SDF dient zur Beschreibung der Session und darin enthaltene Medienströme. Es beschreibt somit Attribute der Sitzung (z.B. Typ oder Name), des Medienstroms (Medien- und Transportformate) und bietet Informationen zur späteren Kontrolle der Wiedergabe. Listing 2 zeigt den Inhalt und die Struktur eines MS-SDF anhand eines Beispiels.

23456564 CompPres_2007_10_29 A scene from the last company presentation On October 29th 2007 filmed by Adam. 4535236 file 00000050-0000-0010-8000-00aa00389b71 audio/mpeg E436EB81-524F-11CE-9F53-0020AF0BA770 video/mpeg MTP 1.0 100 1000 forced 1000 Listing 2: Beispiel einer MS-SDF Beschreibung

Im Listing zeigen sich die drei obligatorischen Hauptelemente einer MS-SDF Beschreibung. Diese sollen nachfolgend noch genauer beschrieben werden. Im Falle einer laufenden Sitzung kann sich noch eine Beschreibung des globalen Zustandes anschließen. Hierzu werden in

60 4. Entwurf

Abschnitt 4.3.2 zwei Formate vorgeschlagen und ihre Kombination mit dem MS-SDF diskutiert.

4.3.1.1 Element

Das Element enthält XML-Elemente zur allgemeinen Beschreibung der Streaming Session. Neben und ist das Element in jedem Element erforderlich. enthält einen String, der den Typ der Session genauer beschreibt. Folgende Werte werden hier definiert:

• file: Das zu übertragende Medium liegt als Datei vor. • live: In der Session wird eine Live-Quelle angeboten (z.B. Webcam).

4.3.1.2 Element

Das Element enthält für den Transport und Verarbeitung des Datenstroms essenzielle Informationen. bietet eine Liste von Medienformaten, die mit dem Medienstrom assoziiert werden. Das Format wird dabei über einen Globally Unique Identifier (GUID) eindeutig bestimmt, während der MIME-Type als erste Orientierung bei der Verarbeitung dienen kann (bspw. Audio oder Video). Die vom Sender der Session-Beschreibung unterstützten Transportformate werden im Element aufgeführt und über einen Namen sowie die Versionsnummer identifiziert.

4.3.1.3 Element

Auch ein Beispiel des Elementes wird in Listing 2 dargestellt. Hier werden Angaben hinterlegt, die für die spätere Wiedergabe sowie Synchronisierung von Bedeutung sind. legt die Start- und Endposition der Wiedergabe des Medienstroms fest. Diese Angaben entfallen, wenn es sich bei dem Medium um eine Live-Quelle handelt. Das Element ist außerdem optional: fehlt es, wird das Medium vom Beginn bis zum Ende wiedergegeben. bestimmt den maximalen Zeitraum, der zwischen zwei Synchronisierungsnachrichten des MS-Server liegen darf. Das Element beschreibt schließlich den Typ der geforderten Synchronisierung. Im MS-SDF werden folgende Synchronisierungsarten definiert:

• none: Wahlfreier Zugriff auf den Stream (keine Synchronisation der Wiedergabe). • forced: Zeigt die gezwungene Synchronisation der Wiedergabe an. • free: Zu Beginn der Sitzung wird eine Synchronisation gewünscht, kann aber im Laufe der Sitzung verlassen werden.

Handelt es sich bei dem Inhalt der Kind-Elemente von um Zeitangaben, kann jeweils über ein unit Attribut die Einheit bestimmt werden. Fehlt dieses optionale Attribut, wird die Einheit Millisekunden vorausgesetzt. Somit wurden alle obligatorischen Elemente des MS-SDF vorgestellt. Auf die formale Definition des Formats sei an dieser Stelle verzichtet. Sie können wie die nachfolgenden Definitionen in [BAU07] nachgelesen werden.

61 4. Entwurf

4.3.2 Weitere Beschreibungsformate

Das vorgestellt MS-SDF wird für die Beschreibung von Session-Attributen eingesetzt. Es werden noch weitere Formate benötigt, die Eigenschaften und Präferenzen eines Teilnehmers repräsentieren. Im Laufe des Entwurfes wurde entschieden, für diese Definitionen Elemente des umfangreichen MS-SDF wieder zu verwenden.

4.3.2.1 Multimedia Streaming - Capability Description Format (MS-CDF)

Das MS-CDF dient zur Beschreibung von Fertigkeiten eines Clients. Es kann als Teilmenge des MS-SDF angesehen werden: die in Listing 2 vorgestellten Inhalte des Elements werden wieder verwendet, um die unterstützten Medien- und Transportformate des Clients zu beschreiben.

00000050-0000-0010-8000-00aa00389b71 audio/mpeg E436EB81-524F-11CE-9F53-0020AF0BA770 video/mpeg MTP 1.0 Listing 3: Beispiel einer MS-CDF Beschreibung

4.3.2.2 Multimedia Streaming - Preference Description Format (MS-PDF)

Das MS-PDF wird verwendet, um die Präferenzen eines Teilnehmers einer Streaming-Session zu spezifizieren. Ähnlich wie das MS-CDF verwendet es bereits definierte XML-Elemente aus dem MS-SDF: und . Ersteres zeigt im Falle des MS-PDF an, welche Formate der Client für den Transport oder die spätere Wiedergabe bevorzugt. Durch die Elemente innerhalb von kann der Client Einfluss auf die spätere Form der Wiedergabe nehmen. Beispielsweise kann eine veränderte Startposition der Wiedergabe oder die Veränderung des Typs der Synchronisierung angefordert werden. Letzteres kann auftreten, wenn der Client anstelle einer gezwungenen synchronisierten Wiedergabe wahlfrei auf Inhalte von Providern zugreifen möchte.

62 4. Entwurf

00000050-0000-0010-8000-00aa00389b71 audio/mpeg 1000 free Listing 4: Beispiel einer MS-PDF Beschreibung

4.3.2.3 Multimedia Streaming – Local State Description Format (MS-LSF)

Die Beschreibung des Zustandes einer Streaming-Session ist für deren Synchronisierung von großer Bedeutung. Bei dem Entwurf stellte sich die Frage, welche Attribute den Zustand einer Streaming-Sitzung eindeutig beschreiben. Neben dem aktuellen Zustand der Wiedergabe bei einem Teilnehmer kann eventuell auch der Pufferfüllstand von Bedeutung sein. Daher werden drei generische Attribute zur eindeutigen Beschreibung eines Session-Zustands herausgestellt:

• Metainformationen des Zustandes (Zeitstempel, Zugehörigkeit, … ) • Der Zustand des Bufferings • Der Zustand der Wiedergabe

Das nachfolgende Beispiel zeigt exemplarisch die Beschreibung eines lokalen Zustands der Sitzung mit der ID 23243. Der Zustand ist dabei als Referenzzustand gekennzeichnet (isRef="true"), stammt also vom Presenter der Sitzung.

… play 600 receiving 1200 Listing 5: Beispiel einer MS-LSF Beschreibung

63 4. Entwurf

4.3.2.4 Multimedia Streaming – Global State Description Format (MS-GSF)

Teilnehmer mit der Rolle des Presenters können mitunter an einer Beschreibung des aktuellen Zustandes einer Sitzung interessiert sein. Hierzu muss ein Beschreibungsformat definiert werden, dass alle Informationen über lokale Zustände verbundener Teilnehmer bündelt. Das nachfolgende Beispiel zeigt eine solche Liste von lokalen Zuständen und verdeutlicht dabei die Wiederverwendung des MS-LSF Beschreibungsformates.

… … Listing 6: Beispiel einer MS-GSF Beschreibung

Informationen über den aktuellen Zustand einer Streaming-Sitzung können in mehreren Fällen hilfreich sein: so kann ein Teilnehmer mit der Rolle des Presenters durchaus daran interessiert sein, in welchem Zustand sich die kollaborative Wiedergabe eines Medienstroms bei verbundenen Teilnehmern der Sitzung befindet. Auch bei einem Late-Join Szenario können diese Informationen einbezogen werden: dem verspätet beigetretenem Teilnehmer können so Informationen zum Referenzzustand zugänglich gemacht werden. Das im Beispiel dargestellte XML-Element kann dafür in das MS-SDF eingebracht werden. Benötigt der Presenter einer Sitzung während deren Verlauf Informationen zum Zustand der Sitzung, kann er eine aktuelle Sitzungsbeschreibung abfragen und gelangt so zu entsprechenden Informationen. Bei einem Late-Join-Szenario sind keine zusätzlichen Abfragen notwendig: die hier übermittelte Sitzungsbeschreibung enthält bereits Informationen zum Referenzzustand.

4.4 Integration von Multimedia Streaming in das CSP

Nach den bisherigen, eher allgemeinen Betrachtungen zu Entwurfsentscheidungen, Rollenmodell und benötigten Beschreibungsformaten soll nun die konkrete Integration des Multimedia-Streamings in das CSP diskutiert werden. Zunächst wurde hierzu im Entwurf die Entscheidung getroffen, die benötigten Kernfunktionen eines Multimedia-Streamings zu separieren und durch Teilprotokolle in das CSP zu integrieren. Dadurch wird der bisher im CSP umgesetzte Mikroprotokollansatz übernommen und eine nahtlose Integration ermöglicht. Abbildung 17 gibt hierzu zunächst eine Übersicht über die bereits vorhandenen Teilprotokolle des CSP. Die für eine Integration von Multimedia-Streaming benötigten Teilfunktionen und deren Realisierung im Entwurf werden nachfolgend erläutert.

64 4. Entwurf

Content Sharing Protocol

Interaktion Event Tracking Presenter Control Protocol (CS-ETP) Protocol (CS-PCP) Telepointer Interaction Protocol (CS-TIP) Content Distribution Protocol (CS-CDP)

Drawing Interaction Protocol (CS-DIP) Binary Transmission Protocol (CS-BTP)

Session Management Protocol (CS-SMP)

Abbildung 17: Content Sharing Protokoll (aus [SCH07b])

Offerieren von Medienströmen Das CSP bietet mit dem Content Offering Protocol (CS-COP, definiert in [SCH07c]) bereits Funktionen zum Offering von statischen Inhalten innerhalb einer Content-Sharing Session an. Dabei werden Inhalte durch einen an HTTP angelehnten Uniform Resource Identifier (URI) eindeutig beschrieben und lokalisiert. Dieses Vorgehen wird für das Multimedia-Streaming übernommen. Einzig das URI-Schema wird abgeändert, um auf die Notwendigkeit der Behandlung der Streaming-Ressource mit neuen Methoden hinzuweisen.

Verwaltung von Nutzern und Rollen Zur Rollenverwaltung wird innerhalb des CSP-Rahmens das Presenter Control Protocol (CS- PCP, definiert in [SCH07d]) verwendet. Hier wird die Rolle des „Current Presenter“ definiert und deren Aushandlung beschrieben. Diese Rolle gleicht der des bisher beschriebenen Presenters einer Multimedia Streaming Session: Teilnehmer, die Presenter einer Data-Sharing Session sind, steuern das gemeinsame Betrachten von bisher unterstützten Inhalten innerhalb der Gruppe. Das CS-PCP kann auch für die benötigte Aushandlung und Zuweisung eines präsentierenden Teilnehmers in einer Multimedia-Streaming Session benutzt werden.

Setup einer Streaming Session Nach dem Offerieren des Medienstroms müssen die für ein Streaming zusätzlich notwendigen Informationen ausgetauscht und die Session ausgehandelt werden. Die Funktionen des CSP bieten dabei bisher keine Möglichkeit eine Session nach Vorgaben eines MS-Clients anzupassen. Daher wird eine eigene Lösung in Form eines neuen Teilprotokolls vorgeschlagen: das neu definierte Multimedia Streaming Protocol (MSP) beschreibt Nachrichten und Abläufe, die für den Setup einer Multimedia-Streaming Session notwendig sind. Das MSP wird in Abschnitt 4.5 genauer diskutiert.

65 4. Entwurf

Transfer und Buffering von Inhalten Bisher wird der Transfer von Inhalten im CSP über das Binary Transmission Protocol (CS-BTP, definiert in [SCH07c]) gehandhabt. Es ermöglicht die fragmentierte Übertragung größerer Binärdateien innerhalb einer Data-Sharing Session. Zur Realisierung der Übertragung von Medienströmen wird im Entwurf ein leichtgewichtiges Transportprotokoll, das Multimedia Streaming Transport Protocol (MTP), vorgeschlagen. Das MTP wird wie das MSP anhand seiner Nachrichten und Abläufe in Abschnitt 4.5 beschrieben.

Kontrolle der Session Die Kontrolle des Zustandes einer Content-Sharing Sitzung wird im CSP durch das Event Tracking Protocol realisiert (CS-ETP, definiert in [SCH07d]). Durch die Übermittlung von Events an Teilnehmer einer Session wird die zentrale Steuerung auch entfernter Zustände ermöglicht. Während des Entwurfes wurde zunächst die Möglichkeit geprüft, auch Events zur Steuerung des gemeinsamen Streamings multimedialer Daten durch das CS-ETP zu verteilen. Diese Lösung wurde aber im Laufe der Arbeit verworfen, da der Umfang der Steuernachrichten und deren Inhalt nicht mit der klaren und einfachen Struktur eines CS-Events vereinbar ist. Für eine klare Abgrenzung zur bisherigen Funktionalität wurde mit dem Multimedia Streaming Control Protocol (MCP) ein eigenständiges Protokoll für die Kontrolle einer Multimedia- Streaming Sitzung definiert. Die Abläufe des MCP werden in Abschnitt 4.5 erläutert. Abbildung 18 zeigt abschließend alle neu definierten Bestandteile (unter dem Begriff Multimedia-Streaming zusammengefasst) im Kontext der vorhandenen Elemente des CSP.

(CS-SWP) Content Offering Shared Workspace Protocol Protocol (CS-COP)

Abbildung 18: CSP inklusive Multimedia-Streaming

66 4. Entwurf

4.5 Protokollentwurf

Der Entwurf der in Abschnitt 4.4 skizzierten Protokolle für die Integration von Funktionen eines Multimedia Streamings in das CSP soll in diesem Abschnitt detailliert beschrieben und vertieft werden. Es wurden, wie bereits im Abschnitt 4.4 erwähnt, drei Teilprotokolle spezifiziert, die folgende Kernfunktionen realisieren:

• Aushandlung und Aufbau der Sitzung durch das Multimedia Streaming Protocol (MSP) • Definition eines geeigneten Transportformats, Datentransport und Monitoring der Übertragung durch das Multimedia Streaming Transport Protocol (MTP) • Kontrolle des Zustandes der Streaming Sitzung durch das Multimedia Streaming Control Protocol (MCP)

Kontrolle

MCP MCP MSP MSP MTP MTP MS-Client MS-Client Presenter MS-Server Viewer

T ra rt n o sp sp o n rt a Tr

MS-Client Provider

Abbildung 19: Teilprotokolle für Multimedia Streaming

Die entworfenen Teilprotokolle sind im Kontext der definierten Komponenten und Rollen eines kollaborativen Multimedia-Streamings in Abbildung 19 dargestellt. Gezeigt wird der mögliche direkte Nachrichtenaustausch zwischen MS-Clients und MS-Server sowie die dadurch ermöglichte indirekte Kommunikation zwischen MS-Clients. Die Ordnung der Protokolle in der Darstellung ist nicht willkürlich gewählt: obwohl alle Teilprotokolle der Anwendungsschicht des ISO/OSI Schichtenmodells zugeordnet werden können, wird mit dem MCP eine höhere

67 4. Entwurf

Abstraktionsebene erreicht. Das MCP stößt dabei den Nachrichtenaustausch des MSP beziehungsweise des MTP an.

4.5.1 Nachrichten für kollaboratives Multimedia-Streaming

Die Grundlage einer Kommunikation bilden Nachrichten. Dieser Abschnitt soll daher zunächst die Nachrichten der entworfenen Protokolle vorstellen. Tabelle 10 zeigt eine Übersicht der im Entwurf definierten Nachrichten für die Aushandlung von Attributen einer Sitzung und den Transport von Medienströmen innerhalb eines kollaborativen Streamings. Anhand der dargestellten Funktionen von Requests und Responses wird so ein Überblick über die entworfene Funktionalität der Teilprotokolle MSP und MTP geboten. Mögliche Nachrichten zur Kontrolle einer Streaming Sitzung (MCP) sollen gesondert in Abschnitt 4.5.3 vorgestellt werden, um auch die Diskussion von Alternativen während der Bearbeitung aufzuzeigen.

FUNKTION TEILPROTOKOLL NACHRICHT REQUEST RESPONSE CAPABILITY Senden von Client- Eigenschaften (MS- - CDF) DESCRIBE Anforderung der Senden der Session- Session-Beschreibung Beschreibung (MS-SDF) SETUP Senden von Client- ggf. Senden einer MSP Präferenzen (MS-PDF) aktualisierten Session Beschreibung (MS-SDF) TEARDOWN Abbau der Streaming- - Session GET Anforderung der Statusmitteilung Datenübertragung DATA Übertragung eines - Datenpakets MTP REPORT Senden eines Receiver- - Reports Tabelle 10: Übersicht Nachrichten für kollaboratives Multimedia-Streaming

Die Struktur der definierten Nachrichten für ein Streaming multimedialer Inhalte soll nachfolgend anhand von DESCRIBE Request und Response erläutert werden. Durch die Beispiele wird auch die Anlehnung an HTTP deutlich: Nachrichten bestehen aus Header und Body. Der Header enthält mindestens eine Bezeichnung der Nachricht im Falle eines Requests bzw. eine Statusbeschreibung, falls es sich um eine Response handelt.

DESCRIBE cs-msp://3453243/stream1/ Accept: text/ms-sdf CSeq: 1 Listing 7: Beispiel einer MSP DESCRIBE Request

Listing 7 zeigt den Aufbau und Inhalt einer DESCRIBE Request. Vom Sender wird durch diese Nachricht eine Beschreibung der zuvor offerierten Session angefordert. Diese wird durch die

68 4. Entwurf dargestellte URI (cs-msp://3453243/stream1/) referenziert. Zusätzlich gibt das Accept Attribut an, welche Beschreibungsformate für die Antwort akzeptiert werden können.

200 OK Content-Type: text/ms-sdf CSeq: 2

23456564 CompPres_2007_10_29 A scene from the last company presentation On October 29th 2007 filmed by Adam. 4535236 file 00000050-0000-0010-8000-00aa00389b71 audio/mpeg E436EB81-524F-11CE-9F53-0020AF0BA770 video/mpeg MTP 1.0 100 1000 forced 1000 Listing 8: Beispiel einer MSP DESCRIBE Response

Listing 8 zeigt eine DESCRIBE Response, die innerhalb des MSP verwendet wird, um Beschreibungen in Form des MS-SDF zu übertragen. In der gezeigten Response wird über das Attribut Content-Type zusätzlich auf den Inhalt des Nachrichtrumpfes hingewiesen. Im Body der dargestellten DECRIBE Response wird das in Abschnitt 4.3.1 vorgestellte Beispiel einer Sitzungsbeschreibung im MS-SDF angehangen.

69 4. Entwurf

Nachdem die definierten Protokolle anhand Ihrer Nachrichten einführend betrachtet wurden, sollen im folgendem Abschnitt die Protokollabläufe verdeutlicht werden. Die Beschreibung komplexer Abläufe soll zeigen, wie die Teilprotokolle interagieren und welchen Zweck die in Abschnitt 4.5.1 vorgestellten Nachrichten erfüllen. Zunächst soll hierzu die Aushandlung einer Streaming Sitzung zwischen MS-Server und Provider, der Start der Übertragung des Datenstroms zwischen diesen Teilnehmern sowie die weitere Vermittlung zu Viewern durch den MSS gezeigt werden. Voraussetzung für die dargestellten Abläufe ist eine bereits aufgebaute CSP Session. Dadurch werden folgende Rahmenbedingungen geboten, die bisher noch nicht näher genannt wurden:

• Es existieren für jeden Teilnehmer Kanäle, die für die Kommunikation mit dem MS- Server genutzt werden können. • Die Übertragung über diese Kanäle geschieht immer gesichert. Dass heißt, gesendete Datenpakete kommen in jedem Falle beim designierten Empfänger an. • Die Teilnehmer sind bereits in der Session angemeldet und es werden eindeutige User- IDs zu deren Identifikation vergeben.

4.5.2 Session-Setup und Buffering

Abbildung 20 zeigt die Aushandlung und den Aufbau einer Streaming-Session zwischen Teilnehmern und die sich anschließende Übertragung der Datenpakete. Vor dem eigentlichen Initiieren der Session können Eigenschaften der MS-Clients durch die CAPABILITY Message an den MS-Server übertragen werden [1]. Der MS-Server kann auf Basis der hierdurch gesammelten Informationen im späteren Verlauf Entscheidungen zur Weiterverteilung der Medienströme an Viewer treffen. Die Initialisierung der Session erfolgt über ein CSP OFFER vom Provider des Medienstroms und der anschließenden Übermittlung eines DESCRIBE Requests vom designierten Empfänger, dem MS-Server [2]. Der Provider antwortet innerhalb der Response mit einem Statuscode (200 OK) und einer Beschreibung der Sitzung im MS-SDF (vgl. Abschnitt 4.3.1). Der Empfänger einer DESCRIBE Response kann nun prüfen, ob der beschriebene Medienstrom der Session abgefragt werden sollen. Im Body der SETUP Request bietet sich ihm durch das MS-PDF die Möglichkeit, Informationen zu bevorzugten Transport- oder Medienformate innerhalb der Session anzugeben [3]. Kann der Provider diese Präferenzen berücksichtigen, sendet er innerhalb der SETUP Response neben dem obligatorischen Status (200 OK) eine aktualisierte Session-Beschreibung. An dieser Stelle gilt die Session als ausgehandelt. Der MS-Server kann mit einer GET Request den Start der Datenübertragung anfordern [3]. Nach dem Empfang einer GET Request initiiert der Provider die Übertragung der Datenströme, die innerhalb des MSP ausgehandelt wurden [4]. Hat der MS-Server genügend Datenpakete empfangen (hier dargestellt durch das i-te Paket), kann er den Medienstrom schließlich anderen Teilnehmern der Session durch OFFER Messages anbieten [5]. Das Buffering von Provider zu MS-Server bleibt davon unberührt und läuft parallel zu den nachfolgenden Aufrufen weiter [6]. Der bisher vorgestellte Ablauf wiederholt sich nun zwischen MS-Server und Viewer [7]. Im dargestellten Szenario wird zusätzlich der Abbruch der Initialisierung durch einen Viewer gezeigt. Es ist durchaus denkbar, dass ein MS- Client die Anforderungen für einen Empfang der Session nicht erfüllen kann oder will. Der entsprechende Client beendet im Beispiel den Verlauf der Aushandlung, indem er kein SETUP Request an den MS-Server sendet [8]. Kann die Session jedoch erfolgreich ausgehandelt werden, wird vom Viewer eine GET Request übermittelt und die Übertragung der Datenpakete zwischen MS-Server und Viewer setzt ein [9]. Die Güte der Datenübertragung kann vom

70 4. Entwurf

Sender durch Informationen empfangener Receiver-Reports ermittelt werden. Solche Reports werden durch die REPORT Message innerhalb des MTP realisiert und in regelmäßigen Abständen an den Sender eines Datenstroms (in diesem Fall der MS-Server) übermittelt [10]. In der Abbildung wurde auf die Darstellung der Receiver-Reports vom MS-Server verzichtet. Diese sind analog zu den dargstellten Reports der Viewer notwendig, um den Provider der Sitzung über die Güte der Übertragung zum MS-Server zu informieren.

Provider MSS Viewer Viewer

[1] CAPABILITY(MS-SDF) CAPABILITY(MS-SDF) OFFER(ms-cdp://.../stream)

DESCRIBE(ms-cdp://.../ [2] stream) 200 OK (MS-SDF)

SETUP(MS-PDF) [3] 200 OK (MS-SDF) GET [4] DATA (0 ms) DATA (40 ms) ... DATA (i ms) OFFER(ms-cdp:\\\stream\) [5] OFFER(ms-cdp:\\\stream\) [7] [6] DATA (i+40 ms) ... DESCRIBE DESCRIBE 200 OK (MS-SDF) 200 OK (MS-SDF) [8] SETUP(MS-PDF) 200 OK (MS-SDF) GET [9] DATA (0 ms) DATA (40 ms) ... DATA (j ms) REPORT [10] DATA (j+1 ms) ...

Nachrichtenströme CSP MSP MTP

Abbildung 20: Setup und Buffering innerhalb einer Multimedia-Streaming Session

71 4. Entwurf

4.5.3 Kontrolle der Streaming Sitzung

Für die Implementierung eines kollaborativen Streamings ist die Kontrolle von Zuständen und deren Transfer essentiell (vgl. hierzu 2.3.2). Ein Grundgedanke soll an dieser Stelle wiederholt werden: ein innerhalb einer Gruppe von Teilnehmern synchronisiertes Streaming wird durch den Abgleich von lokalen Zuständen mit einem Referenzzustand möglich. Als solcher Referenzzustand wird im Entwurf der lokale Zustand des Presenters festegelegt. Für einen Entwurf ist zunächst zu entscheiden, wie die Information zu den Zuständen der Sitzung zusammengetragen werden können.

4.5.3.1 Repräsentation von Zuständen einer Streaming Sitzung

Die zur Repräsentation eines Zustandes einer Streaming Sitzung vorgeschlagenen Beschreibungsformate wurden bereits in Abschnitt 4.3 in Form von Beispielen vorgestellt. Hier wurde definiert, welche Informationen notwendig sind, um den Zustand einer Streaming- Sitzung adäquat zu repräsentieren. Im weiteren Entwurf stellte sich nun die Frage, wie diese benötigten Informationen zusammengetragen werden können. Durch das Routing der Datenströme über den MS-Server werden diesem Informationen zum Zustand des Bufferings aller verbundenen Clients zugänglich gemacht. In einem ersten Entwurf eines Kontrollprotokolls wurde versucht, die Zugänglichkeit dieser Informationen zu nutzen und auf entsprechende Zustandsmeldungen zwischen MS-Clients und MS-Server zu verzichten. Der Aspekt der Skalierbarkeit des zu entwerfenden Systems sowie der zu erwartende Aufwand der Verarbeitung führte im weiteren Verlauf der Arbeit jedoch zu dem Entschluss, den Datenfluss am MS-Server nicht für eine zentrale Verwaltung der Zustände verbundener MS- Clients zu nutzen. Wie gezeigt wurde, müssen für eine vollständige Beschreibung des lokalen Zustandes einer Sitzung auch Informationen zur Wiedergabe des Medienstroms gesammelt werden. Diese Beschreibungen können leicht um den Zustand des Bufferings ergänzt werden, wodurch auch das Argument zur Einsparung eines Nachrichtenaustausches entkräftet werden kann.

4.5.3.2 Initiierung der Synchronisierung

Die Thematik der Synchronisierung einer kollaborativen Streaming-Session sollte bis zuletzt einen Schwerpunkt des Entwurfes bilden. Verschiedene Ansätze und Lösungen wurden dabei während der Bearbeitung der Problemstellung diskutiert:

• Servergesteuerte Synchronisierung: der vorgestellte MS-Server initiiert die Synchronisierung verbundener Teilnehmer mit einem Referenzzustand. • Clientgesteuerte Synchronisierung: der MS-Client initiiert die Synchronisierung nach Abgleich mit dem Referenzzustand der Streaming-Sitzung.

Um einen Einblick in die Problemlösung zu bieten, sollen die beiden herausgearbeiteten Ansätze nachfolgend vorgestellt und ihre Eignung für eine Integration in eine verteilte Groupware diskutiert werden.

72 4. Entwurf

Servergesteuerte Synchronisierung Kerngedanke der servergesteuerten Synchronisierung ist, dass der Server den Teilnehmern nicht nur den aktuellen Session-Zustand mitteilt. Er gibt dem entsprechenden Client vor, wie er sich mit dem angestrebten Zustand zu synchronisieren hat. Hierfür ist folgender Nachrichtenaustausch notwendig:

• MS-Client Æ MS-Server: regelmäßige Informationen zum Zustand der lokalen Wiedergabe des Clients • MS-Server Æ MS-Client: Steuernachrichten zur Synchronisierung der lokalen Sitzung mit einem Referenzzustand – der Client kennt diesen also nicht direkt

Der Client kennt den Referenzzustand der Sitzung also nicht direkt. Nur der Server verwaltet diesen und steuert auf Basis dieses Zustandes (und den gesammelten lokalen Zuständen der Clients) die Synchronisierung von verbundenen Clients. Es kann also von einer expliziten Steuerung durch den MS-Server gesprochen werden. MS-Clients müssen nach Vorgaben des Servers handeln und bspw. MSP-Nachrichten, um sich mit dem Referenzzustand der Sitzung zu synchronisieren.

Clientgesteuerte Synchronisierung Die clientgesteuerte Synchronisierung unterscheidet sich von der servergesteuerten Variante in einem zentralen Punkt: der Server verzichtet auf den Einsatz einer expliziten Steuerung in Form von Kontrollnachrichten. Stattdessen übermittelt er in regelmäßigen Abständen Informationen über den Referenzzustand an die MS-Clients. Diese entscheiden dann eigenverantwortlich, wie mit diesen Informationen umzugehen ist. Im Falle einer zu großen Abweichung des lokalen Zustands vom Referenzzustand können sie eine Synchronisierung einleiten. Bei dieser Variante kann also von einer impliziten Steuerung der Synchronisierung durch den MS-Server gesprochen werden. Für den Teilbereich der Synchronisierung ist also nur folgender Nachrichtenaustausch zu realisieren:

• MS-Server Æ MS-Client: regelmäßige Informationen über den Referenzzustand der Sitzung

Für den abschließenden Entwurf der Kontrolle einer Streaming Session wurde schließlich der clientgesteuerte Ansatz gewählt. Die Skalierbarkeit der servergesteuerten Variante muss in Frage gestellt werden: ein zu hoher Verwaltungsaufwand bei steigender Anzahl der verbundenen Viewer wird angenommen. Der Aufwand für die Implementierung ist ebenfalls komplexer einzuschätzen als bei der clientgesteuerten Synchronisierung.

4.5.3.3 Arten der Synchronisierung bei einer Navigation des Presenters

Zusätzlich zur Art der Initiierung einer Synchronisierung von Zuständen kann noch unterschieden werden, in welcher Form diese stattfinden kann. Anhand von Beispielabläufen sollen die beiden im Entwurf diskutierten Alternativen erläutert werden.

73 4. Entwurf

Ablauf Synchronisierung Variante 1 1. Der Presenter übermittelt den Navigationswunsch an den MS-Server. 2. Der MS-Server leitet den Navigationswunsch an die Viewer weiter und wartet auf Rückmeldungen von diesen (kann die Navigation ausgeführt werden oder nicht?). 3. Erst wenn der letzte Viewer die Vorbereitung der Navigation erfolgreich beendet hat (oder ein Timeout erreicht wurde), wird vom MS-Server eine positive Antwort auf den Navigationswunsch des Presenters gesendet. 4. Der Presenter führt die Navigation lokal aus und teilt dies dem MS-Server mit (Änderung des Referenzzustandes). 5. Der MS-Server leitet den aktuellen Referenzzustand an die Viewer weiter. 6. Die Viewer starten lokal die Navigation.

Ablauf Synchronisierung Variante 2 1. Der Presenter navigiert lokal und informiert den MS-Server über seinen veränderten lokalen Zustand. 2. Der MS-Server verteilt den neuen Referenzzustand. 3. Die Viewer reagieren auf den veränderten Referenzzustand und initiieren eine Synchronisierung (vgl. 4.5.3.2)

Für den Entwurf eines Kontrollprotokolls wurde die zweite Variante gewählt. Die alternativ vorgestellte Variante kann zu Verklemmungen führen und orientiert sich immer am schwächsten Glied einer Gruppe: kann ein Teilnehmer beispielsweise aufgrund einer schwach ausgeprägten Netzanbindung der Navigation nicht folgen, muss der Presenter bis zu einem Timeout warten, bevor er die Navigation selbst starten kann. Es ist zusätzlich davon auszugehen, dass die „schwache“ Variante besser skaliert und in der Implementierung leichter abzubilden ist. Negativ anzumerken ist hier jedoch die geringere Güte der Synchronität innerhalb der Gruppe. Erhöht werden kann diese durch eine feinere Beschreibung des Referenzzustandes: so kann der Presenter bereits einen geplante Veränderung der Wiedergabeposition (und damit eine Änderung des Zustandes des Bufferings) mitteilen, um Viewern die Möglichkeit zu bieten, sich frühzeitig auf die zukünftige Wiedergabeposition einzustellen (und ebenfalls ein entsprechendes Buffering einzuleiten).

74 4. Entwurf

4.5.3.4 Nachrichten zur Kontrolle einer Streaming Session

ANSATZ NACHRICHT RICHTUNG DER FUNKTION KOMMUNIKATION REQUEST RESPONSE PREPARE Presenter Æ MS-Server Vorbereitung einer Status der Navigation Vorbereitung CONTROL Presenter Æ MS-Server Entfernte Steuerung Status der MS-Server Æ MS-Clients der Wiedergabe Wiedergabe TICK MS-ClientsÆ MS-Server Informationen über -

Synchronisierung den lokalen Zustand Servergesteruerte, Servergesteruerte, des Senders STATE MS-Clients Æ MS-Server Informationen über - den lokalen Zustand des Senders TICK MS-Server Æ MS-Clients Informationen über - den Referenzzustand der Sitzung Synchronisierung Clientgesteruerte, Clientgesteruerte,

Tabelle 11: Mögliche Nachrichten zur Kontrolle eines kollaborativen Streamings

In Tabelle 11 werden abschließend mögliche Nachrichten zur Kontrolle einer kollaborativen Streaming-Session aufgeführt. In jedem Fall muss noch die Möglichkeit geboten werden, Informationen zum aktuellen Zustand aller Teilnehmer einer Sitzung abzufragen. In Abschnitt 4.3.2.4 wurde bereits Format für die Beschreibung des globalen Zustandes einer Sitzung vorgeschlagen. Diese Informationen werden können durch die erneute Anfrage einer Session- Beschreibung (DESCRIBE-Request, vgl. Abschnitt 4.5.1 und 4.5.2) abgefragt werden.

4.5.3.5 Synchronisation nach Navigation des Presenters - Szenario 1

Zur Verdeutlichung der bisher vorgestellten Alternativen zur Synchronisierung eines kollaborativen Streamings wird nachfolgend ein Szenario in Form von Sequenzen vorgestellt. Dabei wird zur Vereinfachung und Wahrung der Übersicht vom besten Fall ausgegangen. Alle Teilnehmer sind in der Lage, dem Navigationswunsch ohne eine neue Anforderung von Daten nachzukommen. In Abschnitt 4.5.3.6 wird im Kontrast dazu ein Szenario für den gewählten Ansatz gezeigt, der als Worst-Case einzustufen ist: jeder Teilnehmer der Sitzung und der MS- Server muss die Daten zunächst anfordern, um die Navigation auszuführen.

75 4. Entwurf

play (600ms) play (600ms)

Abbildung 21: Synchronisation nach Navigation durch den Presenter: Best-Case

Abbildung 21 zeigt den Ablauf einer Synchronisation nach der Navigation eines Presenters mit dem clientgesteuerten Ansatz. Die Navigation im Medienstrom wird dabei mit dem lokalem Event play beschrieben: in der Oberfläche könnte beispielsweise die Wiedergabeposition von 100 auf 600ms springen. Der Presenter führt zunächst die Navigation durch, um dann die Veränderung an den MS-Server zu übermitteln (STATE). Dieser aktualisiert den verwalteten Referenzzustand und sendet Informationen hierüber an die verbundenen Viewer (TICK). Diese führen schließlich die Navigation lokal aus und geben die gewünschte Position wieder. Der in diesem Abschnitt bereits beschriebene Ansatz der servergesteuerten und starken Synchronisierung soll an dieser Stelle nochmals in Form eines Beispielsablaufs gezeigt werden. Wie schon in Abbildung 21 wird in diesem Szenario ebenfalls der beste Fall angenommen: alle Teilnehmer können die angeforderte Stelle ohne weiteres wiedergeben.

76 4. Entwurf

Presenter MSS Viewer Viewer

PREPARE (action=play;ptp=600ms;) prepare viewers

PLAY (ptp=600ms) prepare prepare (600ms)

200 ok play (600ms)

PLAY (ptp=600ms)

200 ok (600ms)

viewers ok play 200 ok Play (600ms)

Nachrichtenströme Lokale Aufrufe MCP

Abbildung 22: Alternativer Ablauf: servergesteuerte Synchronisierung

Durch ein PREPARE signalisiert der Presenter seinen Navigationswunsch. Der MS-Server initiiert daraufhin eine entfernte Steuerung der Wiedergaben bei den verbundenen Viewern: mit der Steuernachricht PLAY fordert er die MS-Clients auf, die entsprechende Stelle wiederzugeben. Diese antworten mit einer Statusnachricht. Erst wenn der MS-Server von allen Teilnehmern positive Rückantwort erhalten hat, bestätigt er die initiale PREPARE Anfrage des Presenters. Dieser startet daraufhin die Wiedergabe. Das Szenario verdeutlicht Probleme des Ansatzes: der Presenter wird durch die Wartezeit immer schwächstes Glied einer kollaborativen Wiedergabe sein, und das auch, wenn der Medienstrom lokal vorliegt und er als Provider gilt.

4.5.3.6 Synchronisierung nach Navigation des Presenters - Szenario 2

Nachdem im letzten Abschnitt ein „Best-Case“ Szenario zur Veranschaulichung der notwendigen Nachrichten für eine Synchronisierung eines gemeinsamen Streamings und jeweilige Alternativen beschrieben wurde, soll nun der im Entwurf gewählte Ansatz vertieft werden. Hierzu soll ein „Worst-Case“ Szenario und die Beschreibung dessen Behandlung wie in Abbildung 23 dargestellt dienen.

77 4. Entwurf

seek seek (6000ms) (6000ms) seek seek play (6000ms) (6000ms) play play

Abbildung 23: Synchronisation nach Navigation durch den Presenter, Worst-Case

Die Ausgangslage des in Abbildung 23 dargestellten Szenarios gleicht der von Abbildung 21: der Presenter der Sitzung möchte die Position der Wiedergabe eines Medienstroms ändern (hier nach Wiedergabeposition 6000ms). Er teilt dies dem MS-Server in Form eines Updates seines lokalen Zustands mit (STATE). Dieser aktualisiert den Referenzzustand und teilt dies den

78 4. Entwurf

Viewern mit (TICK). Im Unterschied zu Abbildung 21 können im dargestellten Szenario weder die Teilnehmer noch der MS-Server diesen Navigationswunsch ohne weiteres erfüllen: zunächst muss der Medienstrom vom Provider (vom MS-Server) bzw. dem MS-Server (von MS-Clients) angefordert werden. Sofort nach Erhalt des aktuellen Referenzzustandes beginnt der MS-Server damit, den Medienstrom entsprechend vom Provider anzufordern. Erst nachdem einen gewissen Vorlauf beim Buffering erreicht hat, kann er die mittlerweile eingetroffenen Anforderungen des Datenstroms von Presenter bzw. Viewer beginnen und signalisiert dies mit einem 200 OK. Der Presenter kann in diesem Szenario nach Erhalt des Datenpakets mit der Zeitmarke 6000+j ms schließlich mit der Wiedergabe beginnen: diese Änderungen des lokalen Zustands wird wiederum an den MS-Server übermittelt (STATE). Dieser leitet den neuen Referenzzustand an den Viewer weiter, der aber noch nicht den benötigten Datenvorlauf erreicht hat, um den Medienstrom an der entsprechenden Stelle darzustellen. Erst wenn auch er die Daten für die Wiedergabeposition 6000+j ms erhalten hat, starte er die Wiedergabe lokal.

4.5.3.7 Laufende Synchronisierung

Neben der Synchronisierung nach einer Navigation durch den Presenter einer Streaming- Session kann noch eine laufende Synchronisierung vorgenommen werden. Hierzu übermittelt der MS-Server regelmäßig mit TICK-Nachrichten auch den Sollzustand einer Sitzung an verbundene Teilnehmer. Diese Ticks werden dabei vom MS-Server nach Vorgaben des Presenters oder durch interne Funktionen erstellt. Für letztere Möglichkeit kann die interne Uhr des MS-Server genutzt werden: erreicht ihn beispielsweise eine initiale Statusmeldung des Presenters über den Start der Wiedergabe und in der Folge keine weitere Änderungen dieses Referenzzustandes, kann er davon ausgehen, dass die Wiedergabe ohne Störungen beim Presenter weiterläuft. Folglich kann der MS-Server mit einem internen Zähler auch ohne regelmäßige Statusmeldungen über die Wiedergabeposition beim Presenter „schätzen“, welche Wiedergabeposition derzeit bei der Referenz (dem Presenter) vorliegt. Der Abstand der regelmäßigen TICK Nachrichten kann im MS-SDF für die Sitzung festgelegt werden (vgl. 4.3.1).

4.6 MTP Containerformat

Das MTP Containerformat und dessen Elemente sollen als Transport- und als Speicherformat Anwendung finden. Das hier definierte Format bietet grundsätzlich die Möglichkeit, jegliche Art von zeitkontinuierlichen, multimedialen Daten als Nutzlast (englisch: Payload) abzulegen. Eine Beschränkung auf bestimmte Kodierungen wird nicht vorgenommen. Hierdurch wird für die Implementierung ein gewisser Freiheitsgrad erlangt. Multiple Medienströme innerhalb eines Containers werden ebenfalls erlaubt. So können perspektivisch hierarchischer Codecs oder das Bereitstellen alternativer Medienströme (beispielsweise für verschiedene Sprachversionen) realisiert werden. Bei dem Entwurf wird Wert auf Einfachheit und Effektivität des Formates gelegt: nur für die Übertragung und spätere Wiedergabe essentielle Informationen werden definiert und im Containerformat abgelegt.

79 4. Entwurf

Abbildung 24: MTP Containerformat (Audiostrom)

Abbildung 24 zeigt den strukturellen Aufbau eines MTP-Containers. Der MTP-Header enthält zunächst Informationen zur Identifikation des Formats wie Signatur und Versionsnummer. Auch die Gesamtzahl der im Container abgelegten Datenströme muss bereitgehalten werden. Es können also durchaus mehrere Streams parallel vorkommen. Für die praktische Verwendung des MTP-Containers als Dateiformat müssen noch weitere Metainformationen im Header abgelegt werden. So kann bspw. festgehalten werden, an welcher Stelle der Datei die jeweiligen physischen Daten eines einzelnen Medienstroms beginnen. Die Nutzdaten werden innerhalb von MTP-Blöcken bereitgehalten. In den jeweiligen Block- Headern werden die für die Zuordnung und Identifizierung der Payload Daten notwendigen Informationen abgelegt. Drei Angaben sind hierbei notwendig:

• StreamNr: zeigt an, welchem Stream die nachfolgenden Payload-Daten zugeordnet werden. • Playtime: beschreibt die Wiedergabeposition der im Payload abgelegten Samples. Sind mehrere Samples enthalten, wird die Position des ersten Samples über den Wert von Playtime bestimmt. • IsLongHeader: bestimmt den Typ des Headers.

4.6.1 Adaption durch Block-Header

Auch die Anzeige einer Veränderung eines MTP-Datenstroms wird durch die Block-Header realisiert: wird das Format des assoziierten Stroms verändert, wird dies im entsprechenden Block-Header angezeigt. Hierzu werden zwei Typen von Headern definiert:

• Short-Header: wird verwendet, wenn keine Anpassungen im Vergleich zum vorher empfangenen Block des Medienstroms vorgenommen wurden. • Long-Header: wird bei Änderungen zum vorher übertragenen Block des Stroms verwendet und bietet umfangreichere Informationen als ein Short-Header. Der Typ des Payloads des Streams wird durch die Elemente des Long-Header eindeutig bestimmt.

80 4. Entwurf

Abbildung 24 zeigt exemplarisch die unterschiedlichen Header-Attribute für Audioströme. Auf eine Definition der einzelnen Elemente soll an dieser Stelle verzichtet werden. Sie werden in [BAU07] umfassender beschrieben. Ein Vorteil der Unterscheidung in Long- und Short-Header ist, dass nicht für jedes Datenpaket der Typ der Nutzlast angegeben werden muss. Hierdurch wird der Overhead im Falle eines Einsatzes als Transportformat minimiert.

4.6.2 Serialisierung von MTP-Datenströmen

Bei der Verwendung des MTP-Containerformats als Dateiformat sind noch nähere Beschreibungen der Inhalte notwendig. Informationen, die beispielsweise innerhalb der Long- Header aufgenommen wurden, sollten auch über den MTP-Header abrufbar und somit Applikationen, die MTP-Dateien wiedergeben sollen, sofort zugänglich sein. Für den praktischen Anwendungsfall sind auch weitergehende Metainformationen über die Inhalte denkbar. So könnten umfangreiche Autoreninformationen und Beschreibungen des Inhalts der logischen Medienströme angeboten werden. Letzteres könnte perspektivisch auch das Anbieten und die Auswahl von alternativ im MTP-Container abgelegten Strömen eines Medientyps ermöglichen. Verschiedene Sprachversionen eines Audiostroms oder alternative Qualitätsstufen in einem MTP-Container könnten so ermöglicht werden. In [BAU07] wird dieser Aspekt näher diskutiert.

4.6.3 Echtzeitübertragung

Für die Übertragung von Medien-Datenströmen unter Echtzeitbedingungen müssen Timestamps bereitgestellt werden. Diese Zeitstempel können auf Empfängerseite dazu dienen, eine Berechnung der Latenz und auf dieser Basis Anpassungen der Wiedergabeposition vorzunehmen. Mögliche Verfahren wurden in Abschnitt 2.3.3.2 und im Zuge der Vorstellung von RTP vorgestellt. Das MTP bietet hierzu innerhalb der DATA - Nachricht die Möglichkeit, Timestamps aufzunehmen.

4.7 Zusammenfassung

In den Erläuterungen dieses Kapitels wurden Entscheidungen und Lösungsansätze der Arbeit diskutiert. Es wurde gezeigt, wie die Integration eines Multimedia-Streamings in synchrone Groupware realisiert werden kann. Hierzu wurde ein bestehendes Konferenzsystem um Funktionen und Komponenten eines kollaborativen Streamings erweitert. Im Verlauf des Entwurfes wurden notwendige Neudefinitionen zur Integration dieses Ansatzes vorgenommen, die nachfolgend zusammengefasst werden sollen:

• Drei Teilprotokolle zur Realisierung von Aushandlung (MSP), Transport (MTP) und Steuerung (MCP) einer Multimedia-Streaming Session wurden definiert und in das CSP Protokollsystem integriert.

81 4. Entwurf

• Eine Definition von XML-Formaten zur Beschreibung von Multimedia-Streaming Sitzungen und deren Zustände (MS-SDF, MS-LDF und MS-GDF) sowie Eigenschaften (MS-CDF) und Präferenzen (MS-PDF) von MS-Clients wurde vorgenommen. • Mit dem MTP-Containerformat wurde ein generisches und leichtgewichtiges Format zum Transport und der Serialisierung von Datenströmen mit multimedialen Inhalten vorgeschlagen.

Der Umfang dieser Definitionen macht es schwierig, ein detailliertes Gesamtbild in diesem Kapitel zu bieten. Deshalb wurden die Elemente genauer in einem separaten Dokument beschrieben und spezifiziert (vgl. [BAU07]). Das nachfolgende Kapitel muss nun zeigen, wie die theoretisch beschriebenen Komponenten praktisch umgesetzt werden können und somit den beschriebenen Entwurf validieren.

82 5. Implementierung und Validierung

5. IMPLEMENTIERUNG UND

VALIDIERUNG

Zur Validierung der in Kapitel 4 entworfenen Protokolle wurden Komponenten prototypisch in einen bestehenden Applikationsrahmen implementiert. Im Zuge der praktischen Bearbeitung sollte sich zeigen, ob eine Erweiterung der bisherigen Funktionalität mit den vorgeschlagenen Protokollabläufen und den Beschreibungs- sowie Transportformaten möglich ist. Für die Erstellung eines Prototyps wurde bewusst ein überschaubares Szenario gewählt: ein MPEG- Videostrom sollte in eine bestehende Data-Sharing-Session importiert, verteilt und schließlich kollaborativ wiedergegeben werden. Dabei soll eine Umwandlung in ein einheitliches (und von allen Teilnehmern unterstütztes) Format vorgenommen werden. In diesem Kapitel werden dabei einige zentrale Aufgabenstellungen der Implementierung und deren Lösung beschrieben:

• Import lokaler Medienströme • Setup einer Streaming-Session • Synchronisierung einer Streaming-Session • Transport von Medienströmen

Bevor die Teilaufgaben zur Erstellung des Prototyps genauer erläutert werden, sollen im nächsten Abschnitt mit den technischen Rahmenbedingungen auch die Ausgangslage der Implementierung verdeutlicht werden.

5.1 Technische Rahmenbedingungen

Durch die Integration in das bestehende Konferenzsystem ist bereits der technische Rahmen für die Implementierung gegeben. Als Programmiersprache kommt C++ und somit eine objektorientierte Sprache zum Einsatz. Als Entwicklungsumgebung wurde dabei Microsoft Visual Studio 2005 unter Microsoft Windows XP Professional genutzt. In anderen Modulen der Applikation werden bereits Klassenbibliotheken zur Realisierung von Teilaufgaben verwendet und wurden im Laufe der Implementierung ebenfalls genutzt. Zu nennen sind hier in erster Linie die Microsoft Foundation Classes (MFC) und Codalogics LMX (vgl. [COD07]). Ersteres wird beispielsweise in Kombination mit der Prof-UI-Suite (vgl. [PRO07]) zur Erstellung ergonomischer Benutzeroberflächen verwendet. LMX hingegen

83 5. Implementierung und Validierung ermöglicht eine komfortable Integration von XML-Daten in C++ Applikationen: XML- Beschreibungen können durch entsprechende LMX-Tools in C++ Klassen umgewandelt werden. Instanzen dieser Klassen können nach einer Manipulation innerhalb der Applikation wieder als XML-Daten abgelegt werden. Für die Verarbeitung beliebiger Medienströme wurden Komponenten von Microsoft DirectShow (vgl. Abschnitt 2.5) genutzt. Dabei wurden zu Beginn der Implementierung zunächst andere Alternativen geprüft und Testrahmen für die Verarbeitung lokaler Mediendaten erstellt. Zu nennen sind dabei das Windows Media Encoder SDK sowie das Windows Media Format SDK. Diese SDKs bieten Funktionen, um nahezu beliebige multimediale Eingabeformate komfortabel im ASF-Containerformat abzulegen. Durch entsprechende Encoder- und Decoder-Klassen der Windows Media Encoder SDK kann eine unkomplizierte Verarbeitung von Audio- und Videoformaten vorgenommen werden. Dabei wird beispielsweise die Möglichkeit geboten, Rohdaten mittels WMA- und WMV-Codecs zu kodieren. Die SDKs wurden schließlich aufgrund befürchteter Probleme bei der Auslieferung eines produktiven Gesamtsystems nicht verwendet: man kann nicht davon ausgehen, dass diese SDKs oder WindowsMedia-Codecs auf den Systemen von Endnutzern vorliegen. Eine zusätzliche Installation sollte vermieden werden. Für die prototypische Implementierung wurde daher für eine Kodierung von multimedialen Daten auf bereits integrierte Codecs aus Video- und Audioconferencing Modulen zurückgegriffen. Die notwendige Dekodierung beliebiger Eingabeformate wurde durch DirectShow realisiert. Abschnitt 5.2 soll diesen umfangreichen Aspekt der Entwicklung des Prototyps vertiefen.

Import Export GUI Modules Modules CSApp

Node Controller CS ProtocolProtocol Content AdaptationAdaptation WorkspaceWorkspace Worker Component Objects Service Worker Index Component Object

Conference

Abbildung 25: Struktur der bisherigen Implementierung (aus [SCH07b])

Die Struktur des zugrunde liegenden Data-Conferencing Systems ist in Abbildung 25 dargestellt. Näher erläutert werden einige der dargestellten Komponenten in den nachfolgenden Beschreibungen der Teilaspekte der Implementierung. Einen ausführlichen Einblick in das System bietet [SCH07b]. Zur Erweiterung der Funktionalität um die Verarbeitung von zeitkontinuierlichen Medienströmen wurden Module der Audio- und Videoconferencing Module des Konferenzsystems wieder verwendet (vgl. Abschnitt 5.2).

84 5. Implementierung und Validierung

5.2 Import lokaler Mediendateien

In der bisherigen Data-Sharing Applikation werden statische Inhalte zunächst vom Provider importiert, bevor sie verteilt und gemeinsam betrachtet werden können. Dieses Vorgehen wurde für die Implementierung des Imports von zeitkontinuierlichen Medienströmen übernommen: bevor eine lokale Datei in die Applikation eingebracht werden kann, wird sie vom Provider importiert und dabei in ein einheitliches Format umgewandelt. Als Ziel-Format für diese Umwandlung (Transcoding) während des Imports wird das im Entwurf vorgestellte MTP- Containerformat gewählt. Im Prototyp wird das Transcoding auf Seiten des Providers vollständig vorgenommen. Dadurch ist zeitgleich eine Diskussion zur Nutzbarkeit des MTP- Formats als Dateiformat möglich.

5.2.1 Integration in die Oberfläche

In einer Clientapplikation wird der Import von lokalen Dateien in die Datenkonferenz über ein FileOpen Dialog realisiert. Dieser bietet eine Vorauswahl der unterstützen Formate und ermöglicht es einem Teilnehmer, im lokalen Dateisystem abgelegte Inhalte in die Konferenz einzubringen. Um auch eine Auswahl von multimedialen Datenströmen während des Imports zu ermöglichen, wurden im FileOpen Dialog entsprechende Filter integriert, die die unterstützen Datenformate anzeigen. Nach dem Öffnen einer lokalen Datei erscheint bei den bisherigen statischen Inhalten ein Import-Dialog, der den Nutzer über Inhalte der lokalen Datei und den Fortschritt während des laufenden Imports informiert. Für den Import zeitkontinuierlicher Datenströme wurde analog hierzu ein Import-Dialog implementiert, der den Anwender bspw. über die Fortschritte der Umwandlung (vgl. 5.2.3) informiert. Abbildung 26 zeigt den realisierten Import-Dialog im Kontext einer Clientanwendung. Im Szenario wurde über den erwähnten FileOpen Dialog die lokale Mediendatei „clip1.mpg“ geladen. Ebenfalls in der Abbildung dargestellt ist ein erstes Kontrollelement für die lokale Wiedergabe von Medienströmen: die MediaControl-Toolbar. Diese Toolbar leitet sich von einer bestehenden generischen CCSToolbar Klasse ab. Diese erbt wiederum von CExtToolControlBar, eine Prof-UIs Klasse, die Funktionen einer „dockable“ Toolbar bietet. Perspektivisch ist es notwendig, diese Toolbar um weitere Kontrollelemente zu erweitern, um beispielsweise eine Navigation im Medienstrom zu ermöglichen.

85 5. Implementierung und Validierung

Abbildung 26: Import-Dialog und Media-Control-Toolbar

5.2.2 Importstrategien

Zur praktischen Realisierung des Imports wird in der bisherigen Implementierung das Strategy- Pattern verwendet: verschiedene Importstrategien werden durch Klassen repräsentiert und behandeln den Import statischer Medienformate. Für den Import beliebiger zeitkontinuierlicher Medienströme wurde eine eigene Importstrategie implementiert und beispielhaft erprobt. Einen Überblick über das Konzept der Importstrategien und die Integration der neuen Funktionalität bietet nachfolgendes Klassendiagramm.

86 5. Implementierung und Validierung

«Schnittstelle» MSMediaTranscoder «Schnittstelle» CDcsDialog +Run() CCSImportStrategy +OnSampleIn() +DoImport() +OnSampleEncode() +Completed() +OnSampleOut()

MSMTPTranscoder CMediaImportDlg CCSMediaImport -m_mediaFileDesc aktualisiert benutzt +Run() +SetMediaFileDescription() +DoImport() +OnSampleIn() +OnSampleWritten() +Completed() +OnSampleEncode() +OnSampleWritten() +OnSampleOut()

benutzt

MSMediaImportHelper -m_mediaFileDesc +ParseMediaFileDesc() erstellt +GetMediaFileDesc()

MSMediaFileDesc MSMediaStreamDesc +extension : string -streamNr : long +mimeType : string -length : double +filePath : string -majorType : GUID +nrOfStreams : long 11..*-subType : GUID +streamDesc : MSMediaStreamDesc -isVideo : bool

Abbildung 27: Importstrategie für lokale Medienströme

Abbildung 27 zeigt einige am Import von zeitkontinuierlichen Medienströmen direkt beteiligten Klassen. Auf die umfassende Darstellung der Anwendung und übergeordneter Dialoge wurde aus Gründen der Übersichtlichkeit verzichtet. Für das Verständnis der Funktionalität genügt es festzuhalten, dass die Methode DoImport() der Klasse CCSMediaImport als Einstiegspunkt für den Prozess des Imports von lokalen Medienströmen dient. Diese wird über einen FileOpen-Dialog innerhalb einer Client-Applikation aufgerufen. Während des Imports werden verschiedene Klassen für das Abrufen von Informationen über den Medienstrom (MSMediaImportHelper) und schließlich dem Transkodieren bereitgestellt (MSMTPTranscoder). Letztere sollen im nächsten Abschnitt genauer vorgestellt werden um die Verwendung des DirectShow-SDKs in der Implementierung zu verdeutlichen. Ein Dialogfenster (repräsentiert durch die Klasse CMediaImportDlg) informiert den Anwender über den Inhalt der geöffneten Mediendatei und während der Umwandlung über deren Fortschritt. Zur Beschreibung der Mediendateien wurden die dargestellten Strukturen MSMediaFileDesc und MSMediaStreamDesc verwendet. Nur einige der Attribute sind in Abbildung 27 dargestellt und verdeutlichen einige der zugänglichen Informationen. Der komfortable Zugriff auf Metainformationen einer Datei innerhalb eines MSMediaImportHelper-Objekts wurde mit einer speziellen Klasse des DirectShow-SDKs ermöglicht: IMediaDet. Das nachfolgende Listing verdeutlicht die Verwendung des „Media- Detectors“ innerhalb der Methode ParseMediaFileDesc().

87 5. Implementierung und Validierung

HRESULT MSMediaImportHelper::ParseMediaFileDesc(CString inputPath) { … // init COM

// parameters to read from media file and streams long lOutStreams; GUID streamGUID; double streamLenght; double streamFrameRate; AM_MEDIA_TYPE* streamMediaType = new AM_MEDIA_TYPE; std::vector streamDesc;

// create IMediaDet, set input path and parse file info CComPtr< IMediaDet > pDet; CoCreateInstance( CLSID_MediaDet, NULL,CLSCTX_INPROC_SERVER, IID_IMediaDet, (void**) &pDet ); pDet->put_Filename(inputPath.AllocSysString());

// get total count of streams pDet->get_OutputStreams(&lOutStreams); m_mediaDesc.nrOfStreams = lOutStreams;

// loop: get info from streams within the media file MSMediaStreamDesc actDesc; for (int i=0; iput_CurrentStream(i); // get infos from MediaDet pDet->get_StreamType(&streamGUID); pDet->get_StreamMediaType(streamMediaType); pDet->get_StreamLength(&streamLenght); … // write infos to stream desc actDesc.streamNr = i; actDesc.streamType = streamGUID; actDesc.lenght = streamLenght; … // video format if (streamMediaType->formattype == FORMAT_VideoInfo) { … // collect additional infos from VIDEOINFOHEADER } // audio format else if(streamMediaType->formattype == FORMAT_WaveFormatEx) { … // collect additional infos from WAVEFORMATEX } // finally push stream desc to media desc m_mediaDesc.streamDesc.push_back(actDesc); } … // place to do propper release resources return S_OK; }

Listing 9: MSMediaImportHelper und die Verwendung des DirectShow Media Detectors

Zunächst wird die durch einen lokalen Pfad in Form eines CStrings repräsentierte Mediendatei auf generische Informationen geprüft. Über die Methode get_OutputStreams() wird beispielsweise die Anzahl der in der Mediendatei vorhandenen logischen Medienströme bestimmt. Hierdurch wird ein Schleifendurchlauf ermöglicht, der genauere Informationen über

88 5. Implementierung und Validierung diese sammelt. So kann für jeden Datenstrom dessen Typ (get_StreamMediaType()) oder Länge (get_StreamLength()) in Form einer GUID ausgelesen werden. Eine genauere Unterscheidung nach Medientyp kann sich anschließen, um noch umfangreichere Metainformationen zu erhalten. Im Listing ist diese Möglichkeit nur angedeutet. Die DirectShow VIDEOINFOHEADER-Strukur kann im Falle eines Videostroms beispielsweise Zugriff auf eine BITMAPINFOHEADER-Strukur bieten, die Attribute eines Einzelbildes des Videostroms zugänglich macht. Im Zuge des Imports kommt der MSMediaImportHelper zum Einsatz, um Entscheidungen bei der weiteren Verarbeitung der lokalen Mediendatei zu treffen und den Nutzer über einen Dialog über den Inhalt der Datei zu informieren. Diese Informationen können ebenfalls dazu genutzt werden, um eine Streaming-Session (und die darin offerierten Medienströme) adäquat zu beschreiben.

5.2.3 Transcoding lokaler Medienströme

Für den Import von Mediendateien wurde im Prototyp das Transcoding eines MPEG- Videostroms in das MTP-Containerformat realisiert. Dabei wurden bereits vorhandene Codecs verwendet, um Rohdaten zu komprimieren. Um ein generisches Importszenario abzubilden, wurden während der Implementierung Interfaces definiert, die die hierfür notwendigen Komponenten repräsentieren. Abbildung 28 zeigt die definierten Interfaces in einem vereinfachten Klassendiagramm.

«Schnittstelle» MSMediaTranscoder +Prepare() «uses» +Run() «uses» +OnSampleIn() +OnSampleEncode() +OnSampleOut() «Schnittstelle» +CreateReader() «Schnittstelle» MSMediaReader +CreateEncoder() MSMediaWriter +CreateWriter() +Prepare() +Prepare() +SetCallback() «uses» +SetCallback() +Run() +Write() +OnSampleRead() +OnSampleWritten() «uses» «Schnittstelle» MSMediaEncoder +Prepare() «Schnittstelle» +SetCallback() MSMediaReaderCB +EncodeSample() +OnSample() +OnSampleEncoded() +SetCallback() Abbildung 28: MSMediaTranscoder und assoziierte Interfaces

Das Interface MSMediaReader bietet Funktionen zum Einlesen und Dekodieren von Mediendaten. Im Prototyp wurde mit der Klasse MSMPEG1Reader ein MSMediaReader implementiert, der MPEG-Dateien einliest, die Medienströme innerhalb der Datei separiert und einzelne Datenpakete dekodiert. Klassen, die das MSMediaEncoder-Interface implementieren kodieren Rohdaten aus Medienströmen. Für die prototypische Umsetzung eines MSMediaEncoders wurde in der Implementierung die Klasse VidsoftEncoder definiert. Diese greift auf bereits bestehende Codecs der Video- und Audioconferencing Module der

89 5. Implementierung und Validierung

Applikation zurück. Im Prototyp wandelt ein VidsoftEncoder unkomprimierte Video- Samples mittels H.263 bzw. H.264 um. Das Serialisieren der komprimierten Mediensamples wird schließlich durch das MSMediaWriter-Interface realisiert. Im Prototyp wurde dieses Interfaces in Form einer MTPFileWriter-Klasse implementiert. Objekte dieser Klasse legen komprimierte Mediensamples in einen lokalen MTP-Container ab. Durch die Beschreibung der Grundfunktionen mittels Interfaces wird die Erweiterung des Transcodings auf andere, in der Praxis notwendigerweise breitere, Anwendungsbereiche ermöglicht. So könnte eine umfangreichere Implementierung des MSMediaReader mehr Eingabeformate einlesen und dekodieren. Der Grundstein für eine verhältnismäßig einfache Implementierung ist durch die Verwendung der DirectShow-SDK gelegt. Die implementierte MSMPEG1Reader-Klasse konstruiert einen vergleichsweise einfachen Filtergraphen (vgl. Abschnitt 2.5) um Videodaten aus einem MPEG-Strom auszulesen. Nachfolgendes Listing zeigt diese Konstruktion ohne die im praktischen Einsatz notwendigen Fehlerbehandlungen.

bool MSMPEG1Reader::Run() { … // place to check if reader is ready to run // create filter graph IGraphBuilder* pGraph = NULL; CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER, IID_IGraphBuilder, (void **)&pGraph); // config sample grabber m_pGrabberInterface->SetCallback((MSSampleGrabberCB*) m_pReaderCallback, 0); m_pGrabberInterface->SetOneShot(FALSE); m_pGrabberInterface->SetBufferSamples(FALSE); … // place to create filters pGraph->AddSourceFilter(m_config.inputPath, L"MPEG1 Source", &pSrc); pGraph->AddFilter(m_pGrabberFilter1, L"MPEG1 Video Grabber"); pGraph->AddFilter(pSplitter, L"MPEG 1 Splitter"); pGraph->AddFilter(pVideoDecoder, L"MPEG Video Decoder"); IBaseFilter *pRenderer; … // place to create and add (null) rendering filter // CONNECT FILTERS ConnectFilters(pGraph, pSrc, pSplitter); ConnectFilters(pGraph, pSplitter, pVideoDecoder); ConnectFilters(pGraph, pSplitter, pAudioDecoder); ConnectFilters(pGraph, pVideoDecoder, m_pGrabberFilter); ConnectFilters(pGraph, m_pGrabberFilter, pRenderer); // CONTROL THE GRAPH IMediaControl* pControl;IMediaEvent* pEvent; // query some Interfaces to do control pGraph pGraph->QueryInterface(IID_IMediaControl, (void **)&pControl); pGraph->QueryInterface(IID_IMediaEvent, (void **)&pEvent); // run the graph pControl->Run(); long evCode; pEvent->WaitForCompletion(INFINITE, &evCode); … // place to propper release filters, graph and COM } Listing 10: Konstruktion und Start eines DirectShow Filtergraphen im MSMPEG1Reader

Das Codebeispiel ist dokumentiert und sollte somit unter Berücksichtigung der in Abschnitt 2.5 erläuterten Grundlagen zu DirectShow verständlich sein. Es bleibt festzuhalten, dass durch den

90 5. Implementierung und Validierung

Aufruf der Run()-Methode das Transcoding initialisiert wird. Ein MSSampleGrabber- Objekt (m_pGrabberFilter) greift die eingelesenen und dekodierten Mediensamples ab und ermöglicht so deren weitere Verarbeitung. Dieser SampleGrabber erbt vom MSMediaReaderCB-Interface und implementiert die Methode OnSample(). Diese Methode erlaubt den Aufruf von OnSampleIn() des MSMTPTranscoder-Objekts und somit die weitere Verarbeitung der unkomprimierten Mediensamples innerhalb des Transcoders. Intern nutzt der MSSampleGrabber Methoden eines DirectShow SampleGrabber-Filters. Der weitere Verlauf soll an dieser Stelle nicht näher erläutert werden. Es genügt festzuhalten, dass die unkomprimierten Samples durch Encoder- und Writer-Objekte in ein anderes Format umgewandelt und serialisiert werden können.

5.3 Umsetzung der MSP-Funktionalität

Eine zentrale Herausforderung bei der Erstellung des Prototyps ist die Integration der Funktionalitäten der im Entwurf definierten Teilprotokolle. Hierzu wurde auf eine bereits bestehende Worker-Metapher zurückgegriffen: Worker sind dabei Klassen, die Teilfunktionen einer Entität einer Content-Sharing-Applikation realisieren. In einer Instanz einer Applikation können dabei parallel verschiedene Worker aktiviert werden, die beispielsweise den Nachrichtenaustausch bestimmter Teilprotokolle mit anderen Clients überwachen und steuern. Um die bisherige Applikation um die Möglichkeit des Austausches von MSP und MCP- Nachrichten zu erweitern, wurden entsprechende Worker realisiert, die Nachrichten dieser Protokolle zum einen erstellen sowie versenden und zum anderen empfangen und verarbeiten. Anhand der implementierten MSPWorker-Klasse soll exemplarisch die Integration der Funktionalität eines Teilprotokolls in den bisherigen Applikationsrahmen gezeigt werden.

91 5. Implementierung und Validierung

CSApp

CSService CCSWorkerFactory CGenericWorker

+SendControlData() +CreateInstances() +SendLocalMsg() +OnLocalMsg() +OnRemoteMsg()

MSPClientWorker -m_pDispatcher : MSPDispatcher MSPDispatcher -m_pDecoder : MSPMsgDecoder #m_pEncoder -m_InQueue : MSPMsg[] #SendMSPResponse() #Process() #SendMSPRequest() #OnDescribeRequest() +SendMSPCapability() #OnSetupRequest() #OnGetRequest() +SendSetupResponse() +SendGetResponse() +SendCapabilityMsg() MSClientDescFactory -m_SessionID -m_SessionPath MSPMsgEncoder MSPMsgDecoder +GetPreferenceDescription() +GetCapabilityDesc() +Encode() +Decode() +GetSessionDescription() +EncodeDescription() +DecodeDescription() +SetSessionPath() Abbildung 29: Die Klasse MSPWorker und deren Integration in den Anwendungsrahmen

In Abbildung 29 ist eine MSPClientWorker-Klasse, deren Integration in den bisherigen Applikationsrahmen sowie entsprechende Helferklassen dargestellt. Die CCSWorkerFactory erstellt dabei für die aktive Applikation die verschiedenen benötigten Worker und verwaltet diese. Dargestellt ist mit dem CGenericWorker die generische Klasse, von der alle Worker in einer Applikation abgeleitet sind. Hier werden grundlegende Funktionen zum Nachrichtenaustausch lokaler Worker (Methode OnLocalMsg()) und entfernter Instanzen (Methode OnRemoteMsg()) definiert. Die MSPClientWorker-Klasse realisiert dabei das Senden, Empfangen sowie die Verarbeitung von Nachrichten auf der Seite eines MS- Clients, die mit dem MSP assoziiert werden (vgl. Abschnitt 4.5.2). Dabei nutzt die Klasse verschiedene Helfer: der MSPMsgDecoder dekodiert empfangene MSP-Nachrichten und deren Inhalte. So können mit der allgemeinen Methode DecodeDescription() auch Beschreibungsformate wie das MS-CDF verarbeitet werden. Ein MSPDispatcher hingegen sendet entsprechende MSP-Nachrichten. Zur Kodierung dieser Nachrichten wird ein MSPMsgEncoder-Objekt verwendet, welches analog zum MSPMsgDecoder Funktionen zur Kodierung von Beschreibungsformaten bietet. Zur Beschreibung des Zusammenspiels der beschriebenen Klassen soll nachfolgend beispielhaft ein möglicher Ablauf aufgezeigt werden. Im Szenario empfängt ein Provider nach dem CSP- Offering ein DESCRIBE-Request vom MS-Server. Als Einstiegspunkt soll die OnRemoteMsg()-Methode des MSPClientWorker dienen, die eine generische CTextMessage aufnimmt.

1. Innerhalb der OnRemoteMsg()-Methode wird der Typ der CTextMessage bestimmt. Im Szenario ist die Nachricht vom Typ „DESCRIBE“. 2. Eine Dekodierung der CTextMessage wird vorgenommen. Dabei wird die Struktur ausgelesen, n eine Struktur des Typs MSPDescribeMsg umgewandelt und als Request gekennzeichnet. Diese Umwandlung wird durch die Helferklasse MSPMsgDecoder vorgenommen.

92 5. Implementierung und Validierung

3. Im MSPClientWorker wird nun eine spezielle Handler-Methode zur Weiterverarbeitung des Request aufgerufen: OnDescribeRequest(). Hier wird bestimmt, wie mit der Anfrage umgegangen werden muss. 4. Im Szenario soll die Nachricht positiv beantwortet werden. Hierzu wird zunächst eine neue MSPDescribeMsg-Struktur erstellt und mit entsprechenden Daten gefüllt. Dabei kommt erneut eine Helferklasse zum Einsatz: die MSClientDescFactory. 5. Die MSClientDescFactory bietet Methoden, um die in Abschnitt 4.3.1 vorgestellten Beschreibungsformate zu erstellen. Dabei kommt LMX und entsprechend erstellte Strukturen zum Einsatz. 6. Ist die MSPDescribeMsg-Sruktur mit den notwendigen Daten befüllt, kann sie schließlich durch den MSPDispatcher versendet werden (Methode SendMSPResponse()). 7. Der MSPDispatcher nutzt ein MSPMsgEncoder-Objekt um die MSPDescribeMsg-Struktur in eine CTextMessage umzuwandeln. Diese Umwandlung ist notwendig, um die bestehenden Transportmechanismen der Applikation wieder verwenden zu können. 8. Die kodierte DESCRIBE-Response in Form einer CTextMessage wird mit der Methode SendRemoteMessage() des MSPDispatchers an den Sender der ursprünglichen DESCRIBE Request gesendet. Dabei wird die Nachricht durch bereits vorhandene Funktionen in einen Datenpuffer umgewandelt. 9. Die vorhandene Methode SendControlData() der zentralen Serviceklasse der Client-Applikation (CSService) sendet den Datenpuffer schließlich über die bestehenden Kontrollkanäle der Data-Conferencing-Session. Hier werden - wie schon bei dem Empfang von Nachrichten angedeutet - wiederum vorhandene Komponenten der Client-Applikation genutzt.

Der beschriebene Ablauf zeigt anhand eines einfachen Beispiels im Kontext des MSP, wie die Protokollfunktionalität in den bestehenden Applikationsrahmen integriert werden konnte. Bestehende Transportmechanismen können wieder verwendet werden, indem Strukturen, die MSP-Nachrichten repräsentieren, durch entsprechende Encoder-Klassen in die generische CTextMessage-Struktur umgewandelt werden. So wird im weiteren Verlauf eine einfache Umwandlung in Puffer ermöglicht, die wiederum über Funktionen des CSService verarbeitet und schließlich an den designierten Empfänger gesendet werden können. Für die Kodierung der Beschreibungsformate, die in obigem Szenario beim Versenden der DESCRIBE Response benötigt wird, kommen LMX-Klassen zum Einsatz. LMX bietet die Möglichkeit, aus XSD-Beschreibungen C++ Klassen zu erstellen, diese zu manipulieren und, wie in diesem Anwendungsfall benötigt, in Form von Zeichenketten zu kodieren. Letztere werden schließlich einer CTextMessage-Struktur als Body-Attribut angehangen und können so über bestehende Transportmechanismen versendet werden.

5.4 Umsetzung der MCP-Funktionalität

Die Synchronisierung einer Streaming-Session nach Vorgaben des Presenters einer Sitzung und entsprechende Nachrichten wurden umfassend im Zuge der Konzeption (vgl. Abschnitt 4.5.3) diskutiert. Nachfolgend soll die verbale Beschreibung eines beispielhaften Ablaufs die prototypisch entworfenen Klassen und deren Integration in die Anwendung erläutern. Sie bilden

93 5. Implementierung und Validierung die Funktionalität des MCP auf Seiten des MS-Servers (MCPServerWorker) sowie der MS- Clients (MCPClientWorker) ab.

Abbildung 30: Implementierung des MCP

Abbildung 30 zeigt die bei einer Synchronisation nach Vorgaben des Presenters beteiligten Klassen in Kombination mit einem Szenario: der Presenter einer Sitzung gibt einen Medienstrom lokal an der Position 600ms wieder. Dieser Zustand soll nun an den MS-Server ausgeliefert, als Änderung des Referenzzustandes erkannt und entsprechend an Viewer weitergeleitet werden. Das Diagramm ist dabei entsprechend vereinfacht, um den grundlegenden Ablauf zwischen Presenter, MS-Server und Viewer nachbilden zu können. Nur für die jeweiligen Instanzen relevante Methoden werden dargestellt. Wie bereits in Abbildung 29 angedeutet, existieren auch für einen MCPWorker entsprechende Helferklassen, die Nachrichten kodieren oder dekodieren und über vorhandene Methoden der Applikation an andere Teilnehmer transferieren. Nicht dargestellt ist die Möglichkeit, auf Seiten des MS-Server eine Anpassung der Wiedergabeposition vorzunehmen: dies ist perspektivisch möglich, da MCP-Nachrichten mit Timestamps versehen sind. Der Server kann hierdurch die Latenz der Übertragung bestimmen und den Soll-Zustand entsprechend anpassen.

Der nachfolgende Ablauf soll beispielhaft einen Nachrichtenaustausch zwischen Teilnehmern einer kollaborativen Streaming-Session zeigen. Dabei werden die Teilabläufe nach den beteiligten Rollen separiert. Als Einstiegspunkt dient eine Steueroperation auf Seiten des Presenters. Auf eine umfangreiche Betrachtung der Kodierung der Steuernachrichten soll verzichtet werden.

94 5. Implementierung und Validierung

Presenter 1. Die Wiedergabe eines bereits importierten Medienstroms wird an einer bestimmten Stelle durch den Presenter gestartet. Diese Steueroperation wird im Prototyp durch die Klasse MSPlaybackService registriert und in der Methode OnPlay() behandelt. 2. Es folgt die Aktualisierung des lokalen Zustandes innerhalb des MSClientStateControl. Hier wird der Methode OnLocalControl() ein MSLocalState-Objekt übergeben, welches entsprechende Informationen über den nunmehr aktuellen Zustand der Wiedergabe enthält. 3. Das MSClientStateControl aktualisiert nun den lokalen Zustand durch Aufruf der Methode DoStateUpdate(). Innerhalb dieser Methode wird auch der MCPClientWorker angesprochen. 4. Die Methode OnLocalStateUpdate() informiert den MCPClientWorker über die durchgeführte Änderung des lokalen Zustands. Er initiiert daraufhin mittels SendStateMsg() den Transfer des aktuellen Zustands in Form einer entsprechend kodierten CTextMessage an den Server der Sitzung. In dieser Nachricht ist festgehalten, dass es sich um den Referenzzustand der Sitzung handelt. MS-Server 1. Der Server verarbeitet die empfangene MCPStateMsg-Struktur innerhalb der OnStateMessage() Methode. 2. Im weiteren Verlauf führt der Server in der Klasse MSServerSessionControl die Aktualisierung der verwalteten Sitzung durch. Da es sich bei der zuletzt empfangenen MCPStateMsg um den Referenzzustand der Sitzung handelt, ruft mit DoRefStateUpdate() eine entsprechende Handler-Methode auf. 3. DoRefStateUpdate() initialisiert das Senden einer TICK-Nachricht an verbundene Viewer. Diese wird in Form eines MCPTickMsg Struktur repräsentiert, in eine CTextMessage kodiert und analog zu den letzten Betrachtungen über vorhandene Transportkanäle verteilt. Viewer 1. Der dargestellte Viewer empfängt die TICK-Nachricht des Servers durch die OnRemoteMsg() Methode und behandelt diese entsprechend in die MCPTickMsg- Struktur umgewandelten Informationen in OnTickMessage() weiter. 2. Da es sich hier um eine Aktualisierung des Referenzzustandes der Sitzung handelt, wird die Methode OnRefStateUpdate() aufgerufen. 3. Im MSClientStateControl wird wie auf Seiten des Presenters der lokale Zustand verwaltet. Innerhalb der OnRefStateUpdate() Methode wird nunmehr entschieden, wie auf die Änderungen des Referenzzustandes reagiert wird. 4. In diesem Szenario soll sich der Viewer mit dem Referenzzustand aktualisieren. Es wird eine MSStreamControl Struktur erstellt und die RemoteControl() Methode aufgerufen. Bei der Erstellung der Kontrollnachricht besteht die Möglichkeit, ein Offset aus den angegebenen Timestamps der Steuernachrichten zu erzeugen. Hiermit kann die Latenz während der Übertragung bestimmt werden. 5. Innerhalb der Methode RemoteControl() wird die Steuermethode Play() des lokalen MSPlaybackService aufgerufen. Liegen die benötigten Daten bereits vor, startet die Wiedergabe an der durch den Referenzzustand festgelegten Stelle.

Nach der Änderung der Wiedergabeposition nimmt der Viewer ebenfalls eine Aktualisierung seines lokalen Zustands vor und kann diese Veränderung dem MS-Server über eine STATE

95 5. Implementierung und Validierung

Nachricht mitteilen. Hierdurch wird die Verwaltung lokaler Zustände beim MS-Server ermöglicht, der dadurch im weiteren Verlauf auch einen globalen Zustand der Sitzung ausliefern kann (vgl. Abschnitt 4.3.2.4).

5.5 Transport von Medienströmen

Der Grundstein für die Implementierung des Transports von Medienströmen wurde mit der Realisierung des Imports und der damit verbundenen Erstellung eines MTP-Containers gelegt. In der bisherigen Applikation werden statische Medienobjekte über einen komplexen Transportmechanismus an Teilnehmer einer Sitzung verteilt. Hierbei kommen wiederum spezielle Worker zum Einsatz (bspw. ein CSTransmissionWorker), um lokale Dateien zu segmentieren und schließlich über definierte Transportprotokolle zu übertragen (vgl. CS-BTP in Abschnitt 4.4). Im Zuge der Implementierung wurde zunächst versucht, die entsprechend vorhandenen Module wieder zu verwenden. Dabei müssen Erweiterungen einiger Randbedingungen und Anpassungen vorgenommen werden. Das CS-BTP eignet sich nur zur vollständigen Übertragung einer Binärdatei. Die Angestrebte Echtzeit-Funktionalität, also das Senden eines Datei-Segments (in diesem Falle ein MTP-Block) und deren anschließende Wiedergabe, kann nicht ohne weiteres integriert werden. Hier sind Anpassungen notwendig, um auch die Verteilung einzelner MTP-Blöcke über das CS-BTP zu realisieren. Wie in Abschnitt 5.3 gezeigt werden konnte, existieren bereits Worker, die MSP-Nachrichten verarbeiten können. Diese Worker müssen entsprechende Funktionen eines angepassten CSTransmissionWorker ansprechen, um auch den Transport von MTP-Datenströmen zu initialisieren. Auf Seiten des MS-Servers muss beim Empfang von Binärdaten geprüft werden, ob es sich um MTP-Blöcke handelt. Ist dem so, müssen diese Datenblöcke wiederum von spezialisierten Workern weiterverarbeitet werden. Denkbar ist dabei die Implementierung eines MTPWorkers, der ein Buffering dieser Datenströme realisiert und diese bspw. auf Seiten eines Viewers an entsprechende Playback-Services weiterleitet (vgl. Abbildung 30).

5.6 Zusammenfassung und offene Arbeiten

Im praktischen Teil der Arbeit konnte gezeigt werden, wie Dienstprimitive der im Entwurf definierten Teilprotokolle in eine bestehende Data-Sharing Applikation integriert werden können. Dabei wurden bestehende Komponenten der Anwendung genutzt, um beispielsweise die Verteilung von Nachrichten des MSP zu realisieren. Weitere wichtige Aspekte während der Bearbeitung waren die Erprobung des MTP-Containerformats, der Import von Medienströmen unter Zuhilfenahme bestehender Strategien und die Realisierung verschiedener im Entwurf definierter XML-Beschreibungsformate. Zusätzlich wurden erste Dialog-Komponenten und prototypische Klassen entwickelt, um die Funktionalität des Multimedia-Streamings in die graphische Oberfläche von Client-Applikationen einzubinden. Um eine weit reichende Funktionalität zu gewährleisten, sind weitere praktische Arbeiten notwendig. Zu nennen ist hier in erster Linie die Verteilung von MTP-Paketen durch den MS-

96 5. Implementierung und Validierung

Server und schließlich deren Wiedergabe bei MS-Clients einer Multimedia-Streaming Sitzung. In der prototypischen Entwicklung wurde hierfür ansatzweise die Verwendung bereits existierender Methoden zur Verteilung von zeitdiskreten Medien erprobt. Es ist anzunehmen, dass für eine Echtzeit-Verteilung von zeitkontinuierlichen Medienströmen eigene Transportmethoden entwickelt werden müssen. Ein weiterer wichtiger Aspekt in der praktischen Umsetzung der durch die Teilprotokolle gebotenen Funktionalität ist der Import von Medienströmen und deren Adaption unter Berücksichtigung heterogener Zielplattformen. Im Prototyp wird im Zuge des Imports zunächst ein vollständiges Transcoding in das MTP-Containerformat vorgenommen. Für den praktischen Einsatz unter Echtzeitbedingungen sollten zunächst nur Teile eines Medienstroms importiert und schließlich innerhalb der Sitzung anderen Teilnehmern offeriert werden. Für eine Adaption des Medienstroms kann auf den beschriebenen Prozess des Transcodings zurückgegriffen werden: eine entsprechende Implementierung auf Seiten des MS-Server könnte so eine Anpassung des Medienstroms an Eigenschaften und Bedürfnisse einzelner MS-Clients realisieren. Die Erstellung der dafür notwendigen Beschreibungsformate (MS-CDF und MS- PDF) und deren Austausch über Nachrichten des MSP wurde während der praktischen Arbeit exemplarisch aufgezeigt. Auch der Aspekt der Synchronisierung eines kollaborativen Streamings kann praktisch weiter vertieft werden. Grundvorrausetzung für eine effektive Erprobung der vorgeschlagenen Mechanismen bilden jedoch vorhandene Methoden zur Verteilung und Wiedergabe von zeitkontinuierlichen Medienströmen, die im Zuge der Arbeit noch nicht abschließend umgesetzt werden konnten. Für die praktische Weiterverwendung des Prototyps im universitären Data-Conferencing Testrahmen ist dessen Erweiterung um Komponenten der Audio- und Videoverarbeitung notwendig. DirectShow als Teil der Windows Platform SDK könnte hierzu verhältnismäßig einfach integriert werden und zur Implementierung entsprechender Encoder zur Handhabung des Imports von Multimediaströmen dienen (vgl. 5.2).

97

6. Bewertung und Ausblick

6. BEWERTUNG UND AUSBLICK

Nachdem in den vorherigen Kaptiteln Grundlagen zur Integration von Medienströmen in verteilte synchrone Groupware dargelegt, eine detaillierte Anforderungsanalyse der Problemstellung und eine Konzeption zu deren Lösung vorgenommen sowie Herausforderungen des praktischen Teils der Arbeit beschrieben wurden, soll sich nunmehr eine Bewertung der Arbeit anschließen. Hiernach werden in einem Ausblick einige Ansätze zur weiteren Vertiefung der Thematik vorgeschlagen.

6.1 Bewertung der Arbeit

Ziel der Arbeit war die umfassende Analyse, Konzeption und prototypische Validierung von Verfahren, die eine Integration von Echtzeit-Medienströmen in verteilte synchrone Groupware ermöglichen. Die dazu im 3. Kapitel identifizierten Anforderungen konnten größtenteils durch die Konzeption behandelt werden. Dieser Abschnitt soll die Arbeit anhand einiger während der Analyse herausgestellten Eckpunkte (vgl. Abschnitt 3.2) zusammenfassend bewerten. Eine Betrachtung der Ergebnisse der Bearbeitung soll sich daran anschließen.

Wiedergabe von multimedialen Datenströmen Die Wiedergabe von Datenströmen ist Teil der praktischen Arbeit. Der Grundstein hierfür wurde durch die Einbindung der DirectShow-SDK und vorhandene Klassen der Audio- und Videoconferencing-Module in die Data-Sharing Applikation gelegt. Es wurden bereits prototypisch Klassen bereitgestellt, die perspektivisch eine umfassende Steuerung der Wiedergabe in einer Client-Applikation ermöglichen sollen. Sie dienten im Zuge der Implementierung vorrangig zur Validierung der Übermittlung von MCP-Nachrichten und deren Verarbeitung. Unterstütze Wiedergabeformate Wiederum als Teil der praktischen Arbeit konnte durch die Implementierung des Prototyps gezeigt werden, wie DirectShow zur Verarbeitung praktisch beliebiger zeitkontinuierlicher Inhalte verwendet werden kann. Diese SDK unterstützt dabei von Hause aus viele Quellformate (vgl. Abschnitt 2.5) und kann durch eigene Entwicklungen in Form von Filterobjekten um die Möglichkeit der Verarbeitung weiterer Formate ergänzt werden. Die im praktischen Teil vorgestellten Interfaces zum Transcoding von lokalen Eingabeströmen können auch durch generische (und komplexere) Klassen implementiert werden, die unter Zuhilfenahme von DirectShow oder anderen Multimedia-Frameworks Umwandlungen nahezu beliebiger

99 6. Bewertung und Ausblick

Eingabeströme vornehmen. MTP-Pakete wurden bewusst dazu konzipiert, beliebige Payloads aufzunehmen, um die Daten im weiteren Verlauf zu verteilen. Heterogenität Im Laufe des Entwurfs wurde die Möglichkeit der Existenz heterogener Zielplattformen berücksichtigt. Es wurden umfassende Beschreibungsformate und Protkollabläufe vorgeschlagen, die die Adaption einer Streaming-Session an Eigenschaften von Clientanwendungen ermöglichen. Ein mögliches Transcoding nach Vorgaben der Clients kann so auf Serverseite implementiert werden. Im praktischen Teil wurden die grundsätzlichen Abläufe einer solchen Umwandlung im Zuge des Imports von Medienströmen auf Seite eines Clients gezeigt (vgl. Abschnitt 5.2.3). Synchronisierung Die Aspekte der Kontrolle und Synchronisierung wurden im Laufe der Konzeption umfangreich untersucht und auch Alternativen hierzu diskutiert (vgl. 4.5.3). Es wurde gezeigt, wie Streaming-Sessions beschrieben und Informationen zu deren Zuständen ausgetauscht werden können. Die im Abschnitt 2.3.2 vorgestellten Konzepte eines kollaborativen Streamings konnten umgesetzt und um eigene Ansätze erweitert werden. So kann der beschriebene MS-Server nicht nur zur Verwaltung und Vermittlung von Steuernachrichten des Presenters dienen, sondern den aktuellen Soll-Zustand der gemeinsamen Wiedergabe auch ohne regelmäßige Statusmeldungen des Presenters „schätzen“. Durch einen internen Zähler auf Seiten des Servers und eine initiale Zustandsmeldung durch den Presenter kann diese Funktionalität praktisch realisiert werden. Teilaufgaben wie die Aushandlung und der Wechsel eines Presenters können durch bestehende Teilprotokolle des CSP realisiert werden. Import von Medienobjekten Der Import lokaler Medienobjekte wurde umfassend in Abschnitt 5.2 erläutert. Durch die Wiederverwendung des Prinzips der Importstrategien und der Verwendung eines generischen MSTranscoder-Objekts lässt sich das im Prototyp beschriebene Szenario auf den Import quasi beliebiger Medienformate ausweiten. Hierfür sind entsprechende Implementierungen der Reader-, Encoder- und Writer-Interfaces notwendig. Für den Import von eingebetteten Ressourcen (vorstellbar sind hier bspw. Audiomemos innerhalb einer PowerPoint-Präsentation) sind entsprechende Importstrategien zu implementieren, die Medienströme aus den statischen Inhalten extrahieren. Ein erster Ansatz zur weiteren Behandlung dieser Medienströme wäre, diese wie lokale Medienobjekte entsprechend separiert von statischen Inhalten darzubieten. Technische und sonstige Anforderungen Es konnte im Entwurf gezeigt werden, wie die definierten Teilprotokolle in einen bestehenden Protokollrahmen eingebunden werden können. Der praktische Teil verdeutlicht, dass eine Integration in ein umfassendes und bereits produktiv eingesetztes Gesamtsystem mitunter komplex sein kann. Durch die Integration verschiedener Worker-Klassen wurde ein Weg der Erweiterung des Systems um Funktionen eines kollaborativen Streamings unter Berücksichtigung bestehender Konzepte gezeigt. Wechselwirkungen mit anderen Datenströmen konnten durch die fehlende Erprobung von Transportmechanismen nicht ausreichend berücksichtigt werden. Im bisherigen System können jedoch bereits verschiedene Arten von Datenströmen ausgetauscht werden, wobei ein Priorisierungs-Mechanismus eine Ordnung nach Dringlichkeit vornehmen kann. Für die Erweiterung der Funktionalität um den Transport von Echtzeit-Medienströmen müssen ebenfalls entsprechende Angaben zur Priorität aufgenommen werden.

100 6. Bewertung und Ausblick

Ergebnisse der Arbeit Es konnten im Zuge der Bearbeitung Protokolle definiert werden, die die umfangreiche Aushandlung, die Steuerung und schließlich den Transport von Medienströmen behandeln und dabei die praktischen Aspekte eines Echtzeit-Szenarios berücksichtigen. Teilaufgaben wie die Beschreibung von Eigenschaften und Präferenzen von Teilnehmern oder einer Streaming- Session wurden detailliert behandelt und ein Paket- sowie Containerformat zur Aufnahme von multimedialen Daten vorgeschlagen. Neben den Ausführungen in dieser Ausarbeitung wurden weitergehende Aspekte in einer eigenen Protokollspezifikation festgehalten (vgl. [BAU07]), wodurch auch eine weitere Bearbeitung der Problemstellung ermöglicht wird. Eine umfassende Implementierung konnte aufgrund des Umfangs der Aufgabenstellung und der Komplexität des Zielsystems nicht erreicht werden. An vielen Stellen (bspw. der Wiedergabe von Medienströmen) wurden jedoch prototypische Klassen und Methodenköpfe definiert, um die prinzipielle Funktion eines Gesamtsystems aufzuzeigen. Besonderer Wert wurde auf den Aspekt der Aushandlung und Beschreibungen einer kollaborativen Streaming-Sitzung und deren mögliche Teilnehmer gelegt. Hinzu kommt das durch den Import eines MPEG1-Videostroms prinzipiell aufgezeigte Verfahren zur Verarbeitung beliebiger Medienströme. Hier konnte zeitgleich eine mögliche Integration der neuen Funktionalität in die graphische Benutzeroberfläche und die Verwendung des MTP-Containerformats aufgezeigt werden.

6.2 Ausblick

Nachdem bereits im Zuge der Zusammenfassung des 5. Kapitels Aspekte einer weiteren Vertiefung praktischer Problemlösungen aufgeführt wurden, soll dieser Abschnitt einen Ausblick auf weiterführende wissenschaftliche Untersuchungen der Thematik bieten. Skalierbarkeit und Lastverteilung Ein grundsätzliches Problem bei dem dargelegten Lösungsansatz ist die zu erwartende hohe Belastung des MS-Servers als zentrale Instanz der Architektur. Im Kontext der Adaption trägt dieser einen Großteil der benötigten Funktionalität: Sitzungen müssen nicht nur verwaltet, sondern sollten auch auf die Bedürfnisse einzelner Teilnehmer angepasst werden können. Dabei wird beispielsweise vorgeschlagen, ein Transcoding auf Seiten des MS-Servers nach Vorgaben verbundener Teilnehmer vorzunehmen, um die mögliche Heterogenität der Zielplattformen zu handhaben und das Nutzererlebnis zu steigern. Perspektivisch sind hier weitere Untersuchungen notwendig, die Aspekte der Lastverteilung und Fehlerbehandlung in das vorliegende Szenario (der Verteilung von Medienströmen und deren kollaborative Wiedergabe) einbeziehen. Es existieren bereits Forschungsarbeiten, die es ermöglichen, Teilaufgaben einer Wiedergabe von Multimedia-Formaten in Rechnernetzen zu verteilen und die dabei genutzten Komponenten zu synchronisieren (vgl. NMM in Abschnitt 2.3.3). Hier bleibt zu prüfen, inwieweit die in dieser Arbeit vorgestellten Konzepte um diese feingranulare Abbildung von Verarbeitungseinheiten erweitert werden können. Synchronisierung In der Konzeption wurden die Aspekte der Synchronisierung umfangreich diskutiert. Die Güte und schließlich die Skalierbarkeit der vorgeschlagenen Lösung und entsprechender Alternativen muss weiterhin untersucht werden. Das Konzept des Session-Transfers bzw. -Sharings durch den Austausch von Referenzzuständen kann durch Konzepte der NMM möglicherweise weiter

101 6. Bewertung und Ausblick verfeinert werden. Diese auf die verteilte Wiedergabe von Multimedia spezialisierte Middleware kann durchaus eine nahtlose Übergabe von Zuständen einzelner Nodes, also Verarbeitungseinheiten, realisieren (vgl. [LRS03]). Die Güte der Synchronisierung ist dadurch höher einzuschätzen als bei einem einfachen Session-Transfer. Containerformate für Streaming Für die praktische Anwendung sind weiterhin Untersuchungen zum vorgestellten MTP- Containerformat und entsprechend definierte Paketformate notwendig. Bisher konnten Aspekte des Interleavings bzw. des Deinterleavings und der Intra-Stream Synchronisierung noch nicht ausreichend diskutiert werden. Zur praktischen Nutzung eines MTP-Containers als Dateiformat sind Untersuchungen zu notwendigen Metainformationen vorzunehmen, die eine effektive und fehlerfreie Paketisierung sowie Wiedergabe beliebiger Payload-Formate und Datenströme ermöglichen. Kodierung von Echtzeit-Medienströmen Der Aspekt der Kodierung von beliebigen Eingabeströmen kann sich diesen Betrachtungen anschließen. Es wurden im Zuge der Arbeit bereits Eigenschaften einiger gängiger Mediencodecs vorgestellt. Aufgrund des Umfangs der Arbeit konnten diese Grundlagen nicht in Konzeption und den praktischen Teil der Bearbeitung aufgenommen werden. Für die prototypische Umsetzung wurde auf Codecs der bestehenden Audio- und Videoconferencing Komponenten zurückgegriffen, die üblicherweise eine geringe Latenz, aber zeitgleich eine geringere Wiedergabequalität nach der Kodierung beliebiger Signale (wie bspw. Musik) bieten. Es existieren bereits Entwicklungen (vgl. Abschnitt 2.2.2.3), die in entsprechenden Szenarien Anwendung finden können. Es bleibt zu untersuchen, inwieweit diese Verfahren genutzt und beispielsweise innerhalb eines Transcodings unter Zuhilfenahme von DirectShow eingebunden werden können. Multimedia-Frameworks Neben DirectShow können auch andere Multimedia-Frameworks genauer auf ihre Eignung für die Echtzeit-Verarbeitung von multimedialen Daten untersucht werden. So bietet die NMM bereits eine Fülle von vordefinierten Komponenten, um entsprechende Datenströme zu verarbeiten (siehe [NMM04]). Im Zusammenhang mit der in der Konzeption vorgeschlagenen Datenadaption in einem Echtzeit-Szenario hat die bei der Umwandlung erzeugte Latenz unter Umständen starken (und zumeist negativen) Einfluss auf das Nutzererlebnis. Multimedia- Frameworks und Kompressionsverfahren müssen folglich genauer auf ihre Komplexität und erzeugte Latenz bei der Verarbeitung untersucht werden. Erweiterung bestehender Standards Im Grundlagenkapitel wurden mit RTP und RTSP gängige Standards zur Auslieferung und Steuerung von Echtzeit-Medienströmen vorgestellt, die in klassischen Streaming-Architekturen Anwendung finden. Die vorgeschlagene Konzeption nutzt zur Verteilung beliebiger Medienströme zwischen Teilnehmern einer Sitzung ebenfalls klassische Mechanismen und erweitert diese um Aspekte eines kollaborativen Szenarios. Hier kann weiterhin untersucht werden, inwieweit Standards wieder verwendet und um Funktionen wie Session-Transfer oder - Control erweitert werden können. Mit RTP/I existiert bereits ein Ansatz, um ein RTP-Profil für interaktive Medien zu definieren (vgl. [MHK+99]). Es ist durchaus denkbar, dass durch ein eigenes RTP-Profil Informationen zu Zuständen einer kollaborativen Streaming-Sitzung verteilt werden können. Mit den definierten Beschreibungsformaten wird auch eine Anpassung der durch Provider offerierten Medienströme innerhalb einer Streaming-Session möglich. Zur

102 6. Bewertung und Ausblick

Wiederverwendung bestehender Echtzeit-Protokolle bleibt unter Anderem zu untersuchen, wie diese Funktionalität in das RTSP integriert werden kann.

Die Arbeit konnte zeigen, wie Echtzeit-Medienströme in verteilte synchrone Groupware integriert werden können und welche Anforderungen zur Lösung dieser Aufgabenstellung zu beachten sind. Für die Problemlösung wurden Forschungsarbeiten und Ansätze existierender Protokolle aufgegriffen sowie eigene Ansätze untersucht und diskutiert. Im Zuge der Bearbeitung zeigte sich, dass die Thematik zu umfassend ist, um sie innerhalb dieser Ausarbeitung detailliert zu erläutern. Eine umfangreiche Spezifikation wurde daher neben diesem Dokument gepflegt und vertieft die vorgestellten Protokolle. Sie definiert die exemplarisch gezeigten Beschreibungsformate und Nachrichten förmlich, beschreibt die zu deren Austausch notwendigen Abläufe umfassend und kann so als Einstieg für eine weiterführende wissenschaftliche Bearbeitung des Themas dienen.

103

Literaturverzeichnis

LITERATURVERZEICHNIS

[AKE07] Akester, R.: Low delay MP3 Internet Telephony, 2007 [BAU07] Baumbach, N.: Content Sharing Protocol (CSP) - Teil 7: Multimedia Streaming, 2007 [BK06] Burget, R.; Komosny, D.: Realtime control protocol and its improvements for Internet Protocol television, 2006 [BZB+97] Braden, R. et al.: Resource ReSerVation Protocol (RSVP), 1997 [CIS07] Cisco Systems: Understanding Delay in Packet Voice Networks. url: http://www.cisco.com/warp/public/788/voip/delay-details.html#sourceofdelay Aktualisierungsdatum: 05.03.2007 [COD07] Codalogic: Codalogic XSD XML Schema C++ Binding Code Generator. url: http://www.codalogic.com/lmx/ Aktualisierungsdatum: 04.10.2007 [EGR91] Ellis, C. A.; Gibbs, S. J.; Rein, G.: Groupware: some issues and experiences. In: Communications of the ACM 34 (1991) Nr. 1, S. 39 - 58 [FIN01] Finlayson, R.: A More Loss-Tolerant RTP Payload Format for MP3 Audio, 2001 [FLA04] Flannery, R.: China's Richest-Rice Fields Yield Internet Riches. url: http://www.forbes.com/lists/2004/11/04/cz_rf_1104zhu.html Aktualisierungsdatum: 24.05.2007 [HFG+98] Hoffman, D. et al.: RTP Payload Format for MPEG1/MPEG2 Video, 1998 [ISO05] ISO/IEC : MPEG-1: Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s - Part 2: Video, 2005 [ITU05] ITU-T: ITU-T Recommendation H.263, 2005 [JOH91] Johansen, R.: Teams for Tommorow. In: Proceedings of the Twenty-fourth Annual Hawaii InternationalConference on Systems Sciences 3 (1991), S. 521- 534 [KBW06] Kahmann, V.; Brandt, J.; Wolf, L.: Collaborative Streaming and dynamic scenarios. In: Communications of the ACM 49 (2006) Nr. 11, S. 58-63 [LOH05] Lohse, M.: The Network-Integrated Multimedia Middleware (NMM): Basic Introduction, 2005 [LRS03] Lohse, M.; Repplinger, M.; Slusallek, P.: Dynamic Distributed Multimedia: Seamless Sharing and Reconfiguration of Multimedia Flow Graphs, 2003 [LSG+04] Lutzky, M. et al.: A guidline to audio codec delay. In: Audio Engineering Society (Hrsg. Bd.): AES 116th Convention. , 2004

105 Literaturverzeichnis

[LU,96] Lu, G.: Communication and computing for distributed multimedia systems: Artech House telecommunications library. Boston [u.a.]: Artech House, 1996. - ISBN 0-89006-884-4 [MAN03] Mandal, M. K.: Multimedia Signals and SystemsBd. SECS 716: The Kluwer international series in engineering and computer science. Boston/Dordrecht/Lodon: Kluwer Academic Publishers, 2003. - ISBN 1-4020- 7270-8 [MHK+99] Mauve, M. et al.: A General Framework and Communication Protocol for the Transmission of Interactive Media with Real-Time Characteristics. In: Proc. of IEEE Multimedia Systems (1999) [MIC04] Microsoft Corporation: Advanced Systems Format (ASF) Specification, 2004 [MIC07] Microsoft Corporation: Microsoft DirectShow 9.0 Documentation. url: http://msdn2.microsoft.com/en-us/library/ms783323.aspx [MIL92] Mills, D. L.: RFC 1305: Network Time Protocol (Version 3), 1992 [NMM04] NMM work group : List of available Plugins for NMM, 2004 [PFE03] Pfeiffer, S.: The Ogg Encapsulation Format Version 0, 2003 [PRO07] Professional UI Solutions: Professional GUI tools and solutions for MFC &.NET desktop applications. url: http://www.prof-uis.com/ Aktualisierungsdatum: 23.08.2007 [SC03] Schulzrinne, H.; Casner, S.: RTP Profile for Audio and Video Conferences with Minimal Control, 2003 [SCF+03] Schulzrinne, H. et al.: RTP: A Transport Protocol for Real-Time Applications, 2003 [SCH04] Schmidt, T. R.: Adaptionsalgorithmen zur Erhöhung der Dienstgüte verteilter interaktiver Multimedia-Anwendungen in IP-basierten Netzen Bd. 87 : Bericht über verkehrstheoretische Arbeiten. . Stuttgart : Inst. für Kommunikationsnetze und Rechnersysteme, 2004. - ISBN 3-922403-97-2 [SCH07a] Schuster, D.: Content Sharing Protocol (CSP) - Teil 1: Core, 2007 (a) [SCH07b] Schuster, D.: Bedarfsgesteuerte Verteilung von Inhaltsobjekten in Rich Media Collaboration Applications, 2007 (b) [SCH07c] Schuster, D.: Content Sharing Protocol (CSP) - Teil 3: Distribution, 2007 (c) [SCH07d] Schuster, D.: Content Sharing Protocol (CSP) - Teil 4: Shared Viewing, 2007 (d) [SCH99] Scharphorst, R.: Videoconferencing and Videotelephony: Artech House telecommunications library. 2. ed. Aufl. Boston, Mass. [u.a.]: Artech House, 1999. - ISBN 0-89006-997-2 [SDF90] Sunderstrom, E.; DeMeuse, K. P.; Futrell, D.: Work Teams: Applications and Effectiveness. In: AmericanPsychologist 45 (1990) Nr. 2, S. 120-133 [SMB07] Salomon, D.; Motta, G.; Bryant, D.: Data compression4. ed. Aufl. London: Springer, 2007. - ISBN 978-1-84628-602-5 [SN04] Steinmetz, R.; Nahrstedt, K.: Multimedia Systems : X.media.publishing. Berlin Heidelberg : Springer-Verlag, 2004. - ISBN 3-540-40867-3 [SRL98] Schulzrinne, H.; Rao, A.; Lanphier, R.: Real Time Streaming Protocol (RTSP), 1998 [TPM98] Thom, D.; Purnhagen, H.; MPEG Audio Subgroup: MPEG Audio FAQ Version 9. url: http://www.chiariglione.org/MPEG/faq/mp4-aud/mp4-aud.htm Aktualisierungsdatum: 23.06.2007

106 Literaturverzeichnis

[TSM+95] Teufel, S. et al.: Computerunterstützung für die Gruppenarbeit. Bonn: Addison- Wesley, 1995 [UHV+04] Upperman, G. et al.: Introduction to Methods for Voice Conversion. url: http://cnx.org/content/m12479/latest/ Aktualisierungsdatum: 21.12.2004 [WEB07] WebEx Communications: WebEx Meeting Center Homepage. url: http://www.webex.de/de/solutions/online-meeting-svc.html Aktualisierungsdatum: 20.07.2007 [XIP07] Xiph.Org.: Dare to compare - Vorbis.com, Open Free Audio. url: http://www.xiph.org/vorbis/listen.html Aktualisierungsdatum: 17.07.2007

107

Abkürzungsverzeichnis

ABKÜRZUNGSVERZEICHNIS

AIFF Advanced Interchange File Format API Application Programming Interface ASF Advanced System Format AVI Audio Video Interleave CBR Constant Bitrate CDN Content Delivery Network COM Component Object Model CoSS Collaborative Streaming Service CSCW Computer Supported Cooperative Work FLV Flash Video Format GDI Graphical Device Interface GUID Globally Unique Identifier IFF Interchange File Format MCP Multimedia Streaming - Control Protocol MP3 MPEG-1 Audio Layer III MPEG Motion Picture Expert Group MS-CDF Multimedia Streaming - Capability Description Format MS-GSF Multimedia Streaming - Global State Description Format MS-LSF Multimedia Streaming - Local State Description Format MSP Multimedia Streaming Protocol MS-PDF Multimedia Streaming - Preference Description Format MS-SDF Multimedia Streaming - Session Description Format MTP Multimedia Streaming - Transport Protocol NMM Network-Integrated Multimedia Middleware NTP Network Time Protocol QoS Quality of Service RIFF Ressource Interchange File Format RSVP Resource Reservation Protocol RTCP Real-Time Transport Control Protocol RTP Real-Time Transport Protocol RTSP Real-Time Streaming Protocol SDK Software Development Kit SLB Server Load Balancing SVG Scalable Vector Graphics

109 Abkürzungsverzeichnis

URI Uniform Resource Identifier VBR Variable Bitrate WMA Windows Media Audio WMV Windows Media Video

110 Abbildungsverzeichnis

ABBILDUNGSVERZEICHNIS

Abbildung 1: Prinzipieller Aufbau eines Multimediaformats ...... 11 Abbildung 2: MPEG-1 Videostrom Struktur nach [LU,96] ...... 17 Abbildung 3: Struktur eines ASF Containers ...... 21 Abbildung 4: FLV-1 Struktur und FLV - Tags ...... 22 Abbildung 5: Vereinfachte Architektur klassisches Mediastreaming ...... 24 Abbildung 6: Architektur kollaboratives Streaming aus [KBW06] ...... 26 Abbildung 7: Verteilter Flussgraph für die Wiedergabe einer MP3-Datei (aus [LOH05]) ...... 28 Abbildung 8: Synchronisierung von Nodes in der NMM (aus [LRS03]) ...... 29 Abbildung 9: RTP und assoziierte Protokolle in der Übersicht ...... 30 Abbildung 10: RTP Header mit anschließendem Datenpaket ...... 31 Abbildung 11: DirectShow Filtergraph aus [MIC07] ...... 35 Abbildung 12: Filtergraph in GraphEdit ...... 38 Abbildung 13: WebEx-MC Content Sharing (Screenshot Live-Demo [WEB07]).) ...... 40 Abbildung 14: kollaborative Wiedergabe eines Videos in WebEx ...... 41 Abbildung 15: Szenario kollaborative Wiedergabe multimedialer Daten ...... 43 Abbildung 16: Architektur Multimedia Streaming ...... 56 Abbildung 17: Content Sharing Protokoll (aus [SCH07b]) ...... 65 Abbildung 18: CSP inklusive Multimedia-Streaming ...... 66 Abbildung 19: Teilprotokolle für Multimedia Streaming ...... 67 Abbildung 20: Setup und Buffering innerhalb einer Multimedia-Streaming Session ...... 71 Abbildung 21: Synchronisation nach Navigation durch den Presenter: Best-Case ...... 76 Abbildung 22: Alternativer Ablauf: servergesteuerte Synchronisierung ...... 77 Abbildung 23: Synchronisation nach Navigation durch den Presenter, Worst-Case ...... 78 Abbildung 24: MTP Containerformat (Audiostrom) ...... 80 Abbildung 25: Struktur der bisherigen Implementierung (aus [SCH07b]) ...... 84 Abbildung 26: Import-Dialog und Media-Control-Toolbar ...... 86 Abbildung 27: Importstrategie für lokale Medienströme ...... 87 Abbildung 28: MSMediaTranscoder und assoziierte Interfaces ...... 89 Abbildung 29: Die Klasse MSPWorker und deren Integration in den Anwendungsrahmen ...... 92 Abbildung 30: Implementierung des MCP ...... 94

111

Tabellenverzeichnis

TABELLENVERZEICHNIS

Tabelle 1: Raum-Zeit-Matrix nach [JOH91] ...... 8 Tabelle 2: ITU Sprachcodecs (nach [SCH04] und [SCH99]) ...... 14 Tabelle 3: MPEG-2 Video Level Spezifikation nach [Lu,96] ...... 18 Tabelle 4: ASF Daten-Objekt...... 21 Tabelle 5: Inhalt eines RTCP-SR Pakets nach [BK06] ...... 33 Tabelle 6: Inhalt eines RTCP-RR Pakets nach [BK06] ...... 33 Tabelle 7: RTSP-Requests (Auszug) ...... 34 Tabelle 8: Zusammenfassung der Anforderungen ...... 50 Tabelle 9: Zusammenfassung der Anforderungen (Fortsetzung) ...... 51 Tabelle 10: Übersicht Nachrichten für kollaboratives Multimedia-Streaming ...... 68 Tabelle 11: Mögliche Nachrichten zur Kontrolle eines kollaborativen Streamings ...... 75

113

Selbständigkeitserklärung

SELBSTÄNDIGKEITSERKLÄRUNG

Ich erkläre, dass ich diese Arbeit selbständig verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt und die diesen Quellen und Hilfsmittel wörtlich oder sinngemäß entnommenen Ausführungen als solche kenntlich gemacht habe.

______Dresden, den 20.12.2007 Niels Baumbach

115