Echtzeit-Übertragung Live mit geringer Latenz

Die zeitliche Verzögerung zwischen dem realen Geschehen vor der Kamera und der Anzeige auf dem Bildschirm des Zuschauers wird "Latenz" genannt. Es wird auch von "Delay" oder "Echtzeit übertragung" gesprochen.
Relevat ist dies nur für wenige Übertragungen. Beispielsweise bei Liveübertragungen mit Rückfragen von anderen Standorten, für Online-Auktionen, Versteigerungen, etc.
Bei 90% aller Livesteams die Wert auf maximale Qualität und unterbrechungsfreies Video ohne Nachladezeiten legen, werden die gängigen Verzögerungen von ein paar Sekunden von den Zuschauenden nicht wahrgenommen.

Wo entsteht Latenz?

Streaming-Latenz entsteht im Wesentlichen an 3 Punkten:
1) Live-Encoder vor Ort: 0,1 bis 3 Sekunden
2) Streamingserver: 0,1 bis 1,5 Sekunden
3) Videoplayer ca. 4 bis 60 Sekunden per HTML5
(und per Flash- und VLC-Videoplayer ca. 0,1 bis 4 Sek.)

Unsere Streamingpakete haben eine Standardeinstellung für eine Gesamtlatenz von ca. 10-16 Sek. Hier wird eine konstant hochwertige Übertragung priorisiert. Gerne passen wir dies für Sie an. Beispielsweise auf 5 - 9 Sek. Die hierfür benötigten Einstellungen in Ihrem Live-Encoder beschreiben wir im folgenden.
Hinzu kommen Sonderlösungen per WebRTC mit 0,5 - 2 Sek. Latenz.

Optimierung von Punkt 1: Live-Encoder vor Ort
Ihr Livebild und Ton wird vom Live-Encoder verarbeitet und an den Streamingserver geschickt. Ein Hardware-Encoder ist in der Regel sehr schnell (0,4 - 1,0 Sek.). Software Live-Encoder wie Wirecast oder OBS können für eine geringe Latenz konfiguriert werden und erreichen dann Zeiten von ca. 0,1 bis 0,3 Sek. bei leicht verringerter Bildqualität. Wir unterstützen unsere Kunden gerne mit optimalen Einstellungen.

Optimierung von Punkt 2: Streamingserver
Wir können die Bufferzeiten auf dem Streamingserver auf ca. 0,1 Sek. reduzieren. Zu empfehlen ist jedoch eine Bufferzeit von mind. 0,5 Sek! Im Fall einer übertragung von Ihnen zum Streamingserver per LTE / 5G sollten mind. 0,8 Sekunde konfiguriert werden, da die Latenz der Datenpakete schwankt. Zudem gibt es mehr 'Packet Loss'. D.h. es gehen Datenpakete verloren, die zwar noch einmal angefordert und übertragen werden können, bei gering eingestellter Latenz dann aber zu spät eintreffen. Im Fall einer Satellitenübertragung sind 2 Sekunden Buffer zu empfehlen.
Eine spezielle Konfiguration nehmen wir gerne individuell für Sie vor.

Serverseitig kommt das Live-Transcoding in zusätzliche geringere Auflösungen hinzu.

Optimierung von Punkt 3: Player
Der Videoplayer im Browser kann von uns für eine Latenz für Streaming per HTML5 HLS auf ca. 4 bis 12 Sekunden eingestellt werden. Der Wert ist variabel je nach Browser, Mobilgerät, Internetgeschwindigkeit, etc. und kann bei manchen Zuschauern auch abweichen.

Soweit es an uns liegt, können Sie mit einer Verzögerung von unter 1 Sekunde übertragen. Das entspricht beispielsweise einer Zoom-Übertragung. Zu berücksichtigen sind aber die im Browser des Zuschauers verfügbaren Player-Technologien.
Um für über 99% der Zuschauer einen reibungslosen Videostream mit hochwertiger, kontrollierter Bild- und Audioqualität sicherzustellen, steht nur HTML5 HLS / DASH zur Verfügung. Hierfür sind 5-12 Sekunden Latenz realistisch. Je stärker Bufferzeiten und HLS-Segmentgrößen reduziert werden, desto mehr Zuschauer werden möglicherweise (z.B. bei mittelmäßiger Internetverbindung) einen stockenden Livestream oder Nachladezeiten erleben.

Warum wird nicht immer für eine geringe Latenz konfiguriert?

Der Streamingserver als auch der Videoplayer verwenden normalerweise eine Bufferzeit. Daten werden vorgeladen, um 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 100 ms. Im Fall einer Verbindung per LTE / 5G (und noch stärker bei einer Satellitenverbindung) kommen manche Datenpakete bei Neuanforderung durch Packet Loss 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 übertragungszeit) einfach beim Eintreffen zusammengesetzt 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 insgesamt übertragen wird, nicht die Zeit, welche einzelne Datenpakete benötigen.
- Beim Live-Streaming kommen spät ankommende Datenpakete jedoch "zu spät". Die Daten sind nutzlos, wenn der Stream die zeitlich Position zu der die Daten gehören bereits abgespielt hat. Der Zuschauer hat dann z.B. ein Rucken/Hängen im Video wahrgenommen. Wenn Datenpakete nicht nur einzeln, sondern reihenweise zu spät kommen, bleibt der Livestream zum Nachladen stehen. Es fehlen dann im Wiederholten Fall Abschnitte bei der Wiedergabe oder der Stream kann im schlimmsten Fall gar nicht mehr abgespielt werden.

Durch Bufferzeiten wird dies effizient vermieden! Spät eintreffende Datenpakete werden noch rechtzeitig verarbeitet. Deshalb ist eine gewisse Latenz Absicht und wirkt sich positiv in Form einer angenehmen, flüssigen Bild- und Tonwiedergabe aus.

Alternative: WebRTC

Um per Bild und Ton direkt zu kommunizieren, so dass Personen mit einander sprechen können, gibt es Anbieter wie Zoom, Microsoft Teams und webEX. Wie Sie dies mit Streaming kombinieren können lesen sie hier.

Um eine flüssige und qualitativ hochwertige Echtzeit-Übertragung (mit 0,5 - 2 Sek. Latenz) auch für Livestreams zu 100, 500 oder noch viel mehr Zuschauern zu ermöglichen, ist WebRTC das passende Protokoll.

Gängige Live-Encoder Software und Hardware unterstützt bisher jedoch kein SENDEN per WebRTC zum Streamingserver. Als Alternative werden eingebaute Live-Encoder im Chrome- und Firefox-Browser verwendet, die jedoch erstens kaum Videoquellen unterstützen und zweitens eine im direkten Vergleich miserable Encoding-Qualität abliefern. Während in guten Live-Encodern ein Full-HD 1080p Video mit 2 bis 5 MBit/s eine sehr gute Bildqualität erreicht, sind bei gleicher Datenrate im Browser-Encoder deutlich sichtbare Qualitätseinbußen zu erkennen. Sie kennen dies von z.B. Zoom- und Teams-Sitzungen. Teilweise schwankt die optische Qualität, die Auflösung je Teilnehmer liegt deutlich unter HD und später eintreffende Daten werden darüber kompensiert, dass Sie z.B. gesprochene Worte langsamer und dann wieder (wie vorgespult) schneller hören. Für Konferenz-Software ist dies ideal - für Livestreams mit größerem Publikum werden an die Bild- und Tonqualität oftmals höhere Anforderungen gestellt.

Daher wird in der Praxis weiterhin per RTMP / SRT vom Live-Encoder zum Streamingserver übertragen. Dort werden die eingehenden Daten in das WebRTC Protokoll umgewandelt und vom Player abgerufen. Nur so wird die erwartete Qualität erreicht.

Zu bedenken ist auch, dass webRTC nicht in allen Browsern enthalten oder in jeder Hinsicht kompatibel ist. Sowohl am PC als auch besonders auf Smartphones und Tablets.

WebRTC hat aber noch andere Herausforderung wenn Sie B2B bzw. für Zuschauer im Unternehmensumfeld live übertragen möchten: NAT-Slipstreaming-Angriffe. Siehe beispielsweise hier.
Dieses Angriffsszenario führt bei manchen Firmen dazu, dass die WebRTC-Ports und/oder das Protokoll blockiert werden. Ein Streaming per WebRTC ist daher nur zu einem eingeschränkten Zuschauerkreis möglich. Insbesondere im Businessumfeld von Konzernen, bei Banken und Behörden.

Wir haben die Entwicklung im Auge und haben diverse Szenarien getestet. Bisher erfüllt dies aber nicht die Ansprüche. Dies betrifft den Bereich der unterbrechungsfreien hochqualitativen Übertragung, der Zuverlässigkeit und der Kompatibilität bzw. Erreichbarkeit von 99 % der Nutzer.