- Enterprise-IT/AV
Die Funktionsweise von Online-Video-Streaming hat sich geändert
Im Video-Ökosystem ist es selten, dass konkurrierende Technologien lange friedlich koexistieren können.
Der inzwischen berühmte Krieg der Videokassettenformate in den späten 1970er und 1980er Jahren zeigte, wie schnell die Industrie zugunsten einer Technologie kippen konnte und welche verheerenden Auswirkungen dies auf die Konkurrenz haben konnte. Als die Industrie 1975 ihre kollektive Stimme für VHS abgab, dauerte es weniger als drei Jahre, bis die Technologie Betamax überholte. In einer anschließenden Marktverschiebung zwischen 1999 und 2004 wurden die VHS-Verkäufe von der DVD überholt und dann schnell in den Schatten gestellt.
From Beta to VHS to DVD: Case studies in how suddenly the video ecosystem can tip.
Sources: Business History Review, Nexus Research.
Online-Medien haben ähnliche seismische Verschiebungen erlebt. Im Januar 2010 waren nur 10 % der Online-Videos mit dem H.264-Kompressionsformat kodiert. Weniger als zwei Jahre später hatte sich diese Zahl auf 80 % erhöht (MeFeedia).
In jedem dieser Ereignishorizonte wich die Trägheit des Marktes einer Medientechnologie, deren Zeit gekommen war. Und im Jahr 2015 nähert sich die Branche ihrem nächsten Point of no Return.
In den letzten zehn bis zwölf Jahren sind Online-Videos für die Art und Weise, wie Menschen unterhalten werden, wie Studenten lernen und wie Unternehmen kommunizieren, unverzichtbar geworden. Es wird geschätzt, dass mehr als zwei Drittel des weltweiten Internetverkehrs von Verbrauchern bereits aus Video besteht (Cisco) und dass große Unternehmen bereits über 14 Stunden Video pro Mitarbeiter und Monat streamen (Gartner).
Während dieser Zeit hat sich die Technologie der Medienverteilung in vier Phasen entwickelt.
Die Entwicklung der Online-Medien-Streaming-Technologie
1. HTTP Download
Als Videodateien zum ersten Mal online freigegeben wurden, wurden sie über das Hypertext Transfer Protocol (HTTP) verteilt - der gleiche Ü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. Dieser Prozess, download and play genannt, hatte mehrere bemerkenswerte Mängel. Erstens bedeuteten Einwahlgeschwindigkeiten von 28 bis 56 kbit/s, dass die Benutzer 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 oft für ungesehene 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 angegangen, als sie die Unterstützung für Fast Start veröffentlichten, besser bekannt als progressiver HTTP-Download. 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 durch benutzerdefinierte Protokolle und Server ersetzt, die für eine neue Art der Online-Videobereitstellung namens streaming entwickelt wurden.
Der progressive HTTP-Download verbesserte die Startzeit, litt aber immer noch unter verschwendeter Bandbreite und begrenzter Skalierung.
2. Benutzerdefinierte Streaming-Protokolle
Im Vergleich zu anderen Arten von Inhalten, die online freigegeben werden, sind Videodateien riesig. Eine einzige Minute eines iPhone-Videos kann 80 bis 120 MB Speicherplatz beanspruchen. Auf dem gleichen Speicherplatz könnten Sie zwischen 250 und 350 durchschnittlich große Word-Dokumente speichern (Microsoft).
Diese Eigenschaft machte es schwierig, Videodateien über Netzwerke mit begrenzter Bandbreite zu verteilen. Mit der zunehmenden Verbreitung von Videos im Internet und in Unternehmensnetzwerken begannen Medienunternehmen und Softwareanbieter, eigene Protokolle für das Video-Streaming 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 Spezialfall. Sie konstruierten "Overlay-Netzwerke", in denen protokollspezifische Streaming-Server neben herkömmlichen HTTP-Servern standen. Wenn ein Benutzer eine Anforderung zur Wiedergabe von Videos initiierte, wurde die Anforderung an den Streaming-Server weitergeleitet, der dann eine dauerhafte (oder "zustandsabhängige") Verbindung zum Videoplayer des Benutzers öffnete.
Benutzerdefinierte Streaming-Protokolle erforderten spezielle Server, eine Firewall-Konfiguration und eine separate Caching-Infrastruktur.
Benutzerdefinierte Streaming-Protokolle überwanden viele der Herausforderungen des progressiven HTTP-Downloads. Das Video wurde gepuffert, verarbeitet und wiedergegeben, während es über das Netzwerk übertragen wurde, sodass Benutzer ein Video mitten im Stream mit minimaler Bandbreitenverschwendung abbrechen konnten. Der zufällige Zugriff wurde unterstützt, sodass 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 besser vorhersehbare Latenzzeit. Und 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 ein Videostau 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 die Protokolle eine separate Reihe von spezialisierten Servern, die im gesamten Unternehmensnetzwerk eingesetzt werden mussten, was zusätzliche Kosten für die Hardware- und Software-Infrastruktur bedeutete. Zweitens schufen die Streaming-Protokolle eine Bindung zwischen den Bereitstellungs- und Caching-Mechanismen. Dies erforderte, dass Unternehmen zwei separate Caching-Technologien unterstützen (eine für HTTP-basierten Datenverkehr, eine für Video), was die Komplexität der Netzwerkverwaltung effektiv verdoppelte. Drittens mussten 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 Unternehmensfirewalls blockiert wurden. Schließlich waren die benutzerdefinierten Streaming-Protokolle oft nicht mit mobilen Geräten kompatibel. RTMP erforderte zum Beispiel Flash für die Wiedergabe, ein Format, das bekanntermaßen von iOS-Geräten nicht unterstützt wird. Außerhalb des iOS-Ökosystems haben mobile Clients häufige Verbindungsunterbrechungen und IP-Adressänderungen. Dies würde oft erfordern, dass die aktive RTMP-Verbindung während eines einzigen Ereignisses mehrmals neu aufgebaut werden muss.
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 nie eine kritische Masse erreicht hat, weder im Unternehmens- noch im Verbraucher-Internet. 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 im Einsatz, so dass sie diskutiert werden sollte.
Multicast war eine Netzwerktechnologie, die es einem Sender ermöglichte, die gleichen 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 für jede Person, die sich einstellt, ein eigenes Signal gesendet wird. Wenn es richtig implementiert wurde, ermöglichte Multicast eine unglaubliche Effizienz bei der Datenübertragung. Dies führte zu einer Periode des Interesses an der Verwendung von Multicast für die Videoübertragung.
Mithilfe von 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 benötigt wird. Daher sahen Unternehmen in Multicast oft eine Möglichkeit, zusätzlichen ROI aus ihren bandbreitenbeschränkten Netzwerken zu holen, anstatt die Netzwerkinfrastruktur aufzurüsten.
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 machten die Anforderungen an die Infrastruktur Multicast für die meisten Unternehmen unpraktikabel. Um Video (oder andere Daten) per Multicast zu verteilen, mussten sowohl die Quelle als auch die Empfänger und die verbindende Netzwerkinfrastruktur das Protokoll unterstützen. Genauer gesagt musste jeder Router, Hub, Switch und jede Firewall innerhalb eines Unternehmensnetzwerks Multicast-kompatibel sein. Diese Anforderung einer homogenen Infrastruktur war weder praktisch noch belastbar.
Wenn zum Beispiel eine versuchte Multicast-Kommunikation fehlschlug, war der Fallback typischerweise eine traditionelle Unicast-Übertragung. 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 Multicast außerdem eine homogene Netzwerkumgebung erforderte, stand es im grundlegenden Widerspruch zu den Netzwerktopologien, die noch immer 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 die Arbeit in dieser heterogenen Umgebung entwickelt wurde. In ähnlicher Weise sind auch die Netzwerke hinter den Firewalls der Unternehmen immer heterogener. 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 die fortschreitende Branchenkonsolidierung macht es immer unwahrscheinlicher, dass eine neu erworbene Niederlassung in London dieselbe Netzwerkarchitektur verwendet wie das Home Office 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 führte Microsoft Smooth Streaming ein, einen hybriden Ansatz für die Videobereitstellung, 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 ein flüssigeres Wiedergabeerlebnis bot.
Adaptives Bitraten-Streaming bietet 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 Dynamik, und andere Marktführer investierten schnell in die 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 verteilen, umgewälzt.
Erfahren Sie mehr über Online-Video-Streaming
In unserem neuesten Whitepaper "Modern Video Streaming in the Enterprise: Protocols, Caching, and WAN-Optimierung" werfen wir einen genaueren Blick auf die technischen Veränderungen, die die Entwicklung hin zu modernen Streamingvorantreiben, einschließlich der sieben Merkmale, die ein Video Streaming Protokoll modern machen.
Wir werden uns auch mit den neuen Möglichkeiten befassen, die Modern Streaming für Unternehmen bietet, um die vorhandene Netzwerkinfrastruktur für eine skalierbarere und kostengünstigere Videobereitstellung zu nutzen.
Laden Sie Ihr Exemplar noch heute herunter!