Latenz – Echtzeit-Übertragung

Auktionen, Konferenzen, Podiumsdiskussionen
Auktionen, Konferenzen, Podiumsdiskussionen

Der Ausdruck "Latenz" steht für die zeitliche Verzögerung zwischen
a) dem realen Geschehen und b) der Anzeige beim Zuschauer.

Man könnte statt von "Latenz" auch vom "Delay", von "versatzfreiem Streaming" oder von "Echtzeit Übertragung" sprechen. Gemeint ist immer das gleiche. Bei Sportübertragungen, Auktionen, Konferenzen mit zugeschalteten Standorten, Podiumsdiskussionen mit Telefonanrufen, etc. ist es von Vorteil wenn die Wiedergabe des Livestream möglichst schnell nach dem realen Geschehen erscheint.

Die Latenz beim Streaming entsteht im wesentlichen an 3 Punkten:
1) Live-Encoder vor Ort (0,1 bis 5 Sek.)
2) Streamingserver (0,1 bis 5 Sek.)
3) Videoplayer: (ca. 4 bis 30 Sek. per HTML5 Player, Flashplayer: 0,2 bis 3 Sek.)

 

Lösung für Punkt 1)
Die Latenz hängt stark vom gewählten Live-Encoder zusammen. Hardware-Encoder sind in der Regel sehr schnell (0,5 - 1,5 Sek.). Software Live-Encoding wie der Adobe "Flash Media Live Encoder" sind hingegen relativ langsam (2-7 Sek.). Als Software empfehlen wir für geringe Latenzen entweder Wirecast oder OBS. Beide bieten eine Einstellung für optimiertes Low-Latency Streaming (0,1 - 1,5 Sek).

Lösung für Punkt 2) und 3)
Wir können die Bufferzeiten auf dem Streamingserver auf ca. 0,1 Sek. reduzieren. Auf der Webseite im Videoplayer können wir die Latenz im Flashplayer auf 0,1 Sek. reduzieren und im HTML5 Player auf ca. 5-10 Sekunden.
Dies ist in jedem unserer Streamingpakete auf Kundenwunsch kostenfrei enthalten.

Alternativ kann die Bufferzeit auf dem Streamingserver auch bewußt erhöht werden, um trotz schlechter Internetleitung am Übertragungsort eine saubere Übertragung zu ermöglichen. Dies hilft besonders bei schwankender Leitungsgeschwindigkeit und bei hohem Packet Loss (beispielsweise beim Senden des Livestream über eine nicht optimale LTE-Verbindung).

Das heißt, soweit es an uns liegt, können Sie mit einer Verzögerung von unter 1 Sekunde übertragen. Das entspricht beispielsweise einer Skype-Verbindung. Auf die verfügbare Playertechnologie im Browser des Zuschauers haben wir jedoch keinen Einfluss. Wenn hier nur HTML5 zur Verfügung steht (kein Flashplayer) ist die Latenz technisch bedingt durch das verfügbare Protokoll auf typische 3-6 Sekunden als technischer Bestwert limitiert... (Bezieht man jedoch nicht optimale Empfangsbedingungen und unterschiedlichste Mobilgeräte mit ein, sorgen Einstellungen von 3-6 Sekunden Latenz bei vielen Kunden und Zuschauern für Probleme (siehe unten) und wir richten es daher mit ca. 5-10 Sekunden ein.)


Warum wird dies nicht immer so gemacht?
Der Streamingserver als auch der Videoplayer verwenden normalerweise eine Bufferzeit von ca. 1-2 Sekunden um Daten- bzw. Leitungsschwankungen auszugleichen. Datenpakete werden im Internet nicht 100% gleichmäßig übertragen. Für einzelne Datenpakete beträgt die Übertragungszeit nur 10 ms (Millisekunden) für andere 500 ms. Im Fall einer Verbindung per UMTS oder LTE und noch stärker bei einer Satellitenverbindung kommen manche Datenpakete erst nach 1 bis 2 Sekunden an. 

Für herkömmliche Downloads und das Laden einer Webseite mit Text und Bildern ist dies wenig relevant, da die Daten beim Empfänger (unabhängig von der Übertragsungszeit) einfach beim Eintreffen zusammen gesetzt werden. Der Inhalt der Webseite baut sich mit den empfangenen Daten Stück für Stück auf. Es entscheidet primär die Datenmenge die ingesamt übertragen wird, nicht die Zeit, die einzelne Datenpakete benötigen.

Beim Live-Streaming kommen spät ankommende Datenpakete jedoch "zu spät". Wenn der Stream zeitlich die Position bereits abgespielt hat, zu dem gehörig ein Datenpakete verspätet ankommen, sind die Daten nutzlos. Der Zuschauer hat dann ggf. ein Rucken/Hängen im Video wahrgenommen. Wenn Datenpakete nicht nur einzeln, sondern reihenweise zu spät kommen, bleibt das Video zum Nachladen stehen.

Durch Bufferzeiten wird dies fast vollständig vermieden! Spät eintreffende Datenpakete werden noch rechtzeitig verarbeitet. Wird jedoch mit 0,1 bis 0,2 Sek. Latenz ohne Buffer übertragen, und die Daten kommen nicht in idealer Geschwindigkeit beim Streamingserver an, entstehen kurze oder längere Hänger bei der Wiedergabe.

Übrigens ist dies bei DSL-Leitungen weniger problematisch, als bei Übertragungen per Mobilverbindung (vom Livestandort zum Streamingserver). LTE hat eine weit größere Packet-Loss Rate und mehr später eintreffenden Datenpakete! Daher ist eine starke Latenz-Optimierung mit geringsten Buffereinstellungen per Standard NICHT aktiv! Bei entsprechendem Bedarf können wir diese aber gerne wie beschrieben optimieren und optimal für Ihren Bedarf einstellen. Wir können dies auch gerne testweise für Sie aktivieren, wenn Sie es ausprobieren möchten. 

Fazit
In der Summe lässt sich die Übertragungs-Latenz auf unter 1 Sekunde oder ca. 5-10 Sek. reduzieren. 1 Sekunden per Flashplayer, und ca. 5-10 Sek. per HTML5 Player. (Unser Player verwendet per Standard immer HTML5.)

Latenz per HTML5 HLS

Dieser Abschnitt bezieht sich die Wiedergabe beim Zuschauer (und nicht auf das Senden des Livestream über eine mobile Verbindung).

Mobilgeräte der letzten Jahre und alle modernen Browser am PC verwenden für Live-Streaming HTML5 HLS (MPEG DASH).

Dies ist ein HTTP Übertragungsverfahren. Ursprünglich wurde HLS maßgeblich von Apple entwickelt, um ab ca. 2008 auf dem iPhone eine saubere Livestreaming- und Dateistreaming-Übertragung zu ermöglichen.

Ein typischer Vorteil ist, dass ein Videoinhalt in verschiedenen Qualitäten vorliegen kann, welche der Player selbstständig währen der Wiedergabe auswählen und wechseln kann. Hiermit wird ein typisches Problem bei Mobilverbindungen adressiert, dass die Internetverbindung ständig kurzzeitig unterbrochen sein kann, und dann sofort wieder verfügbar ist. Während sich der Nutzer beispielsweise mit dem Auto oder Zug bewegt gibt es permanent kurze Unterbrechungen im Datenverkehr. Diese können von HTTP HLS kompensiert werden, ohne das der Zuschauer bei der Videostream-Wiedergabe diese Unterbrechungen bemerkt! Das Video läuft sauber weiter, weil Videodaten nicht 0,1 bis 1 Sekunden vor der Wiedergabe geladen werden, sondern der Videostream in Abschnitten/Segmenten heruntergeladen wird: Videoblöcke mit typischerweise 10 bis 30 Sekunden Länge.
Nun muss nur noch die Gesamtverbindung die Daten laden können... beispielsweise gab es innerhalb der letzten 30 Sekunden nur für 3 Sekunden guten Empfang - und in diesen 3 Sekunden wurde der 3 MB Datenblock mit 30 Sekunden Videoinhalt geladen. Hierfür ist das Verfahren perfekt!

Dies geht jedoch konzeptbedingt auf Kosten der Latenz. Live-Videos über HLS sind per altem Originalstandard von Apple sogar um ca. 30-50 Sekunden verzögert! (Bei manchen Anbietern sogar im Bereich von 1-2 Minuten.) Wir können dies deutlich reduzieren. Ein Wert unter 8 Sekunden führt jedoch bei vielen Mobilgeräten zu Störungen im Buffering und ein Teil der Zuschauer sehen möglicherweise eine unsaubere Wiedergabe. Daher sind die Konfiguration von ca. 5-10 Sekunden ein gutes Mindestmaß. Dies stellen wir so bereit.

Diese 5-10 Sekunden Verzögerung sind einerseits keine Echtzeit! Andererseits liegt der Wert deutlich unter den verbreiteten Standard-Latenzen und entspricht auf Geräten die nur über HTML5 HLS übertragen können dem technisch schnellsten Ergebnis. Wenn wir dies weiter reduzieren (siehe oben) ist dies möglich, sollte aber von Ihnen getestet werden ob es sich so verhält wie von Ihnen gewünscht.