Im Video-Ökosystem ist es selten, dass konkurrierende Technologien lange Zeit friedlich koexistieren können.

Der inzwischen berühmt gewordene Krieg der Videokassettenformate in den späten 1970er und 1980er Jahren hat gezeigt, wie schnell die Branche zugunsten einer Technologie kippen kann und welche verheerenden Auswirkungen dies auf die Konkurrenz haben kann. Als die Branche 1975 kollektiv für VHS stimmte, dauerte es weniger als drei Jahre, bis diese Technologie Betamax überholte. Bei einer anschließenden Marktverschiebung zwischen 1999 und 2004 wurden die VHS-Verkäufe zunächst von der DVD überholt und dann schnell in den Schatten gestellt.

 

Von Beta über VHS zu DVD: Fallstudien darüber, wie plötzlich das Video-Ökosystem kippen kann.

Quellen: Business History Review, Nexus Research.

 

Bei den Online-Medien hat es ähnliche seismische Verschiebungen gegeben. Im Januar 2010 waren nur 10 % der Online-Videos mit dem H.264-Komprimierungsformat kodiert. Weniger als zwei Jahre später hatte sich diese Zahl auf 80 % erhöht (MeFeedia).

 

 

In jedem dieser Zeithorizonte wich die Trägheit des Marktes einer Medientechnologie, deren Zeit gekommen war. Und im Jahr 2015 nähert sich die Branche dem nächsten Punkt, an dem es kein Zurück mehr gibt.

In den letzten zehn bis zwölf Jahren sind Online-Videos für die Unterhaltung der Menschen, das Lernen von Schülern und die Kommunikation von Unternehmen unverzichtbar geworden. Es wird geschätzt, dass mehr als zwei Drittel des weltweiten Internetverkehrs von Verbrauchern bereits aus Videos besteht(Cisco) und dass große Unternehmen bereits über 14 Stunden Video pro Mitarbeiter und Monat übertragen (Gartner).

 

Der Anteil der Videos am gesamten Internetverkehr nimmt weiter zu und ist bereits jetzt dominierend. Quelle: Cisco

 

In dieser Zeit hat sich die Technologie der Medienverbreitung in vier Phasen entwickelt.

 

Die Entwicklung der Online-Medien-Streaming-Technologie

1. HTTP Download

Als Videodateien zum ersten Mal online verbreitet wurden, geschah dies über das Hypertext Transfer Protocol (HTTP) - denselben Übertragungsmechanismus, der auch für HTML-Seiten, Bilder, Dokumente und andere Arten von webbasierten Inhalten verwendet wird.

Anfänglich mussten die Videos vollständig heruntergeladen werden, bevor die Wiedergabe beginnen konnte. Dieses Verfahren, das so genannte Herunterladen und Abspielen, hatte mehrere bemerkenswerte Mängel. Erstens bedeuteten Einwahlgeschwindigkeiten von 28 bis 56 kbit/s, dass die Nutzer fast immer lange Verzögerungen bei der Wiedergabe hatten. Zweitens gab es keinen Mechanismus zur effizienten Skalierung auf mehrere gleichzeitige Betrachter. Und schließlich wurde die begrenzte Bandbreite häufig für nicht angeschaute Videosegmente verschwendet. Wenn ein Benutzer beispielsweise ein 10-minütiges Video anklickte und nur die ersten drei Minuten ansah, wurden die restlichen sieben Minuten überflüssigerweise über das Netzwerk heruntergeladen.

Apple hat einige der Probleme des HTTP-basierten Videodownloads gelöst, als es die Unterstützung für Fast Start, besser bekannt als progressiver HTTP-Download, veröffentlichte. Bei diesem Ansatz wurden wichtige Metadaten an den Anfang der Mediendatei gestellt, sodass die Videowiedergabe beginnen konnte, bevor die gesamte Datei heruntergeladen wurde. Obwohl der progressive Download auch heute noch verwendet wird, wurde er in den frühen 2000er Jahren weitgehend von benutzerdefinierten Protokollen und Servern abgelöst, die für eine neue Art der Online-Videobereitstellung, das Streaming, entwickelt wurden.

 

Der progressive HTTP-Download verbesserte die Startzeit, litt aber immer noch unter Bandbreitenverschwendung und begrenztem Umfang.

 

2. Benutzerdefinierte Streaming-Protokolle

Im Vergleich zu anderen Arten von online geteilten Inhalten sind Videodateien riesig. Eine einzige Minute iPhone-Video kann 80 bis 120 MB Speicherplatz beanspruchen. Auf demselben Speicherplatz könnten Sie zwischen 250 und 350 durchschnittlich große Word-Dokumente (Microsoft) speichern.

Diese Eigenschaft erschwerte die Verteilung von Videodateien über Netzwerke mit begrenzter Bandbreite. Mit der zunehmenden Verbreitung von Videos im Internet und in Unternehmensnetzwerken begannen Medienunternehmen und Softwareanbieter, eigene Protokolle für das Videostreaming zu entwickeln. RealNetworks und Netscape arbeiteten gemeinsam an der Entwicklung und Standardisierung des Real Time Streaming Protocol (RTSP). Adobe implementierte durch die Übernahme von Macromedia das Real Time Messaging Protocol (RTMP) für Flash-basiertes Video-Streaming. Microsoft entwickelte ein drittes Streaming-Protokoll, Microsoft Media Server (MMS), für den Einsatz in verschiedenen Windows-Anwendungen.

RTSP, RTMP und MMS behandelten alle Video als Sonderfall. Sie bauten "Overlay-Netze" auf, in denen protokollspezifische Streaming-Server neben herkömmlichen HTTP-Servern standen. Wenn ein Benutzer eine Anfrage zur Videowiedergabe stellte, wurde diese an den Streaming-Server weitergeleitet, der dann eine dauerhafte (oder "zustandsabhängige") Verbindung zum Videoplayer des Benutzers herstellte.

 

Benutzerdefinierte Streaming-Protokolle erforderten spezielle Server, eine Firewall-Konfiguration und eine separate Caching-Infrastruktur.

 

Mit benutzerdefinierten Streaming-Protokollen konnten viele der Probleme des progressiven HTTP-Downloads überwunden werden. Das Video wurde gepuffert, verarbeitet und wiedergegeben, während es über das Netzwerk übertragen wurde, so dass die Benutzer ein Video mitten im Stream mit minimaler Bandbreitenverschwendung abbrechen konnten. Der zufällige Zugriff wurde unterstützt, so dass die Betrachter die Wiedergabe an jeder beliebigen Stelle des Videos suchen und schnell starten konnten. Die dauerhafte Verbindung vom Streaming-Server zum Client sorgte für eine bessere Vorhersagbarkeit der Latenzzeit. In allen Fällen halfen diese Overlay-Netzwerke den Unternehmen, den Videodatenverkehr vom primären WAN-Transport zu entlasten und so die Gefahr zu verringern, dass eine Videoüberlastung die Bereitstellung von Informationen und Transaktionsdaten mit höherer Priorität gefährdet.

RTMP, RTSP und MMS waren jedoch nicht ohne Einschränkungen. Da diese Protokolle Video als einen speziellen Datentyp behandelten, erhöhten sie die Kosten und die Komplexität der Videoübertragung. Erstens erforderten diese Protokolle eine Reihe von speziellen Servern, die im gesamten Unternehmensnetzwerk eingesetzt werden mussten, was zusätzliche Kosten für die Hardware- und Softwareinfrastruktur verursachte. Zweitens schufen Streaming-Protokolle eine Bindung zwischen den Bereitstellungs- und Caching-Mechanismen. Dies erforderte von den Unternehmen die Unterstützung zweier separater Caching-Technologien (eine für HTTP-basierten Datenverkehr, eine für Video), wodurch sich die Komplexität der Netzwerkverwaltung verdoppelte. Drittens mussten die Administratoren für RTMP, RTSP und MMS zusätzliche Netzwerkports für die Kommunikation öffnen (1935, 554 bzw. 1755). Dies vergrößerte die Angriffsfläche des Netzwerks und erhöhte die Wahrscheinlichkeit, dass die Protokolle von den Firewalls des Unternehmens blockiert wurden. Schließlich waren benutzerdefinierte Streaming-Protokolle oft nicht mit mobilen Geräten kompatibel. Für die Wiedergabe von RTMP war beispielsweise Flash erforderlich, ein Format, das bekanntermaßen von iOS-Geräten nicht unterstützt wird. Außerhalb des iOS-Ökosystems kommt es bei mobilen Clients häufig zu Verbindungsunterbrechungen und IP-Adressänderungen. Dies führte oft dazu, dass die aktive RTMP-Verbindung während eines einzigen Ereignisses mehrmals neu aufgebaut werden musste.

 

3. Multicast-Video-Streaming-Technologie

Die Behauptung, dass Multicast eine eigenständige Phase der Online-Videobereitstellung war, ist sehr großzügig, wenn man bedenkt, dass die Technologie weder im Unternehmens- noch im Verbraucher-Internet eine kritische Masse erreicht hat. Mitte der 2000er Jahre gab es jedoch ein starkes Interesse an Multicast für Video, und die Technologie ist in einigen Unternehmensnetzwerken nach wie vor vorhanden, so dass eine Diskussion darüber angebracht ist.

Multicast war eine Netztechnologie, die es einem Sender ermöglichte, dieselben Daten an mehrere Empfänger gleichzeitig zu verteilen. Vom Konzept her war es dem Radiohören nicht unähnlich. Ein einziges Radiosignal wird an alle Hörer gesendet, anstatt dass jeder einzelne Empfänger ein eigenes Signal erhält. Bei richtiger Implementierung ermöglichte Multicast eine unglaubliche Effizienz bei der Datenübermittlung. Dies führte zu einem verstärkten Interesse an der Verwendung von Multicast für die Videoübertragung.

Mit Multicast könnte ein Unternehmen theoretisch Live-Videos im gesamten Unternehmensnetzwerk mit einem Bruchteil der Bandbreite bereitstellen, die für die herkömmliche Unicast-Übertragung erforderlich ist. Daher sahen Unternehmen in Multicast oft eine Möglichkeit, zusätzliche Rendite aus ihren bandbreitenbeschränkten Netzwerken zu ziehen, anstatt die Netzwerkinfrastruktur zu verbessern.

 

Bei der Unicast-Übertragung (links) wird für jeden angeschlossenen Client ein eigener Stream gesendet, während bei der Multicast-Übertragung (rechts) ein einziger Stream gesendet wird, der von allen abonnierten Clients gemeinsam genutzt wird.

 

Leider war Multicast aufgrund der Infrastrukturanforderungen für die meisten Unternehmen nicht praktikabel. Um Video (oder andere Daten) per Multicast zu verteilen, mussten die Quelle, die Empfänger und die verbindende Netzwerkinfrastruktur das Protokoll unterstützen. Insbesondere mussten alle Router, Hubs, Switches und Firewalls innerhalb eines Unternehmensnetzwerks Multicast-kompatibel sein. Diese Anforderung einer homogenen Infrastruktur war weder praktisch noch belastbar.

Wenn zum Beispiel ein Multicast-Kommunikationsversuch fehlschlug, wurde in der Regel auf eine herkömmliche Unicast-Übertragung zurückgegriffen. In den meisten Fällen profitierte diese Unicast-Übertragung nicht von einer Netzwerkoptimierung wie Daten-Caching oder anderen WAN-Beschleunigungstechniken, da Multicast die einzige implementierte Form der Optimierung war.

Da das Multicast-Verfahren eine homogene Netzwerkumgebung erforderte, stand es zudem im Widerspruch zu den Netzwerktopologien, die nach wie vor die Online-Kommunikation von Unternehmen und Verbrauchern dominieren. Das Internet ist für eine breite Palette von Netzwerkgeschwindigkeiten, Verbindungstypen, Dienstgüte (QoS) und Endgeräten ausgelegt. Seine Grundlage ist HTTP - ein zustandsloses, medienunabhängiges Protokoll, das speziell für den Einsatz in dieser heterogenen Umgebung entwickelt wurde. In ähnlicher Weise sind auch die Netzwerke hinter den Firewalls von Unternehmen zunehmend heterogen. Der Trend zu Bring-your-own-device (BYOD) bedeutet, dass die Mitarbeiter eine Reihe von Tablets und Smartphones mit unterschiedlichen Funktionen und Netzwerkanforderungen mit sich führen. Und durch die fortschreitende Branchenkonsolidierung wird es immer unwahrscheinlicher, dass eine neu erworbene Niederlassung in London dieselbe Netzwerkarchitektur verwendet wie die Hauptniederlassung in Seattle.

Zusammenfassend lässt sich sagen, dass Multicast ein hochgestecktes, aber unrealistisches Ziel für die Videoübertragung war. In den letzten zehn Jahren hat das Interesse an dieser Technologie stetig abgenommen.

 

Interesse an Multicast, 2004-2015. Quelle: Google Trends.

 

4. Modernes HTTP-Streaming

Im Jahr 2008 stellte Microsoft Smooth Streaming vor, einen hybriden Ansatz für die Bereitstellung von Videos, der viele Vorteile von benutzerdefinierten Streaming-Protokollen bot und gleichzeitig HTTP und die vorhandene Netzwerkinfrastruktur nutzte. Smooth Streaming unterstützte auch die Bereitstellung mit adaptiver Bitrate (ABR), was den Zuschauern schnellere Start- und Suchzeiten, minimale Pufferung und eine reibungslosere Wiedergabe ermöglichte.

 

Adaptives Bitraten-Streaming sorgt für schnellere Start- und Suchzeiten, minimale Pufferung und eine reibungslose Wiedergabe, indem die Videoqualität dynamisch an die Verbindungsgeschwindigkeit des Clients angepasst wird.

 

HTTP-basiertes Streaming gewann schnell an Bedeutung, und andere Marktführer investierten schnell in diese Technologie. Im Jahr 2009 trat Apple mit der Einführung von HTTP Live Streaming (HLS) in den Markt ein. Im Jahr 2010 verlagerte Adobe mit der Veröffentlichung von HTTP Dynamic Streaming (HDS) seinen Schwerpunkt weg von benutzerdefinierten Streaming-Protokollen. Und seit 2010 arbeiten große Streaming- und Medienunternehmen, darunter Microsoft, Google, Adobe, Netflix, Ericsson und Samsung, gemeinsam an MPEG-DASH, einem offenen Standard für adaptives Video-Streaming über HTTP.

Innovationen wie Smooth Streaming, HLS, HDS und DASH haben zu einem Wiederaufleben der HTTP-basierten Videobereitstellung geführt und die Art und Weise, wie Unternehmen Videos über ihre Netzwerke verbreiten, grundlegend verändert.

 

Erfahren Sie mehr über Online-Video-Streaming

In unserem neuesten Whitepaper, Modernes Video-Streaming im Unternehmen: Protokolle, Caching und WAN-OptimierungIn diesem Kapitel werden wir einen tieferen Blick auf die technischen Veränderungen werfen, die den Übergang zu modernem Streaming vorantreiben, einschließlich der sieben Merkmale, die ein Video-Streaming-Protokoll modern machen.

Darüber hinaus werden wir uns mit den neuen Möglichkeiten befassen, die Modern Streaming für Unternehmen bietet, um die vorhandene Netzwerkinfrastruktur für eine skalierbarere und kostengünstigere Bereitstellung von Videos zu nutzen.

Laden Sie Ihr Exemplar noch heute herunter!