Skip to content

· 5 min read

NDI or Syphon? Pick by where the pixels are going

Both move video between applications. Both appear as a source list you pick from. In a feature comparison they occupy the same row, which is how they end up being treated as alternatives.

They are not alternatives. Syphon shares a texture that never leaves the GPU. NDI encodes a frame, puts it on a network, and decodes it at the other end. The choice is not about preference — it is about whether the destination is on this machine.

What Syphon actually does

Syphon is a macOS-only convention for sharing GPU textures between processes. The publishing application renders a frame into video memory and hands the receiving application a reference to it. No copy to system memory, no compression, no serialisation.

The consequences:

  • Sub-frame latency. There is no encode step to wait for. The receiver can composite the texture in the same frame it was published.
  • Lossless. Full-range RGB, no chroma subsampling. Text stays sharp, gradients do not band, keys hold their edges.
  • Effectively free. The cost is a texture reference, not a stream.
  • Same machine only. A GPU texture reference means nothing to another computer.
  • Video only. No audio, no timecode, no metadata. If you need synchronised audio, it travels separately.

What NDI actually does

NDI takes a frame, compresses it with a low-latency intraframe codec, and sends it over IP. Every frame is independently decodable, which is why NDI can be joined mid-stream and why its latency stays predictable — there are no long GOPs to wait out.

  • Crosses machines. This is the entire point. Any host on the network can subscribe.
  • Carries more than pixels. Audio, timecode, alpha, tally and metadata all ride along.
  • Discoverable. Sources announce themselves; receivers list them without configuration.
  • Costs bandwidth. Full-bandwidth NDI at 1080p60 sits around 125–150 Mbps per stream. NDI HX, the long-GOP variant, is a fraction of that and costs you latency and quality.
  • Costs CPU or GPU. Encode on the sender, decode on every receiver.
  • Subsampled by default. Full-bandwidth NDI is 4:2:2 8-bit in common configurations. Fine for camera content; visible on hard-edged graphics and thin text.

The decision, reduced

Ask one question: is the receiving application running on this Mac?

If yes, use Syphon. You get the frame with no encode, no bandwidth, no network to fail, and no quality loss. Using NDI to move pixels between two apps on the same machine is paying a compression and networking tax for nothing.

If no, use NDI. There is no other realistic option short of an SDI card and a cable, and if you were going to do that you would already own the card.

That is genuinely most of it. The interesting cases are the ones where the answer changes.

When it is not that simple

The destination is on this Mac, but it does not speak Syphon

Plenty of software has NDI input and no Syphon input — video conferencing clients, some switchers, some streaming tools. In that case you use NDI locally and eat the encode. Loopback traffic does not leave the machine, so bandwidth is not a concern, but the encode and decode cost is real and shows up as CPU under load.

You need one source in several places, some of them remote

Publish Syphon for the local consumers and NDI for the remote ones. Both from the same capture, rather than chaining — do not receive NDI on the same machine that published it and re-publish as Syphon. Every hop is a re-encode.

The content is text or UI

This is where the quality difference stops being academic. Chroma subsampling averages colour across pairs of pixels; thin coloured text on a dark background is exactly the pattern it destroys. If you are sending a scoreboard, lower thirds, a spreadsheet or an application window, keep it on Syphon if you possibly can. If it has to cross the network, send it larger than you need and let the destination scale down, or check whether your tooling can do 4:4:4.

You need audio locked to the picture

Syphon has no audio. If lip sync matters and the two ends are separate applications, NDI’s combined stream is doing you a favour that is worth its cost. Routing audio separately on macOS is entirely possible — that is the job SpectraRoute does — but keeping it in one stream is fewer things to get wrong under pressure.

The hybrid rig, in practice

A typical Mac-based show ends up using both, in specific roles:

  • A window or application captured on the playback Mac becomes a Syphon source for the compositing app. Local, lossless, free. This is what SpectraBridge is for.
  • The composited canvas is split into wall segments and each segment goes out as NDI to a processor or a receiving machine, or over SDI if the destination is a switcher. SpectraMap does both.
  • Cameras and remote contributors arrive as NDI because they are on other machines.
  • Confidence and comfort feeds go out as NDI HX, because nobody backstage needs 150 Mbps of a lectern.

The general shape: Syphon inside a machine, NDI between machines, SDI where the destination is hardware that predates both.

A worked example of the whole pattern: getting ProPresenter onto a second surface without a second Mac uses Syphon locally and NDI only where the destination is another machine.

One habit worth forming

Name your sources for the rig, not for the software. SpectraBridge — Chrome tells an operator nothing at 6pm on show day. Scoreboard (Chrome, PC-1) tells them what it is and where it comes from. This matters more on NDI, where the source list is shared across every machine on the network and will be read by people who did not build the rig.

If NDI is going to carry real load on your show network, the switch configuration matters more than the codec choice — we covered that in NDI on a show network. And if the whole chain feels a frame or two behind, the latency breakdown is worth a read before you blame the transport.

Keep reading

← All writing Try the rig free