Someone waves at the camera and the wall responds visibly late. The room notices. Everyone blames the network, because the network is the part nobody can see.

The network is usually one frame of a six-frame problem. Two of the other five are free to fix and one of them is probably a setting nobody checked.

Count in frames, not milliseconds

Latency in a video chain accumulates in frame-sized lumps, because most stages hold a whole frame before passing it on. At 60fps a frame is 16.7ms; at 50fps it is 20ms; at 25fps it is 40ms.

Counting in frames makes the arithmetic tractable and makes the frame-rate decision visible: the same chain at 25fps is more than twice as laggy as at 60fps, before you change anything else.

Perceptually, the thresholds that matter:

  • Under 3 frames — nobody notices, including presenters watching themselves.
  • 3 to 6 frames — noticeable to a presenter on a confidence monitor, invisible to an audience watching content.
  • Over 6 frames — a presenter cannot use the confidence monitor. If they gesture at the screen, it is visible to the room.
  • Over 10 frames — audible lip sync problems if there is any sound in the picture.

The six places it comes from

1. Capture: 1 to 2 frames

Getting the picture into the machine. A camera over SDI into a capture card is about one frame. A USB webcam is often two or three, because USB video devices buffer. Screen capture on macOS is roughly one frame.

Fixable? Somewhat. Choose SDI capture over USB where you have the option — the difference is real and it is at the front of the chain where it compounds.

2. Compositing: 1 to 3 frames

Your playback or mapping software takes the source, renders it into a canvas with everything else, and presents the result. One frame is typical. It grows when the software is under pressure, when effects chains get long, and when the GPU is being asked for more than it can deliver in 16ms.

Fixable? Yes, and this is where the biggest wins hide. Reduce the resolution you are compositing at if you are over-provisioned. Cut effects you cannot see. Check whether the machine is thermally throttled — a hot Mac in a hot venue quietly halves its performance. Watch actual frame timing rather than trusting that it looks smooth.

3. NDI encode: about 1 frame

Compressing the frame for the network. Full-bandwidth NDI is intraframe, so this is genuinely about a frame — it does not need to look ahead.

Fixable? Only by not doing it. If the destination is on the same Mac, use Syphon and this stage disappears entirely along with the decode. That is the single largest free saving available in most rigs, and it is why the transport choice is worth being deliberate about.

The trap here is NDI HX. It uses long-GOP compression to cut bandwidth dramatically, and pays for it with latency — several frames rather than one, sometimes more depending on the encoder. HX is excellent for a comfort monitor backstage and wrong for anything a presenter looks at.

4. The network: under 1 frame, if it is a real network

On a wired gigabit switch with the video traffic isolated, transit is well under a millisecond. Effectively zero.

It becomes the whole problem when the network is not that: Wi-Fi anywhere in the path, an unmanaged switch flooding multicast, the show network sharing a VLAN with the venue’s guest traffic, or a link saturated because someone put six full-bandwidth 1080p60 streams down one gigabit uplink and 900 Mbps does not fit.

Fixable? Yes, and cheaply, by building the network properly rather than by tuning anything. NDI on a show network covers what the switch needs from you.

5. NDI decode: about 1 frame

Symmetrical with encode, and it happens on every receiver. Three destinations means three decodes on three machines, which is fine, but it also means a slow receiver is its own latency story independent of everything upstream.

6. The display device: 1 to 4 frames, and nobody tells you

This is the stage that gets overlooked, and on an LED wall it is often the largest single contributor.

  • An LED processor is doing scaling, colour processing and frame management. One to three frames depending on the model and what features are enabled.
  • A projector in its default picture mode may be doing motion interpolation, noise reduction and scaling — easily two to four frames. There is almost always a low-latency or game mode that turns it off.
  • A production switcher frame-syncs every input, which costs a frame by definition.
  • A consumer TV used as a confidence monitor is the worst offender in the building. Four frames is normal in its default mode.

Fixable? Very often, and for free. Turn off every processing feature on the display device. On projectors, find low-latency mode. On processors, ask the LED tech what the through-delay is and whether any of it is optional — they will usually know the number.

The arithmetic on a real rig

Camera to LED wall, at 60fps, built without thinking about it:

USB camera capture        2 frames
compositing               2
NDI HX encode             4
network (unmanaged)       1
NDI decode                1
LED processor             3
                        ————
                         13 frames ≈ 215ms

Visibly late. The same chain built deliberately:

SDI capture               1 frame
compositing               1
Syphon (same machine)     0
SDI to processor          0
LED processor, minimal    1
                        ————
                          3 frames ≈ 50ms

Nothing exotic changed. SDI instead of USB at the front, Syphon instead of NDI because the destination was on the same Mac, full-bandwidth rather than HX, and a processor with its optional processing turned off.

How to measure it rather than argue about it

The camera-and-clock method takes two minutes and settles every discussion:

  1. Put a millisecond timer on the source — a stopwatch app, or a clapper.
  2. Frame both the source and the destination screen in one phone camera shot.
  3. Record video, then step through frame by frame and read both numbers.
  4. The difference is your real end-to-end latency.

To find which stage is responsible, do it again with a shorter chain. Measure to the local preview first, then after the transport, then at the wall. The stage where the number jumps is the one to work on.

What to fix first

  1. Turn off processing on the display device. Free, often three frames.
  2. Stop using NDI where Syphon will do. Free, two frames, and it gives back CPU.
  3. Do not use HX for anything anyone looks at live. Free.
  4. Raise the frame rate if the show allows it. The same frame count costs less time.
  5. Replace USB capture with SDI. Costs money, saves a frame or two.
  6. Only then look at the network.

Four of those six cost nothing, which is the actual point. Latency in a Mac video chain is usually not a hardware limitation — it is a stack of defaults nobody turned off.

Originally published on the SpectraRig blog.