Stream-Latenz ist kein Lippensync-Versatz

Zwei Beschwerden klingen fast gleich und haben nichts miteinander zu tun. „Die Zuschauer sehen es zu spät“ ist Latenz. „Die Lippen passen nicht zur Stimme“ ist ein Synchronversatz. Beides wird an unterschiedlichen Stellen und von unterschiedlichen Leuten behoben – und das Erste, was wirklich hilft, ist, sie nicht als ein einziges Problem zu behandeln.

In zehn Sekunden auseinanderhalten

Die wichtigste Unterscheidung: Latenz ist eine Verzögerung, die Sie einplanen können, Asynchronität ist ein Defekt. Zehn Sekunden Latenz sind eine Designentscheidung. Zweihundert Millisekunden Lippensync-Fehler sind kaputt – bei jeder Latenz.

Woraus sich die Verzögerung zusammensetzt

Latenz ist nicht eine Zahl, die eine einzige Ursache hat. Sie ist eine Summe, und jeder Summand gehört jemand anderem. Wer weiß, welcher Anteil welcher ist, sieht sofort, ob er etwas dagegen tun kann.

Ihr Encoder. Er muss genug Frames sammeln, um sie gegeneinander zu komprimieren, und gibt dann das Ergebnis heraus. Ein kleiner Anteil, der im Wesentlichen von den Puffereinstellungen Ihres Encoders bestimmt wird.

Der Weg zu uns. Die physische Entfernung plus der Schutz, den Sie angefordert haben. Wenn Sie SRT nutzen, enthält die URL ein Latenzbudget von mindestens 500 ms – Sie haben diese Verzögerung ausdrücklich eingekauft, um Paketverluste zu überstehen. Das ist der Tausch, der genau wie vorgesehen funktioniert, kein Fehler.

Unser Encoding und Packaging. Der Stream wird in die Qualitätsstufen neu encodiert und in Segmente geschnitten. dcast arbeitet mit 4-Sekunden-Segmenten und einem Keyframe-Intervall von 2 Sekunden; ein Segment kann also erst veröffentlicht werden, wenn alle seine 4 Sekunden vorliegen. Bei segmentierter Auslieferung ist das der größte Anteil der gesamten Kette – und das ist Arithmetik, keine Ineffizienz.

Die Auslieferung an den Zuschauer. Die Segmente dorthin bringen, wo der Zuschauer gerade ist.

Der Puffer des Players. Bevor er etwas anzeigt, sammelt der Player Segmente, damit ein langsamer Moment in der Verbindung des Zuschauers nicht zu einem sichtbaren Hänger wird. Diesen Anteil kennen die meisten gar nicht, und nach dem Packaging ist er oft der größte. Ein Player, der drei 4-Sekunden-Segmente vorhält, liegt zwölf Sekunden hinter dem Live-Geschehen, bevor er auch nur ein Bild gezeichnet hat – nicht, weil irgendetwas langsam ist, sondern weil er sich für Sicherheit entschieden hat.

Was Sie verringern können – und was nicht

Zählt man die Anteile zusammen, wird klar, wo Spielraum ist. Die Physik – Entfernung, Geschwindigkeit des Netzes – können Sie nicht ändern. Der Puffer Ihres Encoders ist so klein, dass sich das Tuning selten lohnt, gemessen am Risiko. Das SRT-Latenzbudget können Sie senken, aber Ihre Toleranz gegenüber Paketverlusten sinkt genau im gleichen Maß – und wenn Sie SRT eingesetzt haben, hatten Sie vermutlich einen Grund dafür.

Die beiden Anteile mit echtem Spielraum sind die Segmentdauer und der Player-Puffer, und sie hängen zusammen: Der Player puffert in Segmenteinheiten, die Segmentlänge geht also als Faktor ein. Bei dcast ist die Player-Seite als Latenzmodus des Streams zugänglich – normal, low oder ultra –, und man sollte genau wissen, was diese Einstellung ist: Sie ändert, wie viel der Player puffert, und erreicht den Encoder überhaupt nicht. Das Encoding-Raster ist für jeden Stream auf der Plattform gleich.

So sieht der Tausch ehrlich aus. Ein kürzerer Puffer bedeutet, dass der Zuschauer näher am Live-Geschehen ist und weniger Schutz gegen Aussetzer seiner eigenen Verbindung hat; ein längerer Puffer bedeutet das Gegenteil. Es gibt keine Einstellung, die beides liefert, und wer behauptet, ein Protokoll beseitige diesen Tausch, hat ihn nur an eine andere Stelle verschoben.

Entscheiden Sie, wie live Ihr Stream sein muss

Die meisten Streams brauchen keine niedrige Latenz, und die, die sie brauchen, brauchen sie meist aus einem ganz bestimmten Grund – den sollte man benennen, bevor man anfängt, Robustheit herzugeben.

Wenn Ihre Zuschauer live mit Ihnen interagieren – Sie lesen den Chat vor, beantworten Fragen, führen eine Auktion durch –, dann ist die Latenz das ganze Produkt, und ein Zuschauer, der zwanzig Sekunden hinterherhängt, nimmt an einem anderen Gespräch teil als Sie.

Wenn Ihre Zuschauer das Ereignis zweimal mitbekommen könnten – ein Fußballspiel, bei dem die Nachbarn schon jubeln, oder alles, wo eine Push-Benachrichtigung Ihrem Stream zuvorkommen kann –, dann ist Latenz ein Spoiler-Problem.

Trifft beides nicht zu, und bei den meisten Übertragungen ist das so, dann ist ein großzügiger Puffer die bessere technische Wahl: Der Fehler, den er verhindert – ein Hänger mitten im Vortrag –, fällt dem Zuschauer stärker auf, als zehn Sekunden hinter einem Ereignis zu liegen, das er auf keinem anderen Weg sieht.

Die Latenz, die Sie sich selbst einbauen

Bevor Sie die Auslieferung beschuldigen, lohnt es sich, die Verzögerung zu zählen, die in Ihrem eigenen Raum entsteht. Sie ist oft größer als erwartet – und genau diesen Teil können Sie tatsächlich beseitigen.

Jedes Gerät, durch das das Signal läuft, kostet etwas. Eine Kamera, ein Konverter, ein Bildmischer, ein Scaler, ein zweiter Mischer für den Beamer – jedes hält das Bild einen Moment fest, während es seine Arbeit macht. Eine Kette aus vier Geräten bedeutet vier Verzögerungen, und keine davon ist irgendwo dokumentiert, wo Sie sie leicht finden würden.

Funkstrecken kosten mehr als Kabel. Ein drahtloser Videosender muss paketieren, absichern und wieder zusammensetzen; dieser Schutz ist exakt derselbe Tausch wie ein SRT-Latenzbudget – nur trifft ihn ein Gerät statt Sie.

Ein Relay kostet einen kompletten Weg. Wenn Ihr Signal vom Veranstaltungsort zu einem Büro und von dort zur Plattform läuft, bezahlen Sie beide Strecken plus das, was die Box dazwischen tut. Nicht selten stellt sich heraus, dass die „Streaming-Latenz“, über die sich jemand beschwert, zum größten Teil ein Zwischenschritt ist, der aus historischen Gründen existiert.

Finden lässt sie sich so: Stellen Sie eine Uhr vor die Kamera und fotografieren Sie die Uhr zusammen mit jedem Bildschirm entlang der Kette – dem Kontrollmonitor der Kamera, dem Programmausgang des Mischers, der Vorschau im Encoder. Jeder Schritt zeigt Ihnen, was diese Stufe gekostet hat. Sehr oft ist ein einziges Gerät für den Großteil verantwortlich, und es aus dem Signalweg zu nehmen, geht schneller und kostet weniger als jede Einstellungsänderung weiter hinten.

Lippensynchronität ist ein ganz anderer Fehler

Nun zur anderen Beschwerde. Wenn Stimme und Lippen nicht zusammenpassen, helfen Änderungen an den Latenzeinstellungen nicht, denn Ton und Bild reisen zusammen – der gesamte paketierte Stream kommt als Ganzes zu spät. Ein Synchronfehler bedeutet, dass beide schon versetzt angekommen sind oder dass etwas sie getrennt hat.

Fast immer passiert das vor dem Encoder. Ton und Bild erreichen Ihren Encoder über unterschiedliche Geräte, und unterschiedliche Geräte brauchen unterschiedlich lange.

Meist ist das Bild das langsamere. Die Kamera verarbeitet und skaliert, das Capture-Gerät wandelt um, der Mischer setzt zusammen. Jeder Schritt kostet ein wenig. Der Ton dagegen kommt oft auf einem viel kürzeren Weg – ein Mikrofon direkt in ein Audio-Interface.

Die übliche Lösung ist deshalb, den Ton zu verzögern, nicht das Bild vorzuziehen, denn vorziehen lässt sich nichts: Das Bild ist bereits so früh, wie es je sein wird. Fast jeder Bildmischer und jedes Audio-Interface bietet aus genau diesem Grund eine Audioverzögerung.

Messen Sie, bevor Sie einstellen. Klatschen Sie einmal gleichzeitig vor Kamera und Mikrofon, nehmen Sie den Programmausgang auf und schauen Sie, wo der Klatscher auf jeder Spur liegt. So haben Sie eine Zahl statt einer Schätzung, und diese Zahl ist für eine bestimmte Gerätekette meist stabil – Sie stellen sie also einmal ein.

Wenn der Versatz während der Übertragung wächst

Ein fester Versatz ist lästig, aber einfach. Ein Versatz, der klein anfängt und eine Stunde später eine ganze Sekunde beträgt, ist ein anderer Fehler, und Verzögerungseinstellungen bekommen ihn nicht in den Griff.

Das ist ein Taktproblem. Ihr Audiogerät und Ihr Videogerät zählen die Zeit jeweils mit einem eigenen Oszillator, und wenn sie auch nur um einen winzigen Bruchteil voneinander abweichen, summiert sich der Versatz auf, solange Sie auf Sendung sind. Ein Hundertstelprozent ergibt eine Drittelsekunde pro Stunde.

Die Lösung besteht darin, beide denselben Takt nutzen zu lassen, statt das Symptom zu korrigieren. Wo Ihre Ausrüstung es unterstützt, versorgen Sie Ton und Bild aus einer gemeinsamen Referenz. Wo nicht – der Normalfall bei Consumer-Geräten –, bevorzugen Sie Wege, die beide zusammenhalten: Ton, der per HDMI oder SDI im Videosignal eingebettet ist oder vom selben Gerät aufgenommen wird, das auch das Bild erfasst, statt eines separaten Audio-Interfaces mit eigenem Quarz.

Steht beides nicht zur Verfügung, besteht die praktische Abhilfe darin, einzelne Übertragungen so kurz zu halten, dass der aufgelaufene Fehler unter der Schwelle bleibt, ab der es jemandem auffällt, und zwischen den Abschnitten neu zu synchronisieren.

Eine Diagnosereihenfolge, die funktioniert

Prüfen Sie zuerst Ihren eigenen Programmausgang, auf Ihrem eigenen Rechner, bevor Sie irgendetwas anderes tun. Ist die Synchronität schon dort falsch, hat nichts weiter hinten sie verursacht, und keine Plattformeinstellung wird sie reparieren.

Ist der lokale Ausgang korrekt, prüfen Sie eine Aufnahme des ausgelieferten Streams. Synchronität, die lokal stimmt und weiter hinten falsch ist, ist wirklich ungewöhnlich und sollte gemeldet werden, denn das ist kein Einstellungsproblem.

Erst wenn die Synchronität als korrekt bestätigt ist, sollten Sie sich überhaupt der Latenz widmen. Wer die Verzögerung korrigiert, während der Ton aus dem Takt ist, bekommt nur einen schnelleren falschen Stream.

Und messen Sie die Latenz so, wie ein Zuschauer sie erlebt, nicht anhand der Statistik Ihres Encoders: Blenden Sie eine Uhr ein, schauen Sie den Stream auf einem unabhängigen Gerät an und fotografieren Sie beides. Diese Zahl enthält den Player-Puffer – den Anteil, den Ihr Encoder nicht sieht und der häufig der größte ist.