Latenz und Leistung

Rund 60 ms von der Kamera bis OBS über USB, bei 1080p wie bei 4K; über WLAN ist es mehr und schwankt stärker. Der Wert wird laufend gemessen, nicht geschätzt, und im Statusfeld, in der Statusleiste und im Log angezeigt.

Woher die Verzögerung kommt#

Stufe	Ungefähr	Hinweise
Aufnahme und Belichtung	Ein Bild	Hellere Szenen werden schneller belichtet, und das macht sich hier bemerkbar.
Hardware-Kodierung	Wenige ms	VideoToolbox. Nichts einzustellen.
Die Verbindung	USB: gering, stabil. WLAN: schwankend	Die Stufe, die ein gutes Setup von einem frustrierenden unterscheidet.
Dekodierung	Wenige ms	Standardmäßig auf der GPU, automatischer Rückfall auf Software.
In deine Szene	Unter einer Millisekunde mit der GPU-Pipeline	Sonst eine Kopie aus dem GPU-Speicher heraus und wieder zurück.

Sie senken#

Nutze USB. Am gleichmäßigsten, unempfindlich gegen überlastetes WLAN, und es lädt das Smartphone.
Leuchte die Szene aus. Ein dunkler Raum verlängert die Belichtung, und das geht direkt vom Latenzbudget ab.
Lass die Standardwerte an. Modus für niedrige Latenz und Hardware-Dekodierung sind beide ab Werk aktiviert.
Übertreib es nicht. Wenn die Aufnahme ein sprechender Kopf ist, der in deiner Szene 1000 px breit ist, ist 1080p kein Kompromiss.
Nutze das Teleobjektiv statt starkem Digitalzoom. Gezoomtes, verrauschtes Video lässt sich schlecht komprimieren, was sich als Spitzen bei Bitrate und Latenz zeigt.

Bei Überlastung wird verworfen, nicht gepuffert. Wenn die Verbindung stockt, verwirft LensLink Bilder und senkt kurz die Qualität, statt einen Rückstau aufzubauen. So bleibt die Latenz flach, statt im Laufe eines Streams anzusteigen.

Die Zahlen im Blick#

OBS-Statusleiste: LensLink: iPhone 60 fps · 11.9 Mb/s · 43 ms, ein Eintrag pro aktiver Quelle.
Das LensLink-Dock (Ansicht → Docks): eine Zeile pro Quelle.
Auf dem Smartphone: Statistik im Statusmenü des Live-Bildschirms zeigt dieselbe Zeile. Mit Sauberes Bild als Ruheansicht bleibt sie absichtlich sichtbar, wenn die Bedienelemente ausgeblendet werden.
Das Statusfeld zeigt bei bestehender Verbindung die gemessene Latenz von der Aufnahme bis zur Dekodierung.

Der Wert ist echt: Ein Abgleich des Uhrversatzes nach Art von NTP läuft einmal pro Sekunde, und genau das macht auch die automatische Lippensynchronität möglich.

Die GPU-Dekodier-Pipeline (Beta)#

Normalerweise wird jedes dekodierte Bild von der GPU in den Arbeitsspeicher heruntergeladen, an OBS übergeben und fürs Compositing sofort wieder hochgeladen – bei 4K60 etwa 2 GB/s an Pixeln, für nichts. Die Beta-Pipeline übergibt OBS das Bild als Textur und spart sich den Umweg.

Werkzeuge → LensLink-Einstellungen. Alle Quellen wechseln gemeinsam, nach einem Neustart von OBS.

Messergebnisse#

Zwölf Konfigurationen, jeweils ca. 25 s Live-Video, derselbe PC und dasselbe Smartphone über WLAN. Die Pixelkopien lagen bei jedem Lauf mit der GPU-Pipeline bei 0,00 MB/s.

Konfiguration	Kosten pro Bild (ms)	Pixelkopien (MB/s)	OBS-CPU
720p 60 HEVC	0,81 → 0,09	163 → 0	2,2 % → 1,4 %
1080p 60 H.264	2,11 → 0,10	370 → 0	2,3 % → 1,6 %
1080p 60 HEVC	1,42 → 0,09	373 → 0	2,6 % → 1,4 %
4K 30 HEVC	4,96 → 0,14	721 → 0	2,9 % → 1,5 %
4K 60 H.264	7,54 → 0,10	1221 → 0	4,1 % → 1,8 %
4K 60 HEVC	4,75 → 0,10	1439 → 0	4,1 % → 1,6 %

Die Kosten pro Bild sinken um 89–99 %, und der Gewinn wächst mit der Auflösung: Bei 4K60 HEVC schob die Standard-Pipeline etwa 1,4 GB/s durch den Arbeitsspeicher, was hier komplett entfällt und die CPU-Last des OBS-Prozesses ungefähr halbiert. Bei Latenz und Bildrate zeigte sich kein systematischer Unterschied – die bestimmen das Netzwerk und der Encoder des Smartphones, nicht der Render-Pfad.

Hinweise zu den Plattformen#

Windows	Jedes von OBS 32 unterstützte System (Windows 10 1909+), über gemeinsam genutzte D3D11-Texturen.
macOS	Jedes von OBS 32 unterstützte System (macOS 13+), über IOSurface. Die Ausnahme sind 10-Bit-Streams: VideoToolbox wandelt sie selbst in 8 Bit um, deshalb werden HDR und Apple Log über den Standardpfad gerendert statt über diesen.
Linux	Braucht OBS auf EGL (Standard unter Wayland und in aktuellen X11-Builds) und einen VAAPI-Treiber – in Mesa für Intel und AMD bereits enthalten; NVIDIA braucht `nvidia-vaapi-driver`.
Mehrere GPUs	Laufen Dekodierung und Rendering auf verschiedenen GPUs, lassen sich keine Texturen teilen; die Quelle fällt automatisch zurück.

Der Rückfall erfolgt pro Quelle und automatisch: Im schlimmsten Fall bekommst du genau die Standard-Pipeline, mit einer Log-Zeile, die den Grund nennt.

Spielt der GPU-Hersteller eine Rolle?#

Eine kleinere als das Betriebssystem. Die Dekodierung ist auf jeder modernen GPU ein fest verdrahteter Funktionsblock, und das Plugin spricht ihn über die plattformeigene API an statt über etwas Herstellerspezifisches.

Windows	Herstellerunabhängig. D3D11VA auf jeder aktuellen GPU, DXVA2 als Rückfall.
macOS	VideoToolbox, auf Apple Silicon wie auf Intel-Macs.
Linux, Intel oder AMD	VAAPI ist bereits in Mesa enthalten – nichts zu installieren.
Linux, NVIDIA	Braucht `nvidia-vaapi-driver`; VDPAU ist der Rückfall. Das ist die einzige Stelle, an der der Hersteller entscheidet, ob die GPU-Pipeline überhaupt greift.
Laptops mit zwei GPUs	Landet die Dekodierung auf der einen und OBS rendert auf der anderen, lassen sich keine Texturen teilen, und die Quelle fällt von selbst zurück.
Ältere GPUs	Eine GPU ohne HEVC-Main10-Decoder fällt bei 10-Bit-Streams auf Software zurück; 8 Bit ist nicht betroffen.

Mehrere Smartphones gleichzeitig sind eine Dekodier-, keine Kodierlast. NVIDIAs Grenze für gleichzeitige NVENC-Sitzungen greift nicht – hier wird nichts auf dem Computer kodiert. Was dich begrenzt, sind Dekodierdurchsatz und Speicherbandbreite, und genau die spart die GPU-Pipeline.

Die Messwerte oben stammen von einem Windows-Rechner mit NVIDIA-Karte. Die Pipeline ist auch deshalb Beta, weil die übrigen Kombinationen – macOS IOSurface, Mesa VAAPI, nvidia-vaapi-driver und der Rückfall bei mehreren GPUs – eher Erfahrungsberichte brauchen als mehr Code.

Selbst messen#

Werkzeuge → LensLink-Einstellungen → Pipeline-Benchmark aufzeichnen schreibt pro Sekunde eine CSV-Zeile in den Konfigurationsordner des Plugins (der Pfad steht im Log), dazu alle fünf Sekunden eine Zusammenfassung. Streame zehn Sekunden mit jeder Konfiguration und vergleiche dann ein Paar:

python3 tools/bench-report.py BEFORE.csv AFTER.csv

Jede für LensLink vorgeschlagene Leistungsänderung sollte einen solchen Vergleich anführen.