Videodatenübertragung: Streaming

Die Entwicklung des digitalen Fernsehens wird im Kontext des European Digital Video Broadcasting Projects beleuchtet. Beginnend in den frühen 90er Jahren, wurden erste Konzepte entwickelt, um das analoge Fernsehen durch digitale Übertragungstechniken zu ersetzen. Anfang der 90er Jahre entstanden erste Ideen, das klassische analoge Fernsehen durch digitales Fernsehen abzulösen, vorrangig aufgrund der verschiedenen Entwicklungen in den USA, Japan und Europa. Die Fortschritte in der digitalen Signalverarbeitung, leistungsfähigere Mikrorechner und neue Komprimierungsverfahren waren treibende Kräfte hinter diesem Wandel. Als bedeutender Meilenstein gilt der Start des European Digital Video Broadcasting Project am 10. September 1993. Das Ziel war die Entwicklung eines einheitlichen Standards, der sowohl kommerzielle als auch technische Interessen berücksichtigt. Das Projekt vereint Mitglieder von Unternehmen und Organisationen wie Rundfunk- und Fernsehsender, Kabel- und Satellitenbetreiber, Behörden und die Europäische Kommission. Die Entwicklung zielte auf einen gemeinsamen Standard für alle Beteiligten ab, um Synergien zu schaffen und den Übergang zum digitalen Fernsehen zu vereinfachen.

Eine entscheidende Wahl des European DVB-Projekts war die Festlegung von MPEG-2 als Komprimierungsstandard. MPEG-2 wurde sowohl für die Quellenkodierung von Audio- und Videodaten als auch für die MPEG-2-Systemtechnologie zur Erzeugung unterschiedlicher MPEG-2-Stream-Typen ausgewählt. Allerdings musste der Original-MPEG-2-Standard aufgrund seiner Komplexität und um ökonomische Implementierungen zu ermöglichen, eingeschränkt werden. Die Syntax und Parameter wurden an die spezifischen Bedürfnisse des DVB angepasst. Die Richtlinien und Vorgehensweisen hierfür sind im Guidelines Document dokumentiert. Der Fokus lag darauf, einen praktikablen und kosteneffizienten Standard zu schaffen, der die Anforderungen des digitalen Fernsehens erfüllt. Dies beinhaltete die Definition spezifischer Parameter und die Vereinfachung der Syntax des MPEG-2 Standards, um eine effiziente Implementierung zu gewährleisten. Der Transportstrom (TS) als Ergebnis des Multiplexprozesses wird detailliert beschrieben. Er bündelt PESs und Zeitbasen in einem einzigen Strom, der für verlustbehaftete oder verrauschte Übertragungsmedien optimiert ist. Ein MPEG-2 TS-Paket ist 188 Byte lang und besteht aus Header, Adaption Field und Payload. Obwohl die einzelnen kodierten Videostreams unterschiedliche Bandbreiten benötigen, weist der resultierende Transportstrom eine konstante Bandbreite auf.

Die Arbeit untersucht verschiedene Netzwerktopologien im Kontext der Videodatenverteilung. Die Ring-Topologie, insbesondere im Zusammenhang mit Glasfaser-Netzen (FDDI), wird erwähnt, mit einer Kapazität von bis zu 1000 Rechnerstationen und einer Reichweite von etwa 200km. Jedoch wird der Fokus auf lokale Netzwerke im privaten Haushalt gelegt, wobei die Stern-Topologie als geeignete Lösung für die Verteilung von Videodaten an bis zu fünf Clients identifiziert wird. Die Vorteile einer lokalen Vernetzung, wie die gemeinsame Nutzung von Hardware-Ressourcen und die vereinfachte Wartung, werden hervorgehoben. Gleichzeitig werden die erhöhte Systemkomplexität und die Kosten für die Netzwerkhardware als Nachteile erwähnt. Die persönliche Videoarchivierung mit Formaten wie MPEG-1 oder MPEG-2 wird als ein weiterer Grund für die sinnvolle Einrichtung eines zentralen Servers im Haushalt beschrieben. Der Zugriff auf eine komplette Sammlung von Video- und Audioobjekten von verschiedenen Stellen aus wird als Vorteil gegenüber dem Transport von Speichermedien hervorgehoben.

Ein kritischer Punkt ist die Qualität der Dienstleistung (QoS) für die Echtzeitübertragung von Videodaten. Verzögerungen sind kritisch, da Videobilder mit 25 Bildern pro Sekunde dargestellt werden müssen. Schwankungen der Verzögerungszeiten (Jitter) sind unerwünscht. Kommunikationsnetze sind fehleranfällig; Bitfehler oder Paketverluste wirken sich besonders negativ auf komprimierte Videosignale aus, da diese bereits räumliche und zeitliche Redundanz entfernt haben. Die vom Übertragungsnetzwerk bereitgestellte Leistung wird durch verschiedene QoS-Parameter bestimmt: garantierte Mindestdatenrate, maximale Verzögerungszeit, maximale Verlustrate (Bitfehlerrate) und Jitter. Viele Netzwerke garantieren keine konstanten QoS-Parameter, daher ist eine Untersuchung der QoS-Anforderungen für kodierte Videosignale unerlässlich, um eine zuverlässige und effektive Videoübertragung über ein lokales Netzwerk zu gewährleisten. Die Anforderungen an die Rechenleistung und die Eigenschaften der Übertragungsnetze für die digitale Echtzeitübertragung von Audio- und Videodaten werden als bisher nicht dagewesen beschrieben. Digitales Video stellt die höchsten Ansprüche an die Übertragung: hohe Bandbreite, minimale Verzögerung und niedrige Fehlerrate sind erforderlich.

Die Eignung verschiedener Übertragungsmedien für die Videodatenverteilung wird analysiert. Ein Telefonnetzwerk wird aufgrund der damit verbundenen Einschränkungen ausgeschlossen. Kupfer-Koaxialkabel für Kabel-TV werden als weiterer Übertragungsweg betrachtet, jedoch weist dieser die Limitation auf, dass er noch nicht rückkanaltauglich ist. Das bedeutet, dass für Steuerungsinformationen alternative Wege, wie herkömmliche Telefon- oder Funkverbindungen, gefunden werden müssen. Die Datenrate ist auf maximal 16 Mbit/s begrenzt. Funkübertragungen werden ebenfalls als problematisch eingestuft, da sie keinen definierten Schutz vor Störungen bieten. Störstrahlung und Wechselwirkungen mit anderen Funkdiensten stellen erhebliche Herausforderungen dar. Die Übertragungseffizienz ist durch die geringe Sendeleistung, Dämpfungseinflüsse und Mehrwegausbreitung begrenzt. Hindernisse wie Wände und Möbel beeinflussen die Übertragung negativ, wobei dieser Einfluss mit der Betriebsfrequenz zunimmt. Diese Analyse zeigt deutlich die Vorteile eines lokalen Netzwerks.

Die Arbeit argumentiert für Streaming als geeignete Methode zur Verteilung von Videodaten. Streaming ermöglicht die Echtzeitübertragung multimedialer Inhalte über ein Netzwerk von einem Server zu einem oder mehreren Clients. Der Videoserver liest die Daten von seiner Festplatte und überträgt sie über ein Netzwerkprotokoll zum Videoplayer des Empfängers. Der Vorteil liegt darin, dass der gesamte Inhalt nicht komplett auf den Client kopiert werden muss, sondern direkt während des Abspielvorgangs übertragen wird. Bereits abgespielte Datenabschnitte können nach ihrer Nutzung gelöscht werden. Für das DVP-System wird Video-on-Demand (VoD) als relevante Anwendung des Streamings betrachtet. VoD ermöglicht es dem Nutzer, einen laufenden Datenstrom anzufordern und den Inhalt zu konsumieren, ggf. sogar mit der Wahl des Startzeitpunkts der Übertragung. Die Hardware-Ressourcen des Videoservers (I/O-Kapazität und Netzwerkbandbreite) begrenzen die Anzahl gleichzeitig abspielbarer Datenströme, die nach verschiedenen Algorithmen (Unicast, Multicast, Broadcast) verteilt werden müssen. Unicast wird als ideale Verbindungsart für Video-on-Demand-Zwecke identifiziert.

Für ein effektives Streaming-System sind hohe Qualität des Inhalts, wenige Aussetzer beim Empfänger und eine geringe Verzögerung zwischen Senden und Abspielen entscheidend. Die Übertragungszeit sollte möglichst gering sein. Datenströme werden in Pakete unterteilt, wobei die Möglichkeit besteht, dass diese in falscher Reihenfolge beim Empfänger ankommen (Jumbling). Für Echtzeitübertragungen ist eine schnelle Reorganisation der Pakete notwendig. Die Arbeit untersucht die Verwendung von UDP und TCP für die Datenübertragung. UDP als verbindungsloses Protokoll bietet eine schnelle Übertragung, garantiert aber nicht die richtige Reihenfolge der Pakete und ignoriert verlorene Pakete. Trotzdem ist eine kontinuierliche Wiedergabe auch bei Paketverlust möglich. Das Real-time Transport Protocol (RTP) wird als Protokoll für die eigentliche Übertragung von Video- und Audiodaten vorgestellt. Als Protokoll der Anwendungsschicht ist es auf ein Transportprotokoll wie UDP angewiesen. RTP typisiert ankommende Daten, nummeriert Pakete beim Versand und ermöglicht so dem Decoder die korrekte Rekonstruktion der Datenreihenfolge. RTP bietet jedoch keine Möglichkeiten zur Ressourcenreservierung oder QoS-Kontrolle.

Das Digitale Video Projekt (DVP) verwendet eine Client/Server-Architektur für die Videodatenverteilung. Der Server, ein leistungsstarker PC, ist das Herzstück des Systems. Die Hardware-Anforderungen umfassen einen Pentium 4 Prozessor mit 1,5 GHz, 512 MB Hauptspeicher und eine 40 GB Festplatte zur Speicherung der Videodaten. Eine 100 Mbit Ethernet-Karte stellt die Netzwerkverbindung sicher. Zwei DVB-Karten der Marke TechnoTrend, angesteuert durch einen Siemens DVB-Treiber, ermöglichen die Aufnahme und das Streaming von DVB-Signalen. Eine der Karten verfügt über einen TV-Ausgang. Die VideoLAN Software wird als Streaminglösung eingesetzt. Der Server bietet neben dem Streaming auch Nutzer- und Datenverwaltung. Die Konfiguration des VideoLAN Servers, die für diese Arbeit relevant ist, befindet sich im Anhang A. Diese Architektur gewährleistet die Bereitstellung von Videodaten für mehrere Clients gleichzeitig, die im Haushalt über das Netzwerk darauf zugreifen.

Die Client-PCs im DVP-System sollen benutzerfreundlich sein und dem Design einer Set-Top-Box ähneln. Die Installation und Bedienung sollen einfach sein, wobei die Aufgaben auf das Abspielen von Videodaten beschränkt sind. Eine aufwändige Konfiguration soll vermieden werden, z.B. durch die zukünftige Integration von DHCP für die automatische Netzwerkkonfiguration. Die Produktionskosten der Clients sollen im Vergleich zum Server gering sein. Die Hauptfunktionen der Client-PCs sind der Empfang, die Verarbeitung und die Weiterleitung des paketierten MPEG-2 Transportstroms an den Fernseher. Eine Netzwerkkarte mit einer Kapazität von maximal 4-9 Mbit/s ist ausreichend, um Überlastungen des Servers zu vermeiden und eine garantierte Datenrate für jeden Client sicherzustellen. Jeder Client ist auf einen Stream beschränkt, um die Serverleistung zu schonen. Die Client-PCs benötigen keine DVB-Karte, da der Empfang der Streams vom Server erfolgt. Zukünftig soll die automatische Erkennung der Client-PCs im Netzwerk über DHCP realisiert werden um die Administration zu vereinfachen.

Für die Datenverteilung innerhalb des Privathaushaltes wird die Stern-Topologie als optimale Netzwerkstruktur vorgeschlagen. Diese Topologie garantiert, bei einem realistischen Szenario mit bis zu fünf Clients, eine volle Datenrate. Für eine durchschnittliche Familiengröße von vier Personen wird der Einsatz von fünf Clients (Fernsehapparaten) als ausreichend erachtet. Teure Netzwerktechnik wird nicht benötigt. Um den Anforderungen gerecht zu werden, muss die Hardware des Server-PCs, insbesondere die Netzwerkkarte, für die Belastung ausgelegt sein. Die Netzwerkkarte muss bei maximal fünf Clients, die gleichzeitig einen 5 Mbit/s Videostream anfordern, einen ausreichenden Datendurchsatz gewährleisten, um einen kontinuierlichen Stream ohne Paketverluste oder Fehler zu ermöglichen. Die Wahl der Stern-Topologie vereinfacht das Netzwerkdesign und reduziert die Kosten.

Ein Kernstück der Arbeit ist die Erweiterung der VideoDiskRecorder (VDR) Software um die Funktionalität der Videodatenverteilung. Ziel ist die Integration der Steuerung dieser Verteilung direkt in die VDR-Software. Dies ermöglicht es dem Nutzer, die Videodatenverteilung bequem über die VDR-Oberfläche zu verwalten. Es wird jedoch festgestellt, dass die Verwendung der VDR-Software auf einem Client-PC ohne DVB-Karte nicht möglich ist, da das On-Screen-Display des VDRs vom DVB-Treiber und dem TV-Ausgang der DVB-Karte abhängig ist. Daher wird die Steuerung der Videodatenverteilung auf den Server-PC verlegt, wobei der Client-PC zunächst nur als Empfänger fungiert. Die VDR-Software, entwickelt von Klaus Schmidinger, ist Open-Source und frei im Internet verfügbar. Sie bietet neben den grundlegenden Aufnahmefunktionen auch Komfortfunktionen wie einen integrierten Editor für das Schneiden von Aufnahmen und die Unterstützung des elektronischen Programmführers (EPG). Optional ist sogar ein Time-Shift-Modus möglich, der aber eine zweite DVB-Karte im Server-PC erfordert.

Für die prototypische Implementierung der Videodatenverteilung wird die Open-Source Streaming-Software VideoLAN der Ecole Centrale Paris verwendet. VideoLAN erfüllt die Anforderungen an die server- und clientseitige Softwarekomponente. Die Software besteht aus einem VideoLAN Server und einem VideoLAN Client. Die Wahl fiel auf VideoLAN aufgrund seiner umfassenden Funktionalität und Kompatibilität mit dem Systemdesign. Der VideoLAN Server übernimmt die serverseitige Steuerung der Datenübertragung, einschließlich Nutzerverwaltung und Datenverwaltung. Die Clientseite wird mit dem VideoLAN Client realisiert. Die Integration von VideoLAN in die bestehende Systemarchitektur ermöglicht eine effiziente und zuverlässige Verteilung der MPEG-2 Datenpakete. Der VideoLAN Server wird zusätzlich für die Verwaltung der Clients konfiguriert, wobei die relevante Konfiguration im Anhang A zu finden ist.

Die Steuerung der Videodatenverteilung erfolgt über ein eigens entwickeltes Plugin namens 'vls', welches in die VDR Software integriert wird. Über ein On-Screen-Display (OSD) im VDR kann der Benutzer die Streams steuern. Spezielle Funktionstasten (rot, grün, gelb, blau) auf der Fernbedienung ermöglichen das Starten und Stoppen von ausgewählten Streams. Jede Aktion wird im OSD bestätigt. Ein Setup-Menü des Plugins erlaubt die Verwaltung der im VideoLAN Server konfigurierten Clients. Bestehende Clients können entfernt und neue mit IP-Adresse und Portnummer hinzugefügt werden. Auf der Clientseite wird der VideoLAN Client verwendet, der den vom Server bereitgestellten Datenstrom abspielt. Die Steuerung des VideoLAN Servers ist von der Client-Seite aus nicht möglich; der Client fungiert lediglich als Player. Eine zusätzliche grafische Benutzeroberfläche, erstellt mit Tcl/Tk, ermöglicht die clientseitige Steuerung des VideoLAN Servers über den Server-PC.