Echtzeit-Übertragung

Auktionen, Konferenzen, Podiumsdiskussionen
Auktionen, Konferenzen, Podiumsdiskussionen

Der Ausdruck "Latenz" steht für die zeitliche Verzögerung zwischen dem realen Geschehen bis zur Anzeige auf dem Bildschirm des Zuschauers.
Bei Support-Anfragen sprechen unsere Kunden auch oft von "Delay", "Versatzfreiem Streaming" oder fragen nach "Echtzeit Übertragung".

Bei Sportübertragungen, Auktionen, Konferenzen mit zugeschalteten Standorten, Podiumsdiskussionen mit Telefonanrufen, etc. ist eine niedrige Latenz von großem Vorteil.

Ein Beispiel aus der Praxis:
Bei der Übertragung von Fußballspielen versuchen sowohl Streaminganbieter als auch TV-Sender eine möglichst geringe Latenz zu erzielen. Fällt ein Tor, soll nicht zuerst der Nachbar jubeln und andere sehen das Tor erst 30 Sekunden später.

 

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

 

Lösung für Punkt a)
Die Latenz hängt primär mit dem gewählten Live-Encoder zusammen. Hardware-Encoder sind in der Regel sehr schnell (0,5 - 1,5 Sek.). Live-Encoding Software 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 b) und c)
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. 3-6 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 bei LTE-Verbindungen).

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 Bestwert limitiert.  


Nützliches Hintergrundwissen:

Buffer-Zeiten lassen sich im Streamingserver für eine sehr geringe Latenz verkleinern oder auf ein Minimum von 0,1 Sekunden reduzieren.
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 einfach beim Empfänger (unabhängig von der Übertragsungszeit) 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, wirkt es sich ggf. sichtbar auf die Wiedergabe aus.

Übrigens ist dies bei DSL-Leitungen weniger problematisch, als bei Übertragungen per Mobilverbindung (vom Livestandort zum Streamingserver). Diese haben 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 reduziert, wenn der Zuschauer den Flashplayer verwendet. In dieser Region bewegen sich auch Video-Messenger und man kann sich relativ gut über die Verbindung hin- und zurück unterhalten ohne einen großen Versatz zu spüren. Per HTML5 ist eine flüssige Unterhaltung (hin- und zurück) nicht möglich. Aber es werden im Idealfall Zeiten von 3-6 Sekunden erreicht.

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).

Videostreaming per HTML5 HLS 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!
Gleichzeitig werden auch die Bedürfnisse von langsamen DSL-Verbindungen in ländlichen Regionen befriedigt.

Dies geht jedoch konzeptbedingt auf Kosten der Latenz. Live-Videos über "HLS" sind per altem Standard von Apple 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 es müsste bei einem Teil der Zuschauer eine unsaubere Wiedergabe in kauf genommen werden. Daher sind ca. 10 Sekunden ein gutes Mindestmaß. Dies stellen wir so bereit.

Diese 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.