Wie wir die Bildschirmfreigabe viermal schneller gemacht haben

Latenz bei der Bildschirmfreigabe gehört zu den Problemen, die man erst bemerkt, wenn sie wirklich stören. Ein Vortragender klickt zur nächsten Folie, und der Raum, der den geteilten Bildschirm verfolgt, sieht sie anderthalb Takte später. Nicht direkt kaputt, nur eben daneben. Über mehrere Releases hinweg haben wir genau untersucht, woher diese Verzögerung in der Bildschirmfreigabe von Cliqer kam, und die Grundlatenz von über zwei Sekunden auf etwa eine halbe Sekunde gesenkt, eine Verbesserung um ungefähr das Vierfache. Hier ist die allgemein verständliche Version, wie das gelang.

Wir verstecken uns nicht hinter Codenamen und tun auch nicht so, als gäbe es die eine Wunderlösung. Es gab drei separate Fixes, jeder zielte auf eine andere Stelle, an der sich die Verzögerung versteckte, und ihre Wirkung summierte sich.

Warum die Bildschirmfreigabe überhaupt verzögert

Wenn Sie einen Bildschirm teilen, müssen drei Dinge passieren, bevor ein Zuschauer ein Bild sieht: Ihr Rechner muss es erfassen, zu Video kodieren und senden. Jeder dieser Schritte kann unbemerkt Verzögerung hinzufügen, und der Effekt summiert sich. Ein langsamer Encoder plus ein vorsichtiger Puffer plus das Warten auf das nächste vollständige Bild-Update ergeben schnell zwei oder drei Sekunden, selbst bei einer schnellen Verbindung.

Das Knifflige ist, dass keiner dieser Schritte für sich genommen kaputt wirkt. Die Erfassung funktioniert. Die Kodierung funktioniert. Der Stream kommt an. Er ist nur zu spät, und „nur zu spät“ lässt sich schwer diagnostizieren, ohne jede Stufe einzeln zu messen.

Fix eins: dasselbe Bild nicht zweimal kodieren

Die erste Ursache der Verzögerung war verschwendete Arbeit. Bildschirm- und NDI-Freigaben wurden im Hintergrund doppelt kodiert, einmal für jeden Ausgabepfad, und eine unbewegte Folie wurde fortlaufend neu kodiert, obwohl sich auf dem Bildschirm nichts verändert hatte. Das verdoppelte die Last auf dem Encoder ohne sichtbaren Nutzen, und die Pipeline war dadurch ständig stärker ausgelastet als nötig, was jedes Bild in der Warteschlange weiter nach hinten schiebt.

Durch das Entfernen des doppelten Kodierdurchgangs und das Überspringen der Neukodierung bei unverändertem Bild wurde sofort spürbar CPU-Reserve frei. Weniger Konkurrenz um den Encoder bedeutet, dass jedes Bild, das tatsächlich kodiert werden muss, früher verarbeitet wird.

Fix zwei: den Puffer verkleinern, ohne an Robustheit zu verlieren

Die zweite Ursache war der Puffer zwischen Encoder und Netzwerk, also der Teil, der kurze Netzwerkaussetzer abfangen soll, damit ein Ruckler auf der Leitung nicht zu einem Ruckler auf dem Bildschirm wird. Solche Puffer sind von Natur aus ein Kompromiss: zu klein, und schon ein kleiner Aussetzer verursacht sichtbare Bildfehler; zu großzügig, und Sie fügen jedem einzelnen Bild Verzögerung hinzu, nur für den Fall, dass später etwas schiefgeht.

Der Puffer war großzügig bemessen, was bedeutete, dass er im Normalfall jedes Bild verzögerte, um vor einem seltenen Fall zu schützen. Durch die Verkleinerung sank die Verzögerung im schlimmsten Fall von einigen Sekunden auf deutlich unter eine, während kurze Netzwerkaussetzer weiterhin ohne sichtbare Bildfehler überbrückt werden. Das ist die Art von Fix, die im Diff wie eine kleine Zahlenänderung aussieht, in Wirklichkeit aber eine Abwägung ist, welchen Fehlermodus man lieber in Kauf nimmt.

Fix drei: neue Zuschauer nicht auf den nächsten Keyframe warten lassen

Der dritte Fix zielte auf einen bestimmten, unangenehmen Moment: was passiert, wenn jemand einer bereits laufenden Freigabe beitritt. Videokompression funktioniert so, dass vollständige Bilder, sogenannte Keyframes, nur gelegentlich gesendet werden, dazwischen günstigere Bilder nach dem Prinzip „was hat sich seit dem letzten Mal geändert“. Ein Zuschauer, der mitten im Stream einsteigt, kann mit diesen Zwischenbildern nichts anfangen, bis er einen Keyframe als Ausgangspunkt erhält, und bisher hieß das, auf den nächsten planmäßigen zu warten, bis zu drei Sekunden lang.

Die Lösung bestand darin, den jeweils neuesten Keyframe zwischenzuspeichern und ihn einem neuen Abonnenten in dem Moment zu übergeben, in dem er beitritt, statt ihn auf den nächsten planmäßigen warten zu lassen. In Kombination mit dem intervallbasierten Frame-Timing, das in unserer Dokumentation zur Bildschirmfreigabe beschrieben ist, sehen neue Zuschauer jetzt innerhalb von Millisekunden nach dem Beitritt Video, statt bis zu drei Sekunden auf den nächsten Keyframe zu warten.

Zusammengenommen machten die drei Fixes aus der Grundlatenz von über zwei Sekunden, der die meisten nie so recht getraut hatten, etwa eine halbe Sekunde, ungefähr eine Vervierfachung, bei geringerer CPU-Last und weniger Bandbreite als zuvor. Auch die volle Bildrate spielt hier eine Rolle: Das Program-Video war unbemerkt auf etwa 31 Bilder pro Sekunde begrenzt, unabhängig von der Quelle, sodass eine Freigabe mit 60fps jetzt beim Empfänger genauso flüssig aussieht wie auf dem eigenen Bildschirm des Vortragenden.

Was das bedeutet, wenn Sie gerade präsentieren

Nichts davon erfordert, dass Sie eine Einstellung ändern. Es ist in der Bildschirmfreigabe-Pipeline der Desktop-App enthalten und gilt unabhängig davon, ob Sie einen einzelnen Monitor in einem kleinen Raum teilen oder eine vollständige Studio-Produktion mit mehreren Quellen fahren, einschließlich vMix-Workflows, die auf ein schnelles, vorhersehbares Signal angewiesen sind. In Cliqer 3 ist Studio-Video auf dem Mac Zero Copy: Kamerabilder, Quellen und Program bleiben im GPU-Speicher, und der Hardware-Encoder liest Program direkt von der GPU-Oberfläche. Cliqer 3 zeigt außerdem Program-Bildrate, GPU- und CPU-Last durchgehend in der Statuszeile von Studio an, sodass Sie die Bildrate mitten in der Show selbst prüfen können. Wenn Sie zusätzlich zur Latenzoptimierung Qualität gegen Bandbreite abwägen möchten, finden Sie in den Einstellungen zur Bildschirmfreigabe Codec-Wahl, Auflösung und Bitrate, und mit Desktop 2.2.0 kam die Möglichkeit hinzu, System- oder Mikrofonaudio direkt in eine Freigabe einzubinden.

Für hybride Setups, in denen die Verzögerung am deutlichsten sichtbar war, besonders bei einem externen Sprecher, der einen geteilten Bildschirm verfolgt und live reagiert, passt dazu unser Leitfaden zum Beheben von Latenz bei der Bildschirmfreigabe in hybriden Meetings sowie unser Erklärartikel dazu, warum Presenter-Latenz in Millisekunden auf der Steuerungsseite genauso wichtig ist wie auf der Videoseite.

Wohin der Rest der Latenz geht

Die Bildschirmfreigabe ist nur ein Abschnitt der Strecke. Der andere ist der Netzwerkpfad selbst: ob die Verbindung zwischen Vortragendem und Zuschauer direkt oder über ein Relay läuft und was in Netzwerken passiert, die direkten Peer-to-Peer-Verkehr blockieren. Diese Seite behandeln wir, einschließlich der Frage, warum sich diese Latenz in manchen Netzwerken nie vollständig beseitigen lässt, in TURN-Server erklärt und Ist WebRTC sicher?.

Häufige Fragen

Probieren Sie es selbst aus

Am schnellsten spüren Sie den Unterschied, wenn Sie einen Bildschirm teilen und dabei das Gesicht einer anderen Person beobachten, sobald sie ihn sieht. Laden Sie Cliqer kostenlos herunter und testen Sie eine Bildschirmfreigabe mit Ihrem eigenen Setup, oder sehen Sie sich den vollen Funktionsumfang der Bildschirmfreigabe an und vergleichen Sie die Pläne unter Preise.