Latency and performance

Roughly 60 ms camera to OBS over USB, at 1080p or 4K; Wi-Fi is higher and more variable. The figure is measured continuously, not estimated, and shown in the Status field, the status bar and the log.

Where the delay comes from#

Stage	Roughly	Notes
Capture and exposure	One frame	Brighter scenes expose faster, and it shows up here.
Hardware encode	A few ms	VideoToolbox. Nothing to tune.
The link	USB: small, steady. Wi-Fi: variable	The stage that separates a good setup from a frustrating one.
Decode	A few ms	GPU by default, software fallback automatic.
Into your scene	Sub-millisecond on the GPU pipeline	Otherwise a copy out of GPU memory and back.

Lowering it#

Use USB. Most consistent, immune to Wi-Fi congestion, and it charges the phone.
Light the scene. A dark room lengthens exposure, and that lands straight in the latency budget.
Leave the defaults on. Low latency mode and hardware decoding both ship enabled.
Don't over-specify. If the shot is a talking head 1000 px wide in your scene, 1080p is not a compromise.
Use the telephoto rather than heavy digital zoom. Zoomed, noisy video compresses badly, which shows up as bitrate and latency spikes.

Congestion is dropped, not queued. When the link stalls, LensLink drops frames and briefly lowers quality rather than building a backlog, so latency stays flat instead of drifting up through a stream.

Watching the numbers#

OBS status bar: LensLink: iPhone 60 fps · 11.9 Mb/s · 43 ms, one entry per live source.
The LensLink dock (View → Docks): one row per source.
On the phone: the gauge button shows the same line. With Clean feed as your idle view it deliberately stays visible when the controls fade.
The Status field carries measured capture-to-decode latency while connected.

The figure is real: an NTP-style clock-offset exchange runs once a second, which is also what makes automatic lip sync possible.

The GPU decode pipeline (beta)#

Normally each decoded frame is downloaded from the GPU into system memory, handed to OBS, and uploaded straight back for compositing — about 2 GB/s of pixels at 4K60, for nothing. The beta pipeline hands OBS the frame as a texture and skips the round trip.

Tools → LensLink Settings. All sources switch together, after an OBS restart.

Measured results#

Twelve configurations, ~25 s of live video each, same PC and phone over Wi-Fi. Pixel copies read 0.00 MB/s on every GPU-pipeline run.

Config	Cost per frame (ms)	Pixel copies (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%

Per-frame cost drops 89–99%, and the win scales with resolution: at 4K60 HEVC the standard pipeline pushed about 1.4 GB/s through system memory, which this removes outright, roughly halving OBS's process CPU. Latency and frame rate showed no systematic difference — they are set by the network and the phone's encoder, not the render path.

Platform notes#

Windows	Any OBS 32-supported system (Windows 10 1909+), using shared D3D11 textures.
macOS	Any OBS 32-supported system (macOS 13+), via IOSurface.
Linux	Needs OBS on EGL (the default on Wayland and current X11 builds) and a VAAPI driver — built into Mesa for Intel and AMD; NVIDIA needs `nvidia-vaapi-driver`.
Multi-GPU	Decoding and rendering on different GPUs can't share textures; the source falls back automatically.

Fallback is per source and automatic: the worst case is exactly the standard pipeline, with a log line saying why.

Measuring it yourself#

Tools → LensLink Settings → Record pipeline benchmark writes one CSV row per second into the plugin's config folder (path in the log), plus a summary every five seconds. Stream ten seconds on each configuration, then compare a pair:

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

Any performance change proposed to LensLink is expected to quote one of these.