When NDI is enough — and when it isn't.

Start by assuming NDI wins

Bridge receives the cameras and republishes the program over NDI, SRT, RTSP, HDMI and directly into OBS. NDI alone reaches OBS, vMix, Wirecast, ProPresenter, Resolume, TouchDesigner, Unreal Engine and Zoom. If your target appears on that list, you are finished: install a free app, enable an output, pick a source in a menu.

This is not a consolation prize. It is a well-tested path with no code to maintain, and it should be the default answer.

Four reasons to write your own

Each of these is a real limitation of the republished path, not a matter of taste.

1. You want the control channel. This is the strongest reason. NDI carries pictures. It does not carry the camera's ISO, shutter, white balance, lens position, or its tally state — and it certainly doesn't let you set them. If your integration needs to drive the camera or react to what it's doing, the protocol is the only route.
2. You want the Mac out of the chain. The republished path implies a machine running Bridge. For a headless install, an embedded box, or a product you ship to someone else, that's an extra computer you may not want to specify.
3. You're paying for hops you don't need. Decode, re-encode to NDI, decode again — each stage adds latency and CPU. Receiving directly means decoding once, into whatever you already have.
4. You want frames, not a video source. If the destination is a model, a texture, or an analysis pipeline, pulling frames back out of a broadcast stream is more work than parsing a small protocol in the first place.

Reasons that look convincing but aren't

• "NDI is heavy on the network." On a wired local network sized for production, this is rarely the binding constraint. Measure before you rearchitect.
• "I'll get better quality." You will avoid a re-encode, which is worth having — but the camera's stream is what it is. A direct receiver doesn't create detail that was never sent.
• "Writing it is a big project." It isn't, and that is the point of publishing the spec: a fixed header plus JSON, buildable in an evening with an assistant. Don't let this scare you off a genuinely better design.

A decision you can make in a minute

1. Does your target take NDI or SRT, and do you only need pictures? Use Bridge. Stop here.
2. Do you need tally or camera control, in either direction? Write a receiver. Nothing else exposes it.
3. Is a Mac in the chain unacceptable for your deployment? Write a receiver.
4. Are frames going into code rather than onto a screen? Write a receiver.
5. Otherwise, use Bridge and revisit if a real constraint shows up.

You are allowed to do both

These are not exclusive, and the mixed setup is often the right one. Let Bridge handle the program feed to your screens and your stream, and run a small receiver alongside it for the thing that needs the control channel — an automation, a monitor, an analysis pass. The camera can serve a receiver in control-only mode without sending video at all, which makes that second connection cheap.

Whatever you choose, the constraints are the same: no audio in the protocol, local network for discovery, and the receiver password is access control rather than encryption.