Diplomarbeit

im Studiengang Informatik

Thema: Demonstration des RTSP-Videostreamings mittels VLC-Player und einer eigenen Implementierung

Eingereicht von: Karsten Pohl Eingereicht am: 21.04.2015 Betreuer: Prof. Dr.-Ing. Jörg Vogt

Inhaltsverzeichnis Abbildungsverzeichnis .................................................................................................... III

Tabellenverzeichnis.......................................................................................................... V

Abkürzungsverzeichnis ................................................................................................... VI

I. Einführung ................................................................................................................ 1

1.1. Aufgabenstellung ................................................................................................ 1

1.2. Motivation .......................................................................................................... 1

II. Technische Grundlagen und Voraussetzungen ......................................................... 2

2.1. Technische Grundlagen ...................................................................................... 2

2.1.1. RTSP ........................................................................................................... 2

2.1.2. RTP ............................................................................................................. 7

2.1.3. FEC ........................................................................................................... 10

2.2. Voraussetzungen .............................................................................................. 10

2.2.1. Module ...................................................................................................... 11

2.2.2. Programmablauf ........................................................................................ 15

2.2.3. VLC-Player ............................................................................................... 16

2.2.4. Testumgebung ........................................................................................... 17

III. Motion-JPEG ....................................................................................................... 18

3.1. JPEG Kompression ........................................................................................... 18

3.2. Entwurf eines Standards für MJPEG ................................................................ 22

IV. Implementierung .................................................................................................. 26

4.1. Vorgehensweise ................................................................................................ 26

4.2. Analyse ............................................................................................................. 27

4.2.1. VLC ........................................................................................................... 27

4.2.2. Client ......................................................................................................... 29

4.2.3. Server ........................................................................................................ 29

4.2.4. MJPEG ...................................................................................................... 30

4.3. Entwurf und Implementierung ......................................................................... 30

4.3.1. MJPEG ...................................................................................................... 31

4.3.2. Client ......................................................................................................... 35

4.3.3. Server ........................................................................................................ 36

I

4.4. Test ................................................................................................................... 38

4.4.1. Fehler und ihre Ursachen .......................................................................... 39

V. Ausblicke ................................................................................................................ 40

5.1. VLC und FEC ................................................................................................... 40

5.2. Weiterentwicklung ........................................................................................... 40

VI. Zusammenfassung ................................................................................................ 42

Literaturverzeichnis......................................................................................................... 43

II

Abbildungsverzeichnis

Abbildung II-1 RTSP Methoden und Zustände ................................................................ 2 Abbildung II-2 OPTIONS - Anfrage geht beim Server ein .............................................. 3 Abbildung II-3 OPTIONS - Antwort geht beim Client ein............................................... 3 Abbildung II-4 DESCRIBE - Anfrage geht beim Server ein ............................................ 4 Abbildung II-5 DESCRIBE - Anwort geht beim Client ein ............................................. 4 Abbildung II-6 SETUP - Anfrage geht beim Server ein ................................................... 5 Abbildung II-7 SETUP - Antwort geht beim Client ein ................................................... 5 Abbildung II-8 PLAY - Anfrage geht beim Server ein ..................................................... 6 Abbildung II-9 PLAY - Antwort geht beim Client ein ..................................................... 6 Abbildung II-10 PAUSE- Anfrage geht beim Server ein ................................................. 6 Abbildung II-11 PAUSE - Antwort geht beim Client ein ................................................. 7 Abbildung II-12 TEARDOWN - Anfrage geht beim Server ein ...................................... 7 Abbildung II-13 TEARDOWN - Antwort geht beim Client ein....................................... 7 Abbildung II-14 Aufbau JPEG Header ............................................................................. 8 Abbildung II-15 Aufbau Restart-Marker-Header ............................................................. 9 Abbildung II-16 Aufbau Quantisierungstabellen-Header ................................................. 9 Abbildung II-17 Erstellung FEC-Pakete ......................................................................... 10 Abbildung II-18 Aufbau des Videos aus dem Praktium ................................................. 11 Abbildung II-19 Oberfläche des Clients ......................................................................... 12 Abbildung II-20 Graphische Oberfläche des Servers ..................................................... 14 Abbildung II-21 Inhalt Konfigurationsdatei für ein Video on Demand ......................... 16 Abbildung II-22 Aufruf um Video on Demand zu erstellen ........................................... 16 Abbildung II-23 Aufruf um den Stream empfangen zu können ..................................... 16 Abbildung III-1 Farbraumkonvertierung ........................................................................ 19 Abbildung III-2 Reduktion der Datenmenge durch Farbraumkonvertierung ................. 19 Abbildung III-3 Aufbau einer MCU ............................................................................... 20 Abbildung III-4 Umsortierung der Werte durch Zickzack-Scan .................................... 21 Abbildung III-5 Grober Aufbau eines MJPEG ............................................................... 23 Abbildung III-6 Aufbau eines JPEG ............................................................................... 24 Abbildung III-7 Kompletter Header eines MJPEG-Frames im Hex-Editor ................... 25 Abbildung IV-1 Wasserfallmodell mit Rückkopplung ................................................... 26 Abbildung IV-2 Aufnahme einer RTSP-Session des VLC-Players mit Wireshark ........ 28 Abbildung IV-3 Klassendiagramm VideoStream ........................................................... 31 Abbildung IV-4 Klassendiagramm von MJPEGpacketize ............................................. 31 Abbildung IV-5 Bildung der JPEG-Headerdaten ........................................................... 33 Abbildung IV-6 Klassendiagramm BateTasks................................................................ 34 Abbildung IV-7 Klassendiagramm Client ...................................................................... 35 Abbildung IV-8 Implementierung der Methode Describe .............................................. 35 Abbildung IV-9 Graphische Oberfläche des überarbeiteten Clients ............................... 36

III

Abbildung IV-10 Klassendiagramm Server .................................................................... 37 Abbildung IV-11 Implementierung der Methode Describe ............................................ 37

IV

Tabellenverzeichnis

Tabelle 1 wichtige Marker und ihre Zuweisungen ......................................................... 23

V

Abkürzungsverzeichnis

AVI Audio Video Interleave

DCT Diskrete Kosinus-Transformation

DHT Define Huffman table

DQT Define quantization table

DRI Define restart interval

EOI End of image

EOB End of Block

FEC Forward Error Correction

IP Internet Protocol

JPEG Joint Photographic Experts Group

LAN Local Area Network

MCU Minimal Coded Unit

MJPEG Motion-JPEG

RFC Request for Comments

RGB Rot, Grün und Blau

RTP Real-time Transport Protocol

RTSP Real Time Streaming Protocol

SOI Start of image

SOF Start of frame

SOS Start of scan

Ssrc Synchronization Source

TCP Transmission Control Protocol

UDP User Datagram Protocol

URL Uniform Resource Locator

VI

VoD Video on Demand

VII

I. Einführung

1.1. Aufgabenstellung

Ziel dieser Arbeit ist die Weiterentwicklung des an der Hochschule für Technik und Wirtschaft Dresden im Praktikum Internettechnologien 2 angefertigten Beleges zur Implementierung eines einfachen Streamingservers und –clients für Videodaten. Dieser soll um die Fähigkeit erweitert werden, mit dem VLC-Player zu interagieren. Ziel der Interaktion ist es, ein Video im Motion-JPEG-Format (MJPEG) per Real Time Streaming Protocol (RTSP) streamen zu können. Sowohl VLC-Player als auch die eigene Implementation sollen hierbei als Server und als Client agieren können.

Hierfür ist es notwendig dass zunächst beide Programme analysiert werden, in wie weit die verwendeten Protokolle RTSP, Real-time Transport Protocol (RTP) und die Forward Error Correction (FEC) den jeweiligen Standards entsprechen. Der erarbeitete Beleg muss im Rahmen dieser Arbeit entsprechend angepasst und erweitert werden.

Zudem ist es erforderlich, dass zuvor ein einheitlicher Standard für das Motion-JPEG-Format gefunden wird, da ein solcher zu diesem Zeitpunkt noch nicht vorliegt.

1.2. Motivation

Das erstellte Programm dient der Demonstration des RTSP-Videostreamings für Studenten der Informatik durch den Einsatz im Praktikum Internettechnologien 2 bei Herrn Prof. Vogt. Hierfür wurden alle Programmierschritte möglichst einfach und übersichtlich gehalten. Durch die Orientierung an allen gängigen Standards zur Übertragung von Daten per RTSP, RTP/UDP soll der Student ein möglichst reales Bild aktueller Streamingprozesse bekommen.

1

II. Technische Grundlagen und Voraussetzungen

2.1. Technische Grundlagen

Hier sollen zunächst die im Programm verwendeten Protokolle kurz erläutert werden. RTSP wird genutzt um die Übertragung des Videostreams zu steuern und um Übertragungsdetails mit dem Server auszumachen. Anschließend wird das RTP angewiesen die Streaminginhalte im Netzwerk zu übertragen. Auftretende Paketverluste sollen bei dieser Übertragung durch FEC korrigiert werden.

2.1.1. RTSP

Das Real Time Streaming Protocol (RTSP) ist ein Protokoll auf Anwendungsebene und dient der Steuerung der Übertragung von Echtzeitdaten, wie Audio- oder Videodaten. Es ist ähnlich http ein textbasiertes Protokoll und kann als „Netzwerk-Fernbedienung“ betrachtet werden. Durch RTSP kann eine Übertragung beispielsweise gestartet oder pausiert werden, es können aber auch detaillierte Informationen über den Stream ausgetauscht werden, wie die Art des Mediums oder die Abspieldauer von Audio- oder Videoinhalten. Zudem wird per RTSP festgelegt, welcher Port für den Medienstrom genutzt und wie dieser transportiert werden soll, also welches Protokoll genutzt wird um die Daten zu übertragen. [1]

RTSP ist kein zustandsloses Protokoll, der Server muss sich den Zustand eines jeden Clients merken. Dabei nutzt RTSP für jeden Client eine Sitzungsnummer, die für die Zeit der Übertragung gleich bleibt und pro Client eine Sequenznummer, die vom Client bei jeder Nachricht erhöht wird. Die einzelnen Zustände und deren Übergänge sind in Abbildung II-1 dargestellt.

Abbildung II-1 Zustände in denen sich ein Client befinden kann. Die Methoden kennzeichnen die Übergänge zwischen den Zuständen. [2]

2

Bei einer typischen RTSP Session vereinbart ein Client die Transportmechanismen für den Medienstream, startet den Stream und beendet die Verbindung wieder. Das Protokoll nutzt verschiedene Methoden um diese Kommunikation zwischen Server und Client zu gestalten. Die im Programm verwendeten Methoden sollen in den nächsten Punkten kurz vorgestellt werden. Detaillierte Informationen finden sich im RFC 2326. Jede Methode ist folgendermaßen aufgebaut Methode Videodatei RTSP-Version.

2.1.1.1. OPTIONS

Der Client startet im Zustand init. Eine Options-Anfrage kann jederzeit erfolgen, sie beeinflusst weder die laufende Übertragung noch den Zustand des Clients. Die Anfrage muss folgendermaßen aussehen:

Abbildung II-2 OPTIONS - Anfrage geht beim Server ein

Als Ergebnis auf die Anfrage erhält der Client alle Methoden, die vom Server unterstützt werden. Die Antwort muss den folgenden Aufbau haben:

Abbildung II-3 OPTIONS - Antwort geht beim Client ein

2.1.1.2. DESCRIBE

Durch die Describe-Methode erhält der Client eine Beschreibung des Medienobjektes, welches mit der Methode übermittelt wird. Das Format der Antwort richtet sich nach dem Session Description Protocol SDP, was wie in Abbildung II-3 zu sehen ist vom Client gefordert wird. In Abbildung II-4 erkennt man, dass die Antwort alle Initialisierungsinformationen zum Objekt liefert, die es beschreiben.

3

Abbildung II-4 DESCRIBE - Anfrage geht beim Server ein

Die Parameter v (Protokoll Version), o (Urheber und Sitzungskennung), s (Sitzungsname), t (Start und Ende der Sitzung) und m (Objekttyp und RTP Payload Typ) sind obligatorisch, alle anderen Parameter sind optional.

Abbildung II-5 DESCRIBE - Antwort geht beim Client ein

Hinter der letzten Zeile verbirgt sich die exakte URL des Videostreams, die für die Setup-Anfrage benötigt wird. Wird beispielsweise ein Containerformat wie AVI gestreamt, gibt es noch eine weitere Zeile die ebenso aufgebaut ist, aber zum Beispiel auf /movie.mjpeg/trackID=1 enden würde. Dahinter kann sich zum Beispiel der Audiostream für das Video verbergen.

2.1.1.3. SETUP

Die Setup-Anfrage spezifiziert die Transportmechanismen, die genutzt werden sollen um das Video zu streamen. Eine Setup-Anfrage kann auch genutzt werden, um die

4

Transportparameter während der Übertragung zu ändern, sofern das vom Server unterstützt wird. Tut er es nicht, muss der Server mit 455 Methode Not Valid In This State antworten [1]. Die Anfrage muss die genaue URL des Videostreams enthalten. Zudem kann man in Abbildung II-6 den Parameter Transport erkennen. Hier übergibt der Client dem Server den Port, auf dem er den ankommenden Stream erwartet.

Abbildung II-6 SETUP - Anfrage geht beim Server ein

In Abbildung II-7 erkennt man, dass der Server bei einer Setup-Anfrage eine Sitzungsnummer generiert, die für die Dauer der Transaktion gleich bleibt. Zudem werden andere Anfragen die diese Nummer enthalten auf die aktuelle Sitzung bezogen.

Gibt der Server den Parameter timeout mit an, wird die Verbindung automatisch nach dieser Zeit beendet, sofern keine neuen Anfragen beim Server eingehen und die Übertragung beendet oder pausiert ist.

Abbildung II-7 SETUP - Antwort geht beim Client ein

Durch die Setup-Anfrage geht der Client in den Zustand ready über.

2.1.1.4. PLAY

Die Play-Anfrage darf erst erfolgen, nachdem eine erfolgreiche Setup-Anfrage durchgeführt wurde. Durch die Anfrage startet der Server die Datenübertragung zum Client und der Client geht in den Zustand playing über. In Abbildung II-8 sieht man, dass die Anforderung den Parameter Range enthalten kann, hier legt der Client fest, dass z.B. das Video ab einer bestimmten Minute oder Sekunde starten soll. Ist kein solcher Parameter vorhanden, startet die Wiedergabe am Anfang.

5

Abbildung II-8 PLAY - Anfrage geht beim Server ein

Die Antwort auf die Play-Methode gibt zudem die Sequenznummer des ersten RTP-Paketes mit an. Im Beispiel aus Abbildung II-9 ist das der String seq=14971.

Abbildung II-9 PLAY - Antwort geht beim Client ein

2.1.1.5. PAUSE

Diese Methode pausiert die Datenübertragung. Wird der Stream so lange pausiert, dass der durch Setup vorgegebene timeout greift, wird die Verbindung beendet. Die Pause-Anfrage und -Antwort enthalten wie man in Abbildung II-10 und II-11 sieht, die durch den Server vorgegebene Sitzungsnummer. Auch Play und Teardown müssen diese Nummer mit übertragen.

Abbildung II-10 PAUSE- Anfrage geht beim Server ein

6

Abbildung II-11 PAUSE - Antwort geht beim Client ein

2.1.1.6. TEARDOWN

Die Teardown-Anfrage beendet die Übertragung. Der Aufbau der Anfrage und Antwort der Teardown-Methode sieht man in den Abbildungen II-12 und II-13.

Abbildung II-12 TEARDOWN - Anfrage geht beim Server ein

Abbildung II-13 TEARDOWN - Antwort geht beim Client ein

2.1.2. RTP

Das Transportprotokoll RTP stellt Ende-zu-Ende Netzwerkdienste für den Transport von Daten mit Echtzeitcharakter bereit. Diese Dienste umfassen Datentyp-Identifikation, Paketnummerierung, Zeitstempel und Transportüberwachung [3]. Das Protokoll dient der Übertragung von Medien-Datenströmen und wird hier eingesetzt um die Videodaten zwischen Client und Server zu übermitteln.

7

„Für jeden Sender, d.h. pro Übertragungsrichtung, wird eine eigene RTP-Session initiiert. die durch eine Kennung, die SSRC (Synchronization Source)‚ und einen UDP-Port gekennzeichnet ist.“ [4, S. 95]

Infolge der verbindungslosen ungesicherten Kommunikation werden RTP-Datagramme so schnell wie möglich (ohne Verzögerungen z.B. durch Paketwiederholungen) übermittelt. Daher ist RTP im Zusammenspiel mit UDP bestens geeignet für die Echtzeitkommunikation […] Das Echtzeitverhalten wird zusätzlich durch eine zeitliche Synchronisation zwischen Sender und Empfänger sichergestellt, indem RTP per fortlaufender Paketnummerierung und Zeitstempelung gewährleistet, dass die Multimediadaten […] auf der Empfängerseite in korrekter Reihenfolge wiedergegeben werden können. [4]

Verloren gegangene Pakete können die Qualität des Streams beeinträchtigen, führen in der Regel aber nicht zu kompletten Aussetzern. Diese werden durch die Paketnummerierung erkannt und können durch die Nutzung von Verfahren zur Fehlerkorrektur ergänzt werden. Für die Demonstration wird in diesem Fall FEC genutzt.

2.1.2.1. RTP JPEG Payload Format

Jedes Paket, welches per RTP verschickt wird, besteht aus einem 12 Byte großen RTP-Header, der unter anderem die Sitzungsnummer, den Zeitstempel und die Synchronization Source enthält [3]. An den RTP-Header schließt sich nun der Payload an. Da hier ausschließlich Videos im MJPEG Format übertragen werden, greift zusätzlich der Standard RFC 2435. Dieser regelt den Aufbau des Payloads für JPEG-komprimierte Videos und soll hier kurz beleuchtet werden. [5]

Zunächst muss der RTP-Header angepasst werden. „The RTP timestamp is in units of 90000Hz. The same timestamp MUST appear in each fragment of a given frame. The RTP marker bit MUST be set in the last packet of a frame.” [5, S. 3] Zudem enthält jedes Paket einen speziellen JPEG-Header, welcher direkt auf den RTP-Header folgt. Der Aufbau des JPEG-Headers wird in Abbildung II-14 dargestellt und wird im Folgenden kurz erläutert.

Abbildung II-14 Aufbau JPEG Header [5]

8

Das Feld Type-specific wird auf null gesetzt. „ […] this field MUST be zeroed on transmission and ignored on reception.” [5, S. 4]

Damit ein Frame übertragen werden kann, muss er in kleinere Fragmente zerteilt werden. Der Fragment Offset gibt an wie viele Daten des Frames schon gesendet wurden. Type gibt den Typ des Bildes an, die Werte null bis 127 sind für bestimmte Typen reserviert, wobei bisher nur null, eins, 64 und 65 einem genauen Typ zugeordnet werden. Der Typ impliziert die Farbunterabtastung des Bildes und ob Restart Marker verwendet werden. Das Feld Q definiert die Quantisierungstabelle. Ein Wert zwischen 128 und 255 indiziert, dass es im ersten Paket des Frames einen Quantisierungstabellen-Header gibt. Width und Height geben jeweils einen Wert an, der mit 8 multipliziert, die Breite beziehungsweise die Höhe des Bildes angibt. Höhe und Breit können maximal 2040 Pixel groß sein.

Auf diesen Header folgt gegebenenfalls der Restart-Marker-Header, der nur auftritt, wenn der zu übertragene Frame Restart-Marker enthält. Diese Marker dienen der Aufteilung der Bilddaten in kurze Abschnitte. Tritt nun ein Datenverlust auf, können die Bilddaten der restlichen Marker dennoch rekonstruiert werden [6]. Der Aufbau des Restart-Marker-Headers ist aus Abbildung II-15 ersichtlich.

Abbildung II-15 Aufbau Restart-Marker-Header [5]

Das Restart Interval gibt Auskunft über die Anzahl an MCUs (Minimum Coded Units), die zwischen den Markern auftreten. Die restlichen Bits werden auf eins gesetzt. Die eigentlichen Restart-Marker treten dann erst im Payload auf.

Bevor der eigentliche Payload folgen kann, kommt nun noch der Quantisierungstabellen-Header, sofern der Parameter Q aus dem JPEG-Header einen Wert zwischen 128 und 255 aufweist. Der Header ist folgendermaßen aufgebaut:

Abbildung II-16 Aufbau Quantisierungstabellen-Header [5]

9

MBZ und Precision erhalten den Wert null. Length gibt an wie viele Bytes die Quantization Table Data enthält. Wozu dieser Header beziehungsweise die Quantisierungstabellen benötigt werden, wird im Kapitel III MJPEG erklärt.

2.1.3. FEC

Bei der Echtzeitübertragung von Daten gibt es höhere Anforderungen an auftretende Verzögerungen, als bei normalen Verbindungen. Ein erneutes Übertragen dieser Daten ist im Allgemeinen keine mögliche Option. In diesen Fällen nutzt man besser Fehlerkorrekturverfahren, die es dem Empfänger ermöglichen, Fehler zu erkennen und zu korrigieren, ohne nochmals beim Sender rückfragen zu müssen. Ein mögliches Verfahren für solche Fälle ist die Vorwärtsfehlerkorrektur FEC [7].

Die Forward Error Correction ermöglicht durch das Hinzufügen von Redundanz die Wiederherstellung von Informationen, die über einen fehleranfälligen Kanal übertragen werden. Der einfachste Ansatz um diese Informationen zu schützen liegt im Versenden mehrerer Kopien der Datenpakete. Die Menge n aller übertragenen Pakete ergibt sich somit aus der Menge k von Datenpaketen und der Menge p von FEC-Paketen:

n = k + p

Ziel von FEC ist es nun bei Erhalt beliebiger k Pakete alle originalen Datenpakete wiederherstellen zu können. Im konkreten Fall werden hier, wie auch in der Grafik II-17 dargestellt, jeweils zwei aufeinanderfolgende Datenpakete (k=2) mittels XOR-Verknüpfung durch ein FEC-Paket (k=1) geschützt [8].

Abbildung II-17 Erstellung FEC-Pakete [8]

Dadurch entsteht ein Overhead von 50%, allerdings sollte das bei modernen Breitbandverbindungen kaum mehr ins Gewicht fallen.

2.2. Voraussetzungen

Als Vorlage für dieses Projekt dient der im Praktikum Internet Technologien 2 erarbeitete Beleg zur Implementierung eines einfachen Streamingservers und –clients für Videodaten mit integriertem Fehlerschutz. Grundlage des Beleges ist ein

10

Beispielprojekt in Java, aus dem Buch Computernetzwerke von J. F. Kurose und K.W. Ross [2]. Die im Beleg erstellten beziehungsweise ergänzten Klassen werden im Folgenden beschrieben.

2.2.1. Module

Das Projekt besteht neben Server und Client, noch aus den Klassen VideoStream, RTPpacket und FECpacket. Zudem wird ein spezielles Video für das Praktikum verwendet, welches in einem Format vorliegt, das MJPEG ähnlich ist. Die jeweiligen Framegrößen wurden hier den entsprechenden Frames vorangestellt, was in folgendem Aufbau resultiert:

Abbildung II-18 Aufbau des Videos aus dem Praktikum

Davon abgesehen entspricht der Aufbau dem MJPEG Format.

2.2.1.1. Client

Der Client kann über den folgenden Aufruf gestartet werden: java Client [Server] [Server RTSP-Port] [Videodatei]. Als Videodatei kann hier nur das im vorhergehenden Abschnitt erwähnte Video genutzt werden. Die Oberfläche des Clients ist sehr einfach gehalten. Die RTSP-Methoden können einzeln durch den jeweiligen Button ausgelöst werden. Zudem wird eine Statistik über den aktuellen Transfer ausgegeben und sekündlich aktualisiert. Wie in Abbildung II-19 zu sehen ist, stehen dort die empfangene Medienpakete, die Paketverluste, die Paketverlustrate, die Datenrate und die Korrekturen, die durch FEC erfolgt sind.

11

Abbildung II-19 Graphische Oberfläche des Clients

Der Client regelt die komplette Kommunikation mit dem Server, welche über die Konsole nachvollzogen werden kann. Die Steuerung der Übertragung wird durch RTSP realisiert, die eigentliche Übermittlung der Daten wird dann durch das RTP durchgeführt, welches wiederum UDP nutzt.

Im Client wurden bisher die RTSP Methoden Play, Pause, Setup, Options und Teardown eingebettet. Die Umsetzung orientiert sich am Standard RFC 2326, wurde aber nicht in allen Einzelheiten eingehalten, da es sich nur um eine beispielhafte Umsetzung der Methoden handelte. Ob eine Methode erfolgreich war, wird durch einen Parser untersucht. Erhält der Client eine positive Antwort vom Server kann durch den Parser je nach Methode zudem noch die Sequenz- und die Sitzungsnummer ausgelesen werden.

Der Empfang der Daten wird über einen Timer gesteuert. Alle 20 Millisekunden wird ein neues Paket erwartet und entsprechend seiner Sequenznummer in einen Puffer gespeichert. FEC-Pakete können bei Bedarf auch empfangen werden, diese Funktion wird über den gleichen Timer gesteuert. Die Pakete werden aber über einen anderen Port empfangen als die RTP-Pakete, zudem werden nur FEC-Pakete ausgewertet, die benötigt werden um fehlende Medienpakete zu ersetzen, der restlichen FEC-Pakete werden verworfen.

12

Jedes ankommende Medienpaket beinhaltet ein komplettes Bild des Videos. Die Wiedergabe des Videos startet nach einer gewissen Zeit. Diese wird benötigt um die eingehenden Pakete puffern zu können, damit das Video flüssig wiedergegeben werden kann. Aus dem Zeitstempel des ersten Paketes wird diese Zeit berechnet. Dann wird alle 40 Millisekunden ein Paket aus dem Puffer geholt und der Payload, also die Nutzdaten des Paketes, wird dargestellt.

Alle timergesteuerten Ereignisse werden über einen einzigen Timer gesteuert, dem mehrere Action-Handler zugewiesen wurden.

2.2.1.2. Server

Der Server wird initialisiert und wartet dann auf einen Client mit dem er sich verbinden kann. Am Server sind die gleichen RTSP-Methoden wie beim Client implementiert. Alle Funktionen und Konstanten sind auf das Beispielvideo ausgerichtet, das heißt es gibt eine konstante Versandrate der Daten, die RTP-Pakete sind vom Typ MJPEG, es gibt nur eine konstante Sitzungsnummer und die Sequenznummern beginnen bei null.

Außer den Methoden Options und Teardown werden zunächst alle Methoden ignoriert bis eine Setup-Anfrage erfolgt. Mit dieser Anfrage wird die Verbindung initialisiert und der Stream kann durch eine Play-Anfrage gestartet werden. Welche Methode jeweils beim Server eingeht, wird durch den Parser geklärt. Hier landet jede Anfrage des Clients und wird ausgewertet. Je nach Methode werden hier noch weitere Details ausgelesen, wie zum Beispiel die Sequenznummer oder der RTP-Port der dem Server mitgeteilt wird.

Der Server ist im Stande die Medienpakete durch FEC zu schützen. Es werden jeweils zwei aufeinanderfolgende Medienpakete per XOR-Verknüpfung zu einem FEC-Paket zusammengeschlossen und versendet. Der Versand erfolgt parallel zu den Medienpaketen an den vom Client angegeben Port.

Der Server kann immer nur einen Client und eine Videoanfrage verarbeiten, dann muss er neu gestartet werden. Wie Abbildung II-20 zeigt, kann zudem über die graphische Oberfläche am Server eingesehen werden, welches Paket gerade gesendet wird und eine Paketverlustwahrscheinlichkeit kann eingestellt werden, um Paketverluste zu simulieren.

13

Abbildung II-20 Graphische Oberfläche des Servers

2.2.1.3. VideoStream

Die Klasse wird benötigt um aus dem angeforderten Video, die einzelnen Frames zu extrahieren. Sie kann ebenfalls nur auf das Beispielvideo angewendet werden und wird von der Klasse Server aufgerufen.

Videostream liest die ersten fünf Byte aus dem Beispielvideo und erhält so die Größe des ersten Frames. Anschließend liest es die entsprechende Anzahl an Bytes und gibt sie an den Server zurück. Durch die Nutzung eines Fileinputstreams ist der Dateizeiger beim nächsten Aufruf der Klasse noch an der gleichen Stelle in der Datei und es können die nächsten fünf Bytes gelesen werden.

2.2.1.4. RTPpacket

Der Server übergibt den zu versendenden Payload zusammen mit der Sequenznummer, dem Payloadtyp und dem Zeitstempel an die Klasse RTPpacket. Diese baut daraus ein RTP-Paket, das in seiner Struktur dem RFC 3550 entspricht. Es werden lediglich nicht alle Bits entsprechend gesetzt beziehungsweise werden diese bei jedem Paket auf null gesetzt, da es sich wie schon erwähnt um eine beispielhafte Implementation handelte. Der Client kann erhaltene RTP-Pakete an die Klasse RTPpacket übergeben und erhält dafür die Daten zurück, welche sich im Payload befinden. Zudem gibt es verschiedene Funktionen, um beispielsweise die Sequenznummer, den Payloadtyp oder den Zeitstempel eines Paketes direkt auszulesen.

2.2.1.5. FECpacket

Der Klasse FECpacket werden durch die Klasse Server zwei RTP-Pakete übergeben. Diese erstellt daraus ein FEC-Paket. Ein FEC-Paket besteht zunächst aus einem normalen RTP-Header. An diesen schließt sich dann der FEC-Header an, welcher aus

14

den mit XOR verknüpften RTP-Header-Daten der beiden zu verknüpfenden Pakete besteht. Darauf folgt der Payload, bei dem die Payload-Daten der Medienpakete Byte für Byte durch XOR verknüpft werden. Der Client kann auch dieser Klasse erhaltene FEC-Pakete übergeben um an die Nutzdaten zu kommen. Ansonsten bietet die Klasse dieselben Funktionen wie die Klasse RTPpacket an, nur eben für FEC-Pakete.

2.2.2. Programmablauf

Dem Server wird zunächst ein Port übergeben, auf dem ankommende RTSP-Anfragen eines potentiellen Clients ankommen. Nachdem die graphische Oberfläche gestartet wurde, wartet der Server nun auf einen Client der sich mit ihm verbindet.

Dem Client werden die IP-Adresse des Servers und der Port auf welchem dieser RTSP anfragen erwartet, sowie das gewünschte Videofile übergeben. Nachdem die graphische Oberfläche gestartet und die Parameter überprüft wurden, wird eine Verbindung mit dem Server hergestellt.

Nun können über die graphische Oberfläche RTSP-Anfragen an den Server geschickt werden. Dieser erwartet zu Beginn die Methode Setup um den Stream zu initialisieren. So erhält er die Ports für die Übermittlung der Daten für RTP- und FEC-Pakete und das gewünschte Videofile. Ebenso kann der Server zu Beginn die beiden Methoden Options und Teardown verarbeiten. Andere Methoden werden zu diesem Zeitpunkt vom Server ignoriert.

Ist die Setup-Anfrage erfolgt, kann der Stream durch Play gestartet, durch Pause pausiert und durch Teardown beendet werden. Auch eine Options-Anfrage ist wieder möglich.

Wird der Stream durch Play gestartet, übergibt der Server den Video-File-String der Klasse VideoStream und erhält den ersten Frame des Videos zurück. Dieser wird an die Klasse RTPpacket weitergegeben, wo ein entsprechender Header konstruiert und der komplette Frame in den Payload des Paketes abgelegt wird. Das erhaltene RTP-Paket wird dann in einem Datagrampacket verstaut und an den Client geschickt.

Dies geschieht Timer-gesteuert alle 40 Millisekunden, bis das Ende des Videos erreicht ist. Bei jedem zweiten Durchgang wird zudem das aktuelle und das vorangegangene RTP-Paket an die Klasse FECpacket übergeben und ein FEC-Paket daraus erstellt. Dieses wird dann ebenfalls in einem Datagrampacket verstaut und an den erhaltenen FEC-Port des Clients geschickt.

Der Client erhält die Pakete und ordnet sie ihrer Sequenznummer entsprechend in einen Puffer ein. Enthält ein FEC-Paket die Sequenznummer eines Medienpaketes, welches

15

noch nicht im Puffer liegt, wird es aus dem FEC-Paket wieder hergestellt, sofern das entsprechend andere Paket vorliegt. Fehlen beide Pakete ist eine Wiederherstellung nicht möglich. Wird ein FEC-Paket nicht benötigt, wird es wieder verworfen.

Die Pakete im Puffer werden nach einer kurzen Pufferzeit ausgewertet, heißt die Nutzdaten werden ausgelesen und die Frames dargestellt.

2.2.3. VLC-Player

Der VLC-Player ist ein freier und quelloffener Multimediaplayer der VideoLAN non-profit organization, der einen Großteil der Audio- und Videoformate abspielt und verschiedene Streamingprotokolle unterstützt. In Hinblick auf die Fähigkeit ein MJPEG sowohl streamen als auch empfangen und abspielen zu können, wird für dieses Projekt auf die Entwicklerversion 3.0.0-git zurückgegriffen, da der VLC-Player in der aktuell vorliegenden Version 2.1.5 nur in der Lage ist MJPEG-Streams zu empfangen. Die Implementation MJPEGs per RTP streamen zu können richtet sich in der Entwicklerversion nach dem RFC 2435 und unterscheidet sich nicht im Transport von einfachen JPEG Standbildern.

Um ein MJPEG streamen zu können, wird auf die Funktion Video on Demand (VoD) des VLC-Players zugegriffen. Hierfür wird zunächst eine Konfigurationsdatei angelegt, welche den folgenden Inhalt hat:

Abbildung II-21 Inhalt Konfigurationsdatei für ein Video on Demand

In Zeile eins wird ein neues Video on Demand erstellt, das heißt, das Video wird nur versendet, wenn ein Client danach fragt. Zeile zwei legt fest, welche Datei gestreamt werden soll, wenn das Video on Demand angefordert wird. In der letzten Zeile wird das Video on Demand dann aktiviert. Der Aufruf der Konfigurationsdatei erfolgt dann durch den Aufruf über die Konsole, samt IP-Adresse des Servers und dem Port, auf welchem die RTSP-Anfragen erfolgen:

Abbildung II-22 Aufruf um Video on Demand zu erstellen

Um einen Stream empfangen zu können ist folgender Aufruf ausreichend:

Abbildung II-23 Aufruf um den Stream empfangen zu können

16

2.2.4. Testumgebung

Programmierung und Tests wurden unter Windows 7 durchgeführt. Als Entwicklungsumgebung kam die Eclipse IDE for Java Developers in der Version Luna Service Release 1a (4.4.1) zum Einsatz. Java lag zum Zeitpunkt der Programmierung in der Version 1.8.0_31 vor.

Zudem wurde unter der Linuxdistribution Ubuntu 14.04 mit der Java Version 1.7.0_75 getestet.

Der VLC-Player konnte in der Version 2.1.5 als Client genutzt werden, um MJPEG streamen zu können musste aber auf die Entwicklerversion 3.0.0-git gewechselt werden.

Um die Kommunikation mit dem VLC-Player analysieren zu können kam zudem das Netzwerkanalysetool Wireshark in der Version 1.8.5 zum Einsatz.

Der Hex-Editor MX 6.0.2.244 von NEXT-Soft half beim Verständnis zum Aufbau von MJPEG-Videos.

Sämtliche Diagramme wurden unter MagicDraw UML 17.0.1 erstellt.

17

III. Motion-JPEG

„Motion JPEG (MJPEG) ist ein Kompressionsverfahren für Videodaten, das Einzelbilder einer Videosequenz separat und unabhängig voneinander mit dem JPEG-Verfahren komprimiert.“ [9, S. 35]

Aktuell wird der Videocodec von den meisten Browsern und Mediaplayern unterstützt, aber auch Spielekonsolen und vor allem Netzwerk- und Digitalkameras nutzen dieses Format. Anders als bei vielen anderen Videoformaten, die in internationalen Standards definiert werden, gibt es aber keine anerkannte allgemeine Spezifikation für MJPEG. Aufbauend auf den Entwürfen von Apples QuickTime File Format Specification [10] und Microsofts OpenDML AVI Format Extensions [11] soll im Weiteren ein einheitlicher Standard für das MJPEG Format entwickelt und implementiert werden. Zunächst soll aber der Aufbau eines einfachen JPEG Bildes betrachtet werden, dies ist notwendig um die folgenden MJPEG-Spezifizierungen nachvollziehen zu können.

3.1. JPEG Kompression

JPEG steht für Joint Photographic Experts Group, ein Gremium welches 1992 den JPEG Standard spezifizierte. Der Standard definiert Techniken um Bilddaten kodieren, dekodieren und speichern zu können. Um möglichst viele Anwendungsbereiche abdecken zu können, wurden mehrere Kodierungsmechanismen definiert, die jeweils auf einen Teil der JPEG Techniken zurückgreifen [12]. Die Mechanismen werden in vier Modi aufgeteilt: Baseline-Prozess, erweiterter DCT-basierter Prozess; verlustfreier und hierarchischer Prozess.

Der Versand von JPEGs und JPEG-komprimierten Videos per RTP wird durch das RFC 2435 auf den Baseline-Prozess beschränkt [5, S. 3]. Daher soll an dieser Stelle nur dieser betrachtet werden.

Der Baseline-Prozess definiert die minimale Funktionalität eines JPEG-Decoders. Dieses Verfahren basiert auf dem Prinzipien der DCT-basierten Codierung und es können Bilder mit 8 Bits pro Abtastwert in jeder Komponente verarbeitet werden. Die Codierung erfolgt sequentiell, d.h. Block für Block. [13]

Zunächst wird das unkomprimierte Bild in 8x8 Pixelblöcke zerlegt und in den YCbCr-Farbraum konvertiert. Dieses Format speichert statt der Anteile der Grundfarben Helligkeits- (Luminanzanteil Y) und Farbigkeitswerte (Chrominanzanteil Cb, Cr). Die Werte werden folgendermaßen berechnet:

18

Abbildung III-1 Berechnungen für die Konvertierung vom RGB- in den YCbCr-Farbraum. R – Rot, B – Blau, G - Grün

JPEG profitiert davon, dass das menschliche Auge feine Farbabstufungen wesentlich schlechter unterscheiden kann als Helligkeitsunterschiede. Das heißt dass die Farbigkeitswerte jeweils nur einen Mittelwert aus einem 2x2 Pixelblock darstellen und sich die Datenmenge im Vergleich zum RGB-Format auf die Hälfte reduziert. [14]

Abbildung III-2 Reduktion der Datenmenge durch Farbraumkonvertierung [14]

Der Baseline-Prozess organisiert die Daten innerhalb des Datenstroms in sogenannten MCUs (Minimum Coded Units). Eine MCU enthält zwei zueinander gehörige 8x8 Pixelblöcke der beiden Farbigkeitsanteile und alle Blöcke der Helligkeitsanteile, die zu den Farbigkeitsblöcken gehören. Bei dem Beispiel in Abbildung III-3 wird die Farbunterabtastung 4:2:0 genutzt, das heißt dass ein 16x16 Pixelblock aus 4 Helligkeitsmatrizen a 8x8 Pixel und 2 Chrominanzmatrizen 8x8 Pixel besteht und insgesamt eine MCU bildet [15].

19

Abbildung III-3 Aufbau einer MCU [16]

Nun wird auf jeden Block eine Transformationskodierung mit Hilfe der Diskreten Kosinus-Transformation (DCT) angewendet. Ohne in die Einzelheiten zu gehen, werden die 64 Koeffizienten eines jeden Blocks in Frequenzen umgewandelt. Der erste Wert in dieser 8x8 Matrix ist der DC-Koeffizient (Gleichspannungsanteil) und bestimmt den Durchschnittswert für den gesamten Block. Die anderen 63 Werte sind AC-Koeffizienten (Wechselspannungsanteil) [17].

Da der Inhalt vieler Bilder zu einem Großteil aus Flächen und nur zu einem kleinen Teil aus scharfen Kanten besteht, ist nach der DCT eine erhebliche Datenreduktion möglich. Scharfe Kanten werden durch einen hohen Frequenzanteil repräsentiert, dadurch ergibt sich, bei einem Bild durchschnittlicher Komplexität, dass viele AC-Koeffizienten den Wert null oder fast null besitzen [17].

Durch die Methodik der Quantisierung kann die Datenreduktion realisiert werden. Dabei werden die zuvor errechneten DCT-Koeffizienten durch bestimmte Quantisierungsfaktoren geteilt und zum nächst ganzzahligen Wert gerundet. Diese Quantisierungsfaktoren können den Quantisierungstabellen entnommen werden, welche entweder vom JPEG Standard bereitgestellt werden oder durch eine Bildanalyse optimiert und berechnet werden können. Die Quantisierungstabelle erscheint später auch im Header des JPEGs. Durch die Anpassung der Werte dieser Tabellen entsteht ein Mittel zur Schaffung eines Kompromisses zwischen Qualität und Kompression [15].

20

Werden die Werte nach der Quantisierung wie in Abbildung III-4 dargestellt diagonal abgelesen, bilden sich längere Sequenzen gleicher Werte, welche in der folgenden Entropiekodierung effizienter abgespeichert werden können.

Abbildung III-4 Umsortierung der Werte durch Zickzack-Scan

Zunächst wird auf die erhaltene Zahlenfolge eine Lauflängenkodierung angewendet. Das Prinzip dieser Kodierung ist es, alle Nicht-null Koeffizienten als Wertepaare (r|v) zu kodieren, wobei r für die Anzahl an nullen vor dem Koeffizient und v für den Wert des Koeffizienten steht. Das Beispiel aus Abbildung III-4 würde also die folgende Reihe ergeben:

(15), (1|-2), (0|-1), (0|-1), (0|-1), (2|-1), (EOB)

Die Kodierung wird nicht auf den DC Koeffizient angewendet. Zudem endet die Reihe mit (EOB). Mit diesem Symbol beendet JPEG den Block, das heißt dass ab hier nur noch nullen folgen [15]. Bevor nun noch die Huffman-Kodierung folgen kann, wird bei jedem Block die Differenz zwischen dem DC-Koeffizienten und seinem linken Nachbarn gebildet. Würde dieser zum Beispiel den Wert 13 haben, ergibt sich die Reihe:

(2), (1|-2), (0|-1), (0|-1), (0|-1), (2|-1), (EOB)

Die Huffman-Kodierung nutzt die unterschiedliche Häufigkeitsverteilung der auftretenden Symbole. Im Prinzip wird jedem Symbol entsprechend seiner Häufigkeit eine bestimmte Bitfolge zugewiesen, welche in der Datei gespeichert wird. Zudem gibt es für DC- und AC-Koeffizienten unterschiedliche Tabellen, welche aber alle im Header des Bildes gespeichert werden. Detailliertere Informationen zur Huffman-Kodierung finden sich im Standard ISO/IEC 10918-1 Annex C [12].

21

3.2. Entwurf eines Standards für MJPEG

MJPEG ist ein Videoformat bei dem jedes Einzelbild aus einem separaten JPEG-Standbild besteht. Diese Einzelbilder werden aneinander gereiht und ergeben den Videostream. Warum sich für dieses Verfahren kein einheitlicher Standard durchsetzen konnte, lässt sich nicht genau sagen.

Zum einen baut MJPEG auf JPEG auf, somit ist der Codec zumindest was die einzelnen Frames betrifft von Haus aus hinreichend gut standardisiert.

Worin liegen also die Unterschiede zwischen den einzelnen MJPEG Codecs?

Der JPEG Standard regelt nicht jedes Detail der Kompression. Allein schon die vier erwähnten Modi Baseline-Prozess, erweiterter DCT-basierter Prozess; verlustfreier und hierarchischer Prozess ergeben eine völlig andere Struktur im erstellten JPEG. Hinzu kommen Unterschiede, die durch die Wahl unterschiedlicher Quantisierungstabellen und der Farbunterabtastung zustande kommen. Auch die Farbtiefe kann variieren.

„Zu Beginn der Videoschnittzeiten war der Codec [..] noch hauptsächlich auf Hardware (Capture-Karten) angewiesen […].“ [18, S.27] Jeder Hersteller setzte den Codec auf eine andere Art und Weise um, indem eigene Tabellen genutzt wurden, zusätzliche Marker dem Header hinzugefügt wurden, oder die Informationen im Header einfach ganz anders strukturiert wurden, was dazu führte, dass die Codecs untereinander nicht mehr kompatibel waren. Es gab aber auch Versuche einiger Hersteller einen Standard durchzusetzen.

Unter maßgeblicher Beteiligung von Matrox und Microsoft versuchte das Open Digital Media Consortium einen MJPEG-Standard für die Windows-Plattform zu etablieren. […] Allerdings zogen nicht alle Hersteller nach […] [9, S. 35]

Apple definiert in der Quicktime File Format Specification [10] zwei verschiedene Formate für den Aufbau eines MJPEG: die Formate MJPEG A und MJPEG B. Das B-Format verzichtet im Gegensatz zum A-Format auf Marker, welche benötigt werden um die Headerdaten eines JPEG zu strukturieren. Stattdessen fügt Quicktime einen Header an den Anfang des Bitstreams [10]. Nötig wurden die beiden unterschiedlichen Versionen um verschiedene Videocapture-Karten zu bedienen die nur bestimmte Arten von MJPEG unterstützen. „Ein weiterer Unterschied [zwischen A- und B-Format] ist, dass MJPEG B-Videos nicht mehr kompatibel zum standardisierten JPEG-Format sind.“ [18, S.27] Im weiteren soll das B-Format vernachlässigt werden, da speziell beim RTP-Transport von JPEG kodierten Videos, entsprechend RFC 2435, Bildinformationen anhand der Marker aus dem Video gefiltert und versendet werden.

Da der Standard in Hinblick auf die Möglichkeit entworfen wird, MJPEG per RTP streamen zu können, wird nicht auf Einzelheiten des MJPEGs eingegangen, die für

22

dieses Vorhaben irrelevant sind beziehungsweise die eine folgende Implementierung nicht beeinflussen.

Da ein MJPEG aus mehreren JPEGs besteht, orientiert sich der Aufbau am Standard für JPEG ISO/IEC 10918-1 Annex B. „A set of images of this type with compatible parameters can be placed in an AVI file to describe a motion sequence. Frame headers for these DIBs shall be limited to those specified in Para B.2.2 of the cited Annex B.” [11, S. 30]

Zunächst besteht jedes einzelne JPEG aus verschiedenen Teilen. Jeder Teil wird durch einen zwei Byte langen Token, den so genannten Markern identifiziert. So beginnt jedes Bild mit einem Start-of-image Marker (SOI), auf welchen der Frame folgt. Dieser enthält weitere wichtige Marker beziehungsweise Tabellen, sowie die eigentlichen Bilddaten, die MCUs. Ein Frame endet mit dem End-of-image Marker (EOI), der das Ende des Bildes markiert [12]. Ein Motion-JPEG besteht aus der Aneinanderreihung dieser Syntax:

Abbildung III-5 Grober Aufbau eines MJPEG

Die Marker, welche im Frame liegen, werden benötigt um aus den MCUs das eigentliche Bild zu konstruieren. Dazu leitet ein Marker jeweils eine kurze Sequenz ein, in der bestimmte Parameter, Tabellen oder Headerdaten liegen. Dieses Markersegment besteht aus dem Marker selbst, gefolgt von einem Längenindikator für das Segment und den eigentlichen Daten [12].

Die folgenden 4 Marker muss jedes Frame enthalten:

Zuweisung (hexadezimal) Symbol Beschreibung FFC4 DHT Define Huffman table(s) – Huffmantabelle FFDB DQT Define quantization table(s) –

Quantisierungstabelle FFC0 SOF Start-of-frame – Rahmenparameter FFDA SOS Start-of-scan – Scan-Parameter Tabelle 1 wichtige Marker und ihre Zuweisungen

Hinzu kommt je nach Bildtyp noch ein DRI (Define Restart Interval) Marker, welcher wiederum RST (Restart) Marker zwischen den MCUs impliziert. Die Marker sind folgendermaßen aufgebaut:

23

Abbildung III-6 Aufbau eines JPEG [verändert nach 12]. ECS steht für Entropy-coded segment

Auf den SOS Marker folgen die Bilddaten. Die anderen Marker treten zwischen SOI und SOS Marker auf, können aber in ihrer Reihenfolge variieren.

In Abbildung III-6 sieht man den kompletten Header eines MJPEG-Frames inklusive der genannten Marker im Hex-Editor.

24

Abbildung III-7 Kompletter Header eines MJPEG-Frames im Hex-Editor

Sowohl Apple als auch Microsoft definieren zudem noch Application Marker, da diese aber keine zusätzlichen Bildinformationen beinhalten, wird im Folgenden auf nähere Ausführungen verzichtet. Weitere Einschränkungen finden durch das RFC 2435 statt. Die Farbtiefe wird auf 8 Bit beschränkt und der Kodierungsprozess darf nur im Baseline-Modus erfolgen [5].

Zudem werden durch das RFC 2435 die Farbunterabtastformate indirekt auf 4:2:0 und 4:2:2 beschränkt, da keine anderen Formate definiert werden. Andere Formate können zwar genutzt werden, indem dem Type-Feld im RTP-JPEG-Header ein dynamischer Wert zugeordnet wird, allerdings können andere Applikationen mit diesem Wert nicht umgehen.

25

IV. Implementierung

Nach der Vorstellung des MJPEG-Codecs soll dieser nun in den in Abschnitt 2.2. vorgestellten Beleg integriert werden. Zudem soll der Beleg dahingehend erweitert werden, dass er mit dem VLC-Player kommunizieren kann. Das heißt der Beleg soll sowohl als Client als auch als Server in der Lage sein RTSP-Streams mit dem VLC-Player auszutauschen. Dieses Kapitel beschäftigt sich mit der Herangehensweise an dieses Vorhaben.

4.1. Vorgehensweise

Da die vorliegende Arbeit auf einem bereits vorhandenen Projekt (Beleg) aufbaut, das die Grundfunktionalitäten bereits beinhaltet, wurde für die Implementierung folgendes Vorgehen angewendet:

Zunächst wurde zusammengetragen um welche Features das Programm erweitert werden muss, damit der MJPEG-Codec verarbeitet werden kann. Dann wurden nach und nach die schon implementierten Funktionalitäten analysiert und auf Richtigkeit überprüft. Jede Funktion wurde dabei mit dem jeweiligen Standard verglichen und gegebenenfalls angepasst. Zudem wurde eine Kompatibilität mit dem VLC-Player sichergestellt, das heißt die einzelnen RTSP-Methoden wurden an das RFC 2326 angepasst um eine fehlerfreie Kommunikation zu ermöglichen. Im Anschluss wurde jede Funktion für sich und im Gesamtkontext getestet. Als Vorgehensmodell wurde, wie aus Abbildung IV-1 ersichtlich wird, ein Wasserfallmodell mit Rückkopplung gewählt.

Abbildung IV-1 Wasserfallmodell mit Rückkopplung

26

Da es sich bei diesem Projekt um eine Erweiterung eines bestehenden Programmes handelt wurde dieses Modell gewählt. Dadurch wird unter anderem erreicht, dass das überarbeitet Programm möglichst nah an der Struktur des Originals ist. Damit haben die Studenten die Möglichkeit sich einfacher in diese Version des Streaming-Clients/Servers einzuarbeiten. Zudem kann somit jede schon existierende Klasse Funktion für Funktion analysiert und bearbeitet werden.

Um im Folgenden eine bessere Übersicht zu gewährleisten wird zunächst die Analysephase für alle Klassen abgehandelt. Erst dann folgen die weiteren Phasen.

4.2. Analyse

Bevor mit der Programmierung begonnen werden konnte, musste zunächst der aktuelle Stand der Klassen betrachtet und die Anforderungen an die Interaktion mit dem VLC-Player und den MJPEG-Codec ermittelt werden. Folgende Fragen werden unter anderem im Laufe des Kapitels beantwortet:

1. Kann der VLC-Player Videos im MJPEG-Format streamen? 2. Richtet sich der VLC-Player beim Streamen per RTSP und RTP nach den

gängigen Standards? 3. Unterstützt der VLC-Player FEC? 4. Richtet sich die Umsetzung der RTP und RTSP Protokolle im Beleg nach den

aktuellen Standards? 5. Wie läuft der Umgang mit dem MJPEG Video ab, wie wird dieses fragmentiert,

versendet und zusammengefügt?

4.2.1. VLC

Um Videos mit dem VLC-Player streamen zu können, benötigt man den VideoLan Manager. Mit diesem kann man sogenannte Videos on Demand erstellen, also einen Stream zur Verfügung stellen, den man bei Bedarf anfordern kann. Zunächst fiel auf, dass der VLC-Player in der aktuellen Version 2.1.5 MJPEGs zwar abspielen kann, aber nicht in der Lage ist diese auch zu streamen. Die Fehlermeldung

„cannot add this stream (unsupported codec: MJPEG)“

erscheint aufgrund einer fehlenden Implementierung des Codecs in der Datei rtpfmt.c. Diese ist dafür verantwortlich aus einem Stream gültige RTP-Pakete zu erstellen. Der entsprechende Code wurde in der Entwicklerversion 3.0.0-git ergänzt, weshalb weitere Tests mit dieser Version durchgeführt wurden. Die getätigten Änderungen sind unter

27

der folgenden Adresse einzusehen: https://github.com/videolan/vlc/commit/2b0d98825 30302947ab4774a3bac119da6094581

Die Einhaltung des Standards für das Transportprotokoll RTSP wurde per Wireshark kontrolliert. Hierfür wurde unter Linux mit dem VLC-Player 3.0.0-git ein Video on Demand erstellt. In Abbildung IV-2 ist der Server an der IP 192.168.2.2 zu erkennen. Als Client dient ein anderer Rechner im lokalen Netzwerk, zu erkennen an der IP 192.168.2.3. Dieser verwendet den VLC-Player 2.1.5 unter Windows. Auf diesem Rechner wurde auch Wireshark ausgeführt. In der Abbildung IV-2 sieht man die Antwort des Servers auf die Methode Options. Es ist zu erkennen, dass diese Methode dem Standard also dem RFC 2326 entspricht.

Abbildung IV-2 Aufnahme einer RTSP-Session des VLC-Players mit Wireshark

Auf diese Art und Weise wurden alle RTSP-Methoden überprüft und mit dem RFC 2326 verglichen. Das Ergebnis des Tests zeigt, dass der VLC-Player dem Standard entspricht.

Als nächstes wurde der Aufbau der RTP Pakete überprüft. Deren Aufbau konnte durch die schon erwähnte Implementierung des MJPEG-Codecs in der Datei rtpfmt.c nachvollzogen werden. Der Aufbau des Headers innerhalb der RTP-Pakete sollte sich nach dem RFC 3550 richten. Außerdem muss der Payload dem RFC 2435 entsprechen, da es sich hierbei um ein JPEG-komprimiertes Video handelt. Einzelheiten werden in Punkt 4.3.1. näher beleuchtet.

Die Funktion einer Fehlerkorrektur durch FEC wird aktuell von keiner Version des VLC-Players unterstützt. Daher beschränkt sich diese Funktionalität auf die Kommunikation zwischen den angefertigten Modulen.

28

4.2.2. Client

Die Analyse des Clients begann mit den RTSP Methoden im Client. Die RTSP-Methoden wurden auf Vollständigkeit und Konformität geprüft. Hier ergab sich, dass alle bisher implementierten Methoden nur oberflächlich eingepflegt wurden und eine Describe-Anfrage bisher nicht berücksichtigt wurde. Auch der Parser muss überarbeitet werden, sodass auch komplexe Antworten (zum Beispiel Describe) komplett empfangen und wichtige Details herausgefiltert werden können. Im Beleg war es lediglich möglich die Sitzungsnummer auszulesen.

Da der Client nach der Implementierung des MJPEG-Codecs nur noch Frameabschnitte erhalten würde anstatt ganzer Bilder, musste der Empfangsprozess besonders überarbeitet werden. Der Einsatz eines Threads wurde notwendig, da nun nichtmehr ein Paket alle 40 Millisekunden zu erwarten war, sondern je nach Framegröße mehrere Pakete. Auch die Sequenznummern starten nun gemäß RFC 3550 nicht mehr mit null, sondern mit einer zufälligen Zahl. Zudem beschränkt sich der Zahlenraum aufgrund der 16 Bit, die diesem Parameter im RTP-Header zur Verfügung stehen, auf eine Zahl zwischen null und 65535. Dies muss bei größeren Videos berücksichtigt werden, da hier mehr als 65535 Pakete versendet werden und die Sequenznummer des nächsten Paketes dann wieder bei null starten wird. Die Einordnung der Pakete in den Puffer erfordert somit ebenfalls eine Anpassung.

Auch die Wiedergabe musste bearbeitet werden, da die empfangenen Abschnitte zunächst wieder zu einem Frame zusammengefügt werden müssen. Zudem muss die Abspielgeschwindigkeit durch den Zeitstempel der RTP-Pakete bestimmt werden.

Die grafische Benutzeroberfläche bedurfte auch einiger Änderungen, vor allem um auf unterschiedliche Videoauflösungen reagieren zu können, da die Oberfläche vorher auf die Größe des Beispielvideos festgelegt war. Zudem muss ein Button für die Describe-Methode angelegt werden. Im gleichen Zug kann die Oberfläche so angepasst werden, dass nun alle Buttons vollständig angezeigt werden, was wie in Abbildung II-19 zu sehen ist vorher nicht der Fall war.

4.2.3. Server

Die RTSP-Methoden im Server werden ebenfalls überarbeitet, da auch hier die Implementation nur beispielhaft stattfand. Die Describe-Methode fehlt ebenfalls noch und auch der Parser muss an die überarbeiteten Methoden angepasst werden. Der Timer für den Sendeprozess muss durch einen Thread ersetzt werden, da nun nichtmehr nur ein Frame alle 40 Millisekunden versendet wird, sondern je nach Framegröße unterschiedlich viele Pakete versendet werden müssen.

29

Sitzungsnummer, Zeitstempel und die erste Sequenznummer müssen gemäß RFC 3550 zufällig erzeugt werden, zudem dürfen die Sequenznummern maximal bis 65535 gehen und müssen dann wieder mit null beginnen. Die Variable Ssrc (Synchronization source) darf auch nicht länger null sein, der Wert muss vom Server zufällig bestimmt und der Klasse RTPpacket übergeben werden. In dieser Klasse ergeben sich somit auch entsprechende Anpassungen.

Die Klasse FECpacket wurde ebenfalls überprüft. Da sich die Bildung der Pakete aber bereits vollständig nach dem RFC 5109 richtet, sind hier keine Änderungen notwendig.

Zudem sollten wesentliche Fehlercodes hinzugefügt werden, damit falsche Anfragen nicht in einem Serverabsturz enden.

4.2.4. MJPEG

Das Modul VideoStream muss verändert werden, so dass die einzelnen Frames nicht länger anhand der gegebenen Framegrößen herausgesucht werden, sondern anhand der spezifischen Marker, die jedes Frame enthält, um auch andere MJPEGs übertragen zu können.

Zudem wird ein weiteres Modul benötigt, um aus einem kompletten MJPEG-Frame Fragmente zu erstellen und diese in das RTP JPEG Payload Format zu bringen. Dies ist nötig, da JPEG Frames normalerweise größer sind als die maximale Paketgröße in der verwendeten Netzwerkschicht. Eine Fragmentierung ist zwar auch durch eine darunterliegende Netzwerkschicht wie zum Beispiel IP möglich, allerdings bringt dies auch einige Einschränkungen mit sich. Mehr Informationen hierzu finden sich in der Arbeit „Fragmentation Considered Harmful“ von C. Kent und J. Mogul von 1987. Um diese Einschränkungen zu vermeiden, definiert das RFC 2435 eine Fragmentierung auf RTP Ebene. [5]

4.3. Entwurf und Implementierung

Der folgende Abschnitt beinhaltet die Antworten auf die in der Analyse aufgestellten Fragen. Zudem wird aufgezeigt wie die vorgeschlagenen Änderungen an den Klassen umgesetzt beziehungsweise implementiert wurden. Des Weiteren soll durch die aufgestellten Diagramme der Programmaufbau näher gebracht werden.

30

4.3.1. MJPEG

Hier sollen zunächst die Klassen beschrieben werden, welche zur Bearbeitung des MJPEG-Videos benötigt werden.

Die Klasse VideoStream, zu sehen in Abbildung IV-3, wird um die Funktion getframesize() erweitert. Diese wird benötigt um die Positionen der SOI und EOI Marker aus dem Video zu extrahieren. Das Video wird dazu in Blöcken a 50.000 Byte eingelesen und nach den Markern durchsucht.

Abbildung IV-3 Klassendiagramm VideoStream

Die Positionen dieser Marker werden jeweils in einer Liste vermerkt. Bekommt die Klasse VideoStream nun durch den Server ein Video übergeben, wird die Funktion getframesize() einmalig aufgerufen und anhand der Markerpositionen können die einzelnen Frames ausgelesen und ausgegeben werden.

Da für die Fragmentierung der Frames, gemäß RFC 2435, eine neue Klasse benötigt wird, wurde die Klasse MJPEGpacketize erstellt. Die Klasse hat die Aufgabe bestehende Frames zu fragmentieren und in das RTP-Payload-Format für JPEG komprimierte Videos zu bringen. Außerdem ist die Klasse auch für den umgekehrten Weg verantwortlich, nämlich um aus übermittelten Fragmenten wieder komplette Frames herzustellen. Die Implementierung der beiden Funktionen MJPEGpacketize und buildImage, zu sehen in Abbildung IV-4, orientieren sich sowohl am RFC 2435 Appendix B und C, als auch an der Implementierung des VLC-Players für den JPEG-Codec.

Abbildung IV-4 Klassendiagramm von MJPEGpacketize

Der Funktion MJPEGpacketize, dem Konstruktor der Klasse, wird zunächst ein Frame übergeben, um daraus den Payload für ein RTP-Paket zu bilden. Dazu sucht sie nach

31

den in Abschnitt 3.2. benannten Markern. Wichtig für den Transport sind die Marker DQT, SOF, DRI und SOS, gemäß RFC 2435. Hierfür liest die Funktion zunächst die ersten zwei Byte des Frames und vergleicht diese mit den genannten Markern. Wird ein Marker gefunden, werden die Daten aus dem Markersegment entsprechend gespeichert. Durch den Längenindikator, welcher in jedem Markersegment vorhanden ist, weiß die Funktion nun wie viele Bytes übersprungen werden müssen, um zum nächsten Marker zu gelangen. Dies geschieht so lange, bis der SOS Marker gefunden wird. Da auf diesen Marker die MCUs folgen, wird die Suche abgeschlossen und der JPEG-Header kann aufgrund der abgespeicherten Informationen erstellt werden.

In Abbildung IV-5 ist zu sehen, wie aus den gefundenen Headerdaten der JPEG-Header, gegebenenfalls der Restart-Marker-Header und der Quantisierungstabellen-Header gebildet werden.

32

Abbildung IV-5 Bildung der JPEG-Headerdaten aus den im vorhergehenden Schritt gefundenen Markersegmenten

Es folgen die Nutzdaten des Frames. Dazu werden die Bilddaten in maximal 1400 Byte große Abschnitte geteilt und an den Header gehangen. Ist ein Payload fertig, wird er in einer Arrayliste gespeichert und der nächste Abschnitt wird wiederrum mit dem Header verknüpft. Dieser unterscheidet sich zu seinem Vorgänger nur durch das gestiegene Offset im JPEG-Header. Wurde der gesamte Frame zerlegt, kann die Liste durch den Aufrufer, also den Server eingesehen und weiterverarbeitet werden.

33

Die zweite wesentliche Funktion der Klasse ist buildImage. Sie erhält eine Liste mit RTP-Paketen die zum selben Frame gehören und muss daraus den Frame rekonstruieren.

Um die JPEG-Header-Daten zu bauen, reicht es aus, die Header-Daten des ersten Paketes auszuwerten. Das Bild beginnt mit dem SOI Marker, gefolgt von der Huffmantabelle. Diese ist für jedes JPEG gleich, weshalb sie auch nicht übertragen werden muss. Es folgen der Quantisierungstabellen-Header, Start-of-frame- Header, DRI- und Start-of-scan-Header. Schließlich werden noch die Bilddaten aller Pakete hinzugefügt und das JPEG ist komplett.

Die beiden Klassen, VideoStream und MJPEGpacketize, arbeiten hauptsächlich auf Byte-Ebene. Hierfür wurden verschiedene Funktionen zur Typkonvertierung und eine Funktion für die Suche nach Bytearrays geschaffen, wie in Abbildung IV-6 zu sehen ist. Diese werden unter anderem benötigt um nach Markern suchen zu können. Die Klasse ByteTasks wurde erstellt, damit diese Funktionen nicht mehrmals für die jeweiligen Klassen implementiert werden müssen, da auch die Klasse RTPpacket auf diese Funktionen zurückgreift.

Abbildung IV-6 Klassendiagramm ByteTasks

34

4.3.2. Client

Die Klasse Client, zu sehen in Abbildung IV-7, wurde umfangreich überarbeitet.

Abbildung IV-7 Klassendiagramm Client

Die eingepflegten RTSP-Methoden wurden ergänzt, um dem RFC 2326 zu entsprechen. Die Methode Describe, welche für die Kommunikation zum VLC Player zwingend notwendig ist, wurde wie in Abbildung IV-8 dargestellt hinzugefügt.

Abbildung IV-8 Implementierung der Methode Describe

Der Parser erkennt nun auch Fehlercodes und kann diese ausgeben. Zudem werden jetzt zusätzlich Ssrc, die URL des Videostreams, Abspieldauer, die Sequenznummer des ersten Paketes und der Payloadtyp erkannt.

Der Timer für den Empfangsprozess wurde, wie in Abschnitt 4.2.2. schon erwähnt, durch einen Thread ersetzt. Dieser startet bei einer positiven Antwort auf die Methode Play und wartet dann auf ankommende Pakete. Der Thread kann durch Methode Pause pausiert werden. Beendet wird er entweder durch Teardown mit dem Rest des Programms oder wenn zehn Sekunden lang keine Pakete eintreffen, die Verbindung also entweder zu schlecht ist oder die Übertragung beendet wurde.

35

Die Einordnung der Pakete wurde an so den begrenzten Zahlenraum angepasst, dass auch Pakete richtig eingeordnet werden, die verspätet beim Client eintreffen. Zudem ist die Position der Pakete im Puffer nicht mehr abhängig von ihrer Sequenznummer, da diese nun gemäß RFC 3550 mit einem zufälligen Wert beginnen.

Die Wiedergabe startet drei Sekunden nachdem das erste Paket empfangen wurde und wird nach wie vor durch einen Timer gesteuert, dessen Verzögerung aber nun durch den Zeitstempel der Pakete geändert werden kann. Zudem werden erst in der Wiedergabefunktion die einzelnen Pakete zu einem kompletten Frame zusammengesetzt. Dazu werden alle Pakete mit dem gleichem Zeitstempel aus dem Puffer geholt. Anhand von Offset und den Sequenznummern wird untersucht, ob alle Pakete vorhanden sind. Fehlt ein Paket, so wird der Frame verworfen, da das Bild nicht komplett rekonstruiert werden kann.

Sind alle Pakete vorhanden, werden sie der Klasse MJPEGpacketize übergeben. Das Ergebnis ist ein JPEG, welches dargestellt werden kann.

Weiterhin wurde die graphische Oberfläche entsprechend der Analyse angepasst:

Abbildung IV-9 Graphische Oberfläche des überarbeiteten Clients

Es werden jetzt alle Buttons vollständig angezeigt und ein Button für die Describe Anfrage wurde hinzugefügt. Zudem reagiert die Oberfläche nun dynamisch auf die Auflösung des Videos.

4.3.3. Server

Auch der Server wurde komplett überarbeitet. Wie in Abbildung IV-10 zu sehen ist, startet der Server den Thread SendThread, welcher dann für den Streamingprozess verantwortlich ist.

36

Abbildung IV-10 Klassendiagramm Server

Die RTSP Methoden des Servers wurden komplett überarbeitet und ergänzt, um dem RFC 2326 zu entsprechen und somit mit dem VLC-Player interagieren zu können. Zudem wurden einige Fehlercodes hinzugefügt um unbestimmte Zustände sowie möglicherweise auftretende Serverabstürze zu vermeiden. Durch die Setup Methode werden nun Sitzungsnummer, der Zeitstempel, Ssrc und die Sequenznummer für das erste RTP-Paket zufällig erstellt, in Übereinstimmung mit dem RFC 2326. Desweiteren wurde, wie in Abbildung IV-11 dargestellt, die Methode Describe nun ergänzt.

Abbildung IV-11 Implementierung der Methode Describe

Auch der Parser wurde an die überarbeiteten Methoden angepasst. Unter anderem wird nun geprüft, ob die übertragenen Methoden auch zur aktuellen Sitzung gehören.

37

Der Timer für den Sendeprozess wurde zugunsten eines Threads ersetzt. Der Prozess erhält nun zunächst einen Frame durch eine Anfrage an die Klasse VideoStream und gibt diesen Frame an die Klasse MJPEGpacketize weiter, wo dieser in kleine Pakete fragmentiert wird. Jedes dieser Pakete wird zu einem RTP-Paket zusammengefügt und dann an den Client versendet. Wurden alle Pakete eines Frames abgeschickt, wartet der Prozess 40 Millisekunden, erhöht den Zeitstempel entsprechend und macht dann mit dem nächsten Frame weiter. Um RTP-Pakete zu erstellen, wurde die Klasse RTPpacket leicht angepasst. Der Klasse werden nun Ssrc und der Wert für den Marker im RTP-Header übergeben. Der Wert für den Marker wurde durch die Fragmentierung der Pakete notwendig. Entspricht der Wert einer eins, so weiß der Client, dass es sich um das letzte Paket eines Frames handelt.

4.4. Test

„Unter Testen versteht man den Prozess des Planens, der Vorbereitung und der Messung, mit dem Ziel, die Eigenschaften eines IT-Systems festzustellen und den Unterschied zwischen dem tatsächlichen und dem erforderlichen Zustand aufzuzeigen.“ [19, S. 9]

Tests wurden durchgeführt um die implementierten Methoden zu überprüfen, Fehler zu finden und diese zu berichtigen. Im Vordergrund standen Zuverlässigkeit und Funktionalität, aber auch die Portabilität wurde betrachtet.

Die Tests wurden lokal und im lokalen Netzwerk, sowohl unter Linux als auch unter Windows durchgeführt. Betrachtet wurde in erster Linie das Verhalten zwischen VLC-Player und der eigenen Implementation. Aber auch die Kommunikation zwischen den erstellten Modulen wurde kontrolliert.

Getestet wurde mit dem Praktikumsvideo movie.mjpeg einem weiteren Video im MJPEG Format, sowie mit zwei Videos, welche in den Formaten AVI und QuickTime Movie vorlagen. Beides sind Video-Containerformate, die bei den gewählten Videos den Videocodec MJPEG nutzen. Da der Audiostream getrennt übertragen wird, kann dieser bei der Übertragung ignoriert werden. Beide Videos können nur vom VLC-Player als Stream bereitgestellt werden, da das Projekt selbst keine Containerformate verarbeiten kann.

38

4.4.1. Fehler und ihre Ursachen

Zunächst fiel auf, dass das Praktikumsvideo weder vom VLC-Player gestreamt noch korrekt empfangen und wiedergegeben werden kann. Dies liegt an der Beschränkung der Farbunterabtastformate durch das RFC 2435. Das Video movie.mjpeg liegt im Format 4:4:4 vor. Dadurch kann das Video vom VLC-Player zwar abgespielt werden, aber bei der Zerlegung des Streams in RTP-Pakete kommt es zum Fehler und die Videodaten werden nicht übertragen. Auch Empfangen kann der VLC-Player das Video zwar, aber nicht korrekt wiedergeben. Intern wurde das Problem so gelöst, dass für das Format 4:4:4 der Typ 130 festgelegt wurde, was nach dem RFC 2435 möglich ist: „Types 128-255 are free to be dynamically defined by a session setup protocol […].” [5, S. 5]. Durch diese Anpassung wird ein Byte im Start-of-frame-Header verändert und das Bild kann korrekt dargestellt werden.

Durch die Statistik am Client wurde schnell deutlich, dass beim Client-Modul unter Windows deutlich mehr Pakete verloren gingen als unter Linux. Teilweise gingen unter Windows ca. 0,6 Pakete pro Sekunde verloren, während es, beim Einsatz des gleichen Servers, unter Linux lediglich 0,03 Paketverluste pro Sekunde gab. Da diese Verluste auch lokal auftraten, kam als Ursache nur ein Fehler in Frage der durch Java selbst verursacht wurde. Nach Inspektion des Sockets kam die Größe des TCP-Stacks in Frage. Während ein Datagram-Socket unter Windows mit einen 8192 Byte großen TCP-Stack initialisiert wird, erhält der Socket unter Linux 81920 Byte. Nach Anpassung des Wertes unter Windows konnte die Ursache bestätigt werden. Durch die geringe Größe des TCP-Stacks unter Windows kam es zum Überlauf und die Pakete gingen verloren.

39

V. Ausblicke

Dieses Kapitel soll einen kurzen Ausblick über die Entwicklung eines FEC-Schutzes für den VLC-Player geben. Zudem werden Möglichkeiten genannt, wie das im Rahmen dieser Arbeit erstellte Programm erweitert werden kann.

5.1. VLC und FEC

Wie schon erwähnt, gibt es für den VLC-Player aktuell keine Implementierung für das Feature FEC. Da FEC aber gerade im Bereich des Streamings sehr wertvoll sein kann, soll an dieser Stelle noch ein Ausblick folgen.

Die Idee VLC mit FEC zu erweitern gibt es schon seit längerem, unter anderem beschäftigte sich im Februar 2011 Andreas Staudt in seiner Bachelorarbeit mit dem Thema „Erweiterung von VLC um Forward Error Correction (FEC)“.

„Als Standard für die Umsetzung wurde das RFC 6015 verwendet, das ein dynamisches RTP Payload Format definiert, mit dem Korrekturdaten auf einem eigenen Stream transportiert werden. Für die Gewinnung der Redundanz werden die RTP Pakete der Medienströme mit exclusive-OR verknüpft. Durch ein zusätzliches Interleaving dieser Verknüpfungen werden nicht nur gleichverteilte Datenverluste, sondern auch die bei drahtlosen Netzwerken häufig beobachteten Burstverluste abgedeckt.“ [20]

Diese Implementation wurde damals allerdings für den VLC 1.0 geschrieben und ist mit der heutigen Version nicht mehr kompatibel. Eine Anpassung des Codes hätte den Umfang dieser Arbeit gesprengt, da der gesamte Code mit ca. 2000 Zeilen Umfang überarbeitet und an die neuen Module angepasst werden müsste.

Auch VideoLan hat den Nutzen von FEC erkannt und bietet für eine Implementierung eine Belohnung von 2000 €. [21]

5.2. Weiterentwicklung

Das im Rahmen dieser Arbeit vorgestellte Projekt dient in erster Linie der Lehre und der Demonstration des RTSP-Videostreamings. Es soll ein Grundgerüst für weiterführende Implementierungen darstellen. Eine sinnvolle Weiterentwicklung wäre vor allem die Erweiterung der Module um eine Audiowiedergabe. Somit könnten Containerformate, die auf MJPEG aufbauen, samt Ton abgespielt werden. Aber auch eine Erweiterung um andere Videocodecs wäre denkbar.

40

Zudem können mit relativ wenig Aufwand weitere RTSP Methoden, wie Announce oder Get_Parameter realisiert werden. Ebenso käme die Unterstützung des Servers mehrerer Clients in Frage oder die Weiterentwicklung der Fehlerkorrektur mit FEC, etwa durch ein Interleaving.

41

VI. Zusammenfassung

Für den MJPEG Codec konnte durch die Zuhilfenahme der Entwürfe von Microsoft und Apple, sowie des ISO Standards 10918-1, ein einheitliches Format gefunden werden. Durch die Beschränkung auf ein MJPEG-Format welches via RTP versendet werden kann, konnten die spezifischen Standards weiter limitiert werden. Die verwendeten Marker wurden auf die Wesentlichen (SOI, DHT, DQT, DRI, SOF, SOS, EOI) beschränkt und auch die Reihenfolge in welcher diese auftreten wurde begrenzt. Zudem kommt für die Kodierung der einzelnen MJPEG-Frames nur noch der Baseline-Prozess in Frage. Des Weiteren wurden die Farbtiefe auf 8 Bits und die Farbunterabtastung auf die Formate 4:2:0 und 4:2:2 beschränkt.

Durch die Anpassung und Ergänzung der Client- und Servermodule an die Standards der Protokolle RTSP und RTP können nun Videos im MJPEG-Format zwischen dem Streamingclient und –server und dem VLC-Player ausgetauscht werden. Der MJPEG-Codec wurde entsprechend der Analyse implementiert und die einzelnen JPEG-Bilder des Videos werden gemäß RFC 2435 fragmentiert und versendet. Zudem wurden die Parser an die überarbeiteten RTSP-Methoden angepasst und erweitert. Dadurch können detailliertere Informationen aus den einzelnen Methoden gewonnen und für den Streamingprozess genutzt werden.

Eine Demonstration der Fehlerkorrektur durch FEC zwischen den Modulen und dem VLC-Player konnte aufgrund der fehlenden Implementation im VLC-Player nicht erreicht werden. Allerdings ist diese Funktionalität nach wie vor zwischen dem Client- und dem Servermodul möglich.

Die Funktionsweise des RTSP wird durch die Ausgabe der Methoden-Anfragen und –Antworten durch die Module deutlich. Auch der Erhalt der einzelnen RTP-Pakete wird dem User angezeigt.

42

Literaturverzeichnis

[1] H. Schulzrinne, A. Rao, R. Lanphier: Real Time Streaming Protocol (RTSP), RFC 2326 (Proposed Standard), Internet Engineering Task Force, April 1998, Adresse: https://tools.ietf.org/html/rfc2326.

[2] J. F. Kurose, K. W. Ross: Computernetzwerke, Pearson Deutschland GmbH, 2008.

[3] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson: RTP: A Transport Protocol for Real-Time Applications, RFC 3550 (Internet Standard), Internet Engineering Task Force, Juli 2003, Adresse: http://tools.ietf.org/html/rfc3550.

[4] U. Trick, F. Weber: SIP, TCP/IP und Telekommunikationsnetze: Anforderungen - Protokolle – Architekturen, Oldenbourg Verlag, 2004.

[5] L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart: RTP Payload Format for JPEG-compressed Video, RFC 2435 (Proposed Standard), Internet Engineering Task Force, Oktober 1998. Adresse: http://tools.ietf.org/html/rfc2435.

[6] W. B. Pennebaker, J. L. Mitchell: JPEG: Still Image Data Compression Standard, Springer Science & Business Media, 1993 (siehe S. 120).

[7] A. Li: RTP Payload Format for Generic Forward Error Correction, RFC 5109 (Proposed Standard), Internet Engineering Task Force, Dezember 2007, Adresse: https://tools.ietf.org/html/rfc5109.

[8] J. Vogt: Internettechnologien 2, FEC-Einführung, Hochschule für Technik und Wirtschaft Dresden, Adresse: http://www2.htw-dresden.de/~jvogt/it2/it2-20-fec-einfuehrung_print.pdf.

[9] R. Schmitz, R. Kiefer, J. Maucher, J. Schulze, T. Suchy: Kompendium Medieninformatik, Mediennetze, Springer-Verlag Berlin Heidelberg, 2006.

[10] Apple Developer, QuickTime File Format Specification, Apple Inc., 2004, Adresse: https://developer.apple.com/library/mac/documentation/QuickTime/ QTFF/qtff.pdf.

[11] OpenDML AVI M-JPEG File Format Subcommittee, OpenDML AVI File Format Extensions, Version 1.02, 1996, Adresse: http://www.the-labs.com/Video/odmlff2-avidef.pdf.

43

[12] JPEG - Joint Photographic Experts Group: Information Technology – Digital Compression and Coding of Continuous-tone Still images – Requirements and guidelines, CCITT Recommendation T.81 (ISO/IEC International Standard 10918-1), 1992.

[13] T. Strutz: Bilddatenkompression, Vieweg+Teubner Verlag, 2005.

[14] T. Becker, S. Peukert, p. Roos: Bildkompression mit JPEG, August 2005, Adresse: http://www.numerik.mathematik.uni-mainz.de/EModule/jpeg/pages/ node9.htm, Abgerufen am 07. April 2015.

[15] M. Stirner: JPEG – Das Bildformat Teil 1: Theorie und Grundlagen, 2011, Adresse: http://www.burosch.de/technische-informationen/339-jpeg-das-bildformat-teil-1-theorie-und-grundlagen.html, Abgerufen am 05. April 2015.

[16] S. Manz: Development and Implementation of an MotionJPEG Capable JPEG Decoder in Hardware, Heidelberg Universität, Diplomarbeit, 2008, Adresse: http://opencores.org/websvn,filedetails?repname=mjpeg-decoder&path=%2Fmjpeg-decoder%2Ftrunk%2Fmjpeg.pdf, S. 13.

[17] R. Steinmetz: Multimedia-Technologie: Grundlagen, Komponenten und Systeme, Springer-Verlag Berlin Heidelberg, 1999 (siehe S. 131ff).

[18] R. Biebeler: Codecfibel, Fachverlag Schiele & Schoen, 2007, S.27. [19] M. Pol, T. Koomen, A. Spillner: Management und Optimierung des

Testprozesses. Ein praktischer Leitfaden für erfolgreiches Testen von Software mit TPI und TMap, dpunkt.Verlag, Heidelberg, 2002, S. 9.

[20] A. Staudt: Erweiterung von VLC um Forward Error Correction (FEC), Karlsruher Institut für Technologie, Institut für Telematik, Bachelor-Arbeit, 2011, Adresse: https://telematics.tm.kit.edu/staff_1882.php.

[21] Anonym, Bounties, Adresse: https://wiki.videolan.org/Bounties/#Add_RTP_ with_FEC, Abgerufen am 13. April 2015.

44

Eidesstattliche Erklärung

„Ich versichere, dass ich die Diplomarbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.

Ferner gestatte ich der Hochschule für Technik und Wirtschaft Dresden (FH), die vorliegende Diplomarbeit unter Beachtung insbesondere datenschutz- und wettbewerbsrechtlicher Vorschriften für Lehre und Forschung zu nutzen.“

Dresden, 21. April 2015 Karsten Pohl