NDI HX vs NDI High Bandwidth for Remote Production and Cloud OBS

The direct answer

Use NDI High Bandwidth when a managed local production network has capacity and the team wants the low-latency, high-quality source behavior that its receivers support. Use NDI HX when bandwidth, remote transport, or lighter receivers make compression necessary. Neither choice replaces the separate job of getting a reliable program feed into StreamableRun.

NDI's current documentation says a typical 1080p60 High Bandwidth NDI stream can reach 150 Mbps and recommends dedicated, high-availability network capacity for production. Its Bridge documentation says Local Mode can transcode High Bandwidth sources to HX using H.264 or HEVC, and that remote transport settings affect GPU use, bandwidth, and compatibility. That is the actual choice: network capacity and operating cost, not a badge on the camera.

For most mobile or distributed shows, keep NDI inside the location where it is easy to observe. Use one tested SRT, RTMP, or hardware-encoder contribution feed to StreamableRun. Cloud Hosted OBS then owns public scenes, fallback, destinations, monitoring, and producer handoff.

What the names actually tell you

High Bandwidth NDI is the local-network choice when image quality, low latency, and intra-frame behavior matter more than conserving every megabit. NDI documents it separately from HX and lists its own interoperability expectations. It is comfortable in a venue where cameras, a switcher, replay, and local OBS live on a properly designed network.

NDI HX is the compressed family. In NDI Bridge, HX can use H.264 or HEVC and shifts part of the decision toward encoder support and GPU capacity. It is useful when a link is constrained or when a receiver cannot live with a High Bandwidth source. It is not free: encoding can add load, format support varies, and every extra transcode is another place to rehearse.

Do not treat HX1, HX2, and HX3 as interchangeable names. NDI's documentation calls HX1 legacy and says it will be discontinued over time. Inventory the actual camera, decoder, runtime, and receiver before promising a format to a producer.

Start with the network, not the codec

Map the route before choosing a setting. A High Bandwidth camera on a gigabit production switch may be sensible. The same camera crossing venue Wi-Fi, a hotel uplink, and a remote laptop is a different job. Count simultaneous sources, program monitoring, intercom, control traffic, and the headroom that disappears when an audience joins the venue network.

NDI's bandwidth guide explicitly says NDI is not deterministic and that required capacity should be based on expected average utilization. That means a one-minute idle test is not proof. Test the busiest scene: fast motion, graphics, all cameras active, a replay, and every remote receiver subscribed. Watch the switch and the host machine instead of trusting a calculator.

For IRL and remote shows, assume the last mile is the least polite part of the network. Protect the public show by converting the planned program into a contribution protocol that the StreamableRun operator can monitor. Keep the NDI network private and narrow.

• List every NDI sender and every receiver before estimating capacity.
• Test peak action, not a static color bars feed.
• Separate production networking from venue guest Wi-Fi where possible.
• Watch switch ports, host CPU/GPU, and receiver freshness together.
• Make one program feed the public contribution route, with a second source ready for recovery.

Bridge is a transport choice, not an automatic tunnel

NDI Bridge can connect NDI environments over the public internet, and its deployment documentation describes remote mode, encryption, groups, logs, and transcode choices. That is useful for a real multi-site NDI production. It is not an excuse to send every local source across a shaky route because the button exists.

Bridge Local Mode can convert High Bandwidth sources to HX. If you choose that path, pick the GPU deliberately. NDI says Bridge supports Intel Quick Sync or NVIDIA NVENC for its hardware encoding options and exposes logs for bandwidth, round-trip time, buffer delay, and GPU information. Put those logs in the technical rehearsal, not in a folder nobody opens after failure.

If the remote side only needs the finished program, send the finished program. A remote producer normally needs a dependable public output, a backup, and a way to recover—not six camera sources to accidentally cut live.

Compatibility and color are production decisions

NDI 6 documentation describes HDR support for High Bandwidth and HX2/HX3, but it also requires an HDR option to be controllable because not every receiver is compatible. That is the right instinct for streaming: HDR should be an intentional end-to-end decision, not something that happens because one source can send it.

If your public destinations and Cloud OBS scene package are SDR, make a clean SDR program. If you are running HDR, verify camera, NDI source, bridge or receiver, OBS scene, encoder, and destination together. A color mismatch will look like a creative mistake to viewers even if each individual box says it supports HDR.

The same applies to audio. HX and High Bandwidth workflows may behave differently across older receivers. NDI notes an NDI 4 compatibility option in Bridge that changes audio behavior for older endpoints. Keep an audio confidence check on the exact receiving path.

• Choose HDR only when the whole route supports and has been tested for it.
• Name the color space and frame rate in the source label.
• Keep an SDR fallback scene and a known-good H.264 contribution profile.
• Test audio on the final receiver, not just on the sender.
• Avoid changing NDI formats during a public segment.

A practical StreamableRun route

A reliable layout is simple: cameras and local machines use NDI on the venue LAN; a local director or encoder builds the program; that program goes to a named StreamableRun ingest; Cloud Hosted OBS takes over public graphics, fallback, clips, destination routing, and remote operation. The field team can stay focused on sources while a remote producer protects the audience experience.

Use a second ingest for the backup, not a second guess. It might be a lower-bitrate local OBS output, a hardware encoder, or a phone feed. Label it as backup in Cloud OBS and rehearse the switch. If NDI discovery fails, the local team repairs NDI while the StreamableRun producer decides whether the public program needs fallback.

Keep destination keys in the cloud production layer. A local NDI laptop should not need every Twitch, YouTube, Kick, and sponsor RTMP secret just because it sits near the cameras.

• Venue LAN: NDI High Bandwidth where capacity supports it, or HX where the local route needs compression.
• Program layer: local OBS, switcher, or encoder with named source and backup states.
• Contribution: tested SRT or RTMP into StreamableRun.
• Cloud layer: Cloud OBS scenes, destination control, fallback, clips, and monitoring.
• Producer handoff: one runbook that identifies whether a fault is NDI, local program, cloud ingest, or platform output.

Failure drills that make the choice real

During rehearsal, subscribe an extra receiver and watch what happens. Disconnect the preferred NDI sender. Restart the Bridge process if you use Bridge. Load the GPU with the exact transcode choice. Change from calm footage to motion. Then interrupt the contribution feed and make the cloud producer use fallback and return.

Write down which metric moved first: NDI receiver freshness, Bridge buffer, GPU load, local OBS frame loss, StreamableRun ingest health, or platform preview. That gives the producer an actual first action next time. 'The video looks weird' is not a recovery plan.

The better format is the one your crew can observe, restart, and explain under pressure. High Bandwidth NDI often wins inside a prepared LAN. HX often wins when bandwidth is genuinely constrained. StreamableRun wins the public-operations role by keeping both local choices behind a stable production layer.

• Add a receiver and test the realistic peak load.
• Remove a sender and verify the local director sees a clear failure.
• Force the contribution route down and practice Cloud OBS fallback.
• Confirm the backup ingest is usable without re-entering platform keys.
• Record the recovery owner and pass condition for each test.

Other resources

Use these NDI primary sources to verify current format support, Bridge behavior, and bandwidth assumptions for your exact hardware and runtime. Rehearse the public contribution route separately from the NDI network.