NDI 6.3, NDI Bridge, and Cloud OBS for Remote Stream Production

The direct answer

NDI is great for moving video around a local production network. It is not automatically the right way to send an IRL field feed into a cloud server. NDI 6.3 matters because NDI's own release notes call out sender monitoring enhancements, improved discovery server capabilities, and fixes around NDI HX encoding performance and Bridge behavior. Those are real operator improvements for teams with bigger NDI networks.

For StreamableRun, the useful model is local NDI where it fits, then a tested contribution feed into Cloud Hosted OBS. If your cameras, laptops, replay machine, or local OBS instance are on the same LAN, NDI can be clean. When the production needs to reach StreamableRun, use a bridge, encoder, local OBS output, SRT, RTMP, or another tested contribution path. Do not assume a LAN discovery protocol will behave like a public ingest protocol.

The best StreamableRun workflow is usually NDI inside the venue, then one controlled feed into StreamableRun. Cloud OBS becomes the public operating layer: scenes, fallback, clips, destination routing, monitoring, and remote producer handoff.

What NDI 6.3 changes for operators

NDI 6.3 is mostly an operations and visibility story, not a reason to rebuild every live workflow overnight. NDI's release notes list sender discovery and monitoring improvements, Discovery Server improvements, and fixes including poor NDI HX encoding performance on AMD GPU and CPU systems in Screen Capture HX and NDI Bridge.

That matters when a team has several NDI senders and receivers on a network. If cameras, screen captures, local OBS outputs, replay machines, and remote bridges are all in play, discovery and monitoring are not optional. The hard part is knowing which source is healthy before the producer cuts it live.

For streamers, the practical takeaway is simple: if your venue stack uses NDI, update and test it like infrastructure. Verify discovery, naming, source visibility, Bridge behavior, and CPU or GPU load. Then decide how the final program gets into StreamableRun. The NDI update helps the local network; it does not replace your cloud ingest plan.

• Test sender discovery after updating NDI Tools or Runtime.
• Name sources clearly so Cloud OBS operators do not see mystery feeds.
• Check NDI HX performance on the exact machine and GPU class you will use.
• Use monitoring to catch missing or stale sources before cutting them live.
• Keep the StreamableRun contribution path separate from local NDI discovery.

DistroAV and OBS

DistroAV, formerly known as OBS-NDI, is the common OBS plugin path for NDI source and output workflows. The OBS forum resource describes three integrations: adding NDI sources into OBS, transmitting the main program view over NDI, and adding an NDI filter to output a parent source.

That is useful in local production. A producer can bring an NDI camera into local OBS, send local OBS program out over NDI, or use NDI as a clean handoff between machines. It is also a place where version mismatch hurts. NDI Runtime, DistroAV, OBS version, operating system, and network discovery all need to match the plan.

With StreamableRun, DistroAV is usually part of the local side. You might receive NDI sources in a local OBS scene, then send local OBS to StreamableRun as SRT or RTMP. Or you might use StreamableRun output back to local OBS for recording or special plugins. Be precise about direction. NDI into local OBS and StreamableRun ingest are different legs.

• Use DistroAV to bring LAN NDI sources into local OBS.
• Use DistroAV to send local OBS program or selected sources over NDI on the LAN.
• Do not expose NDI source names or production networks casually.
• Match OBS, DistroAV, and NDI Runtime versions before a paid show.
• Convert to SRT, RTMP, or another contribution path when sending to StreamableRun.

NDI Bridge is not a universal ingest

NDI Bridge is designed to connect remote NDI infrastructures over a wide-area network. NDI's Bridge docs describe remote interconnection and mention video transcoding for internet transmission using H.264 or HEVC compression. That is useful for teams that want to extend an NDI environment beyond one LAN.

But Bridge is not the same as a streamer-facing ingest URL. It still requires compatible NDI tooling, network setup, source selection, discovery, and monitoring. For many StreamableRun workflows, it is cleaner to use NDI locally, then publish one program feed from local OBS or an encoder to StreamableRun over SRT or RTMP.

Use Bridge when the production team truly needs remote NDI sources inside an NDI workflow. Use StreamableRun ingest when the job is to bring a finished field or venue feed into Cloud OBS for public production. If those sound similar, draw the route on paper before building it.

• Bridge remote NDI networks when both sides need NDI-native production.
• Do not use Bridge as a last-minute replacement for a tested SRT or RTMP ingest.
• Watch bandwidth and CPU/GPU use when Bridge transcodes.
• Test source discovery after reconnects and network changes.
• Keep a simple StreamableRun ingest route ready for the public program.

Where StreamableRun fits

StreamableRun should be the point where the production becomes public-facing and recoverable. If the local room has NDI cameras, a replay machine, a slide laptop, and a local OBS instance, those can all stay local. The local technical director sends one program feed into StreamableRun. Cloud OBS adds the parts that need remote operation: overlays, clips, fallback, destination management, and moderator control.

This is especially useful when the local venue is busy. A producer outside the venue can watch the public output, switch Cloud OBS to fallback if the local program stalls, restart a destination, and monitor StreamableRun without remote-desktoping into a laptop under a table.

It also gives the team better access boundaries. The local NDI network does not need to be shared with every moderator. The platform keys do not need to be stored on the local switching laptop. The streamer can hand off production control without handing out the whole venue network.

• Local network: NDI cameras, screen captures, replay, local OBS, and internal monitors.
• Contribution leg: one tested SRT, RTMP, or encoder output to StreamableRun.
• Cloud layer: Cloud OBS scenes, fallback, clips, destinations, and monitoring.
• Producer layer: remote controls, viewer-device checks, destination restarts, and recovery notes.
• Security layer: keep NDI network access, StreamableRun access, and platform keys separated.

A practical NDI to Cloud OBS route

One clean route is NDI sources into local OBS, local OBS program to StreamableRun, StreamableRun Cloud OBS to destinations. Local OBS becomes the bridge between a LAN production and cloud production. That does not mean local OBS owns the public show forever. It owns the local composition job.

Another route is hardware encoder to StreamableRun while NDI stays in the venue for monitoring or secondary feeds. For example, a Magewell, ATEM, or YoloBox-style encoder can send the program feed out while NDI sources stay available to local operators. Pick the route that the team can support under pressure.

Do not route every NDI source into Cloud OBS if the cloud producer only needs the program feed and a backup. More sources can mean more confusion, more monitoring work, and more ways to cut the wrong thing. Send what the cloud producer needs to operate the public show.

• Route one: NDI cameras to local OBS, local OBS to StreamableRun.
• Route two: NDI local monitoring, hardware encoder program to StreamableRun.
• Route three: StreamableRun output back to local OBS only when local recording or plugins require it.
• Backup route: phone or second encoder into StreamableRun as a separate ingest.
• Do not build a route that only the network engineer can restart.

Monitoring checklist

NDI workflows need monitoring at each layer. The source can be alive while discovery is broken. Discovery can work while the receiver has no audio. Local OBS can look clean while the StreamableRun ingest is unstable. StreamableRun can be healthy while one platform destination is buffering.

Assign each screen a job. NDI monitoring watches local source health. Local OBS watches composition. StreamableRun watches ingest and Cloud OBS. The platform dashboard watches destination state. A normal viewer device watches what the audience sees. One producer cannot stare at all of that forever, so write down which signal triggers which recovery action.

The worst NDI failure is not a dramatic black screen. It is a stale source that looks present but is not current. During rehearsal, freeze a source, disconnect it, reconnect it, and rename it. Make sure the operator knows what stale, missing, and healthy states look like before the show.

• Verify source discovery and source freshness.
• Check audio on the receiver, not only video.
• Watch CPU, GPU, and network load on the NDI machines.
• Confirm StreamableRun ingest state separately from local OBS preview.
• Use a viewer device for final confirmation before returning from fallback.

Failure drills

Run failure drills that match the real weak points. Kill an NDI source. Restart local OBS. Disconnect the Bridge session if you use one. Change a camera name. Drop the StreamableRun contribution feed. Restart one destination. Then write down how the producer recovered.

The correct response is usually to protect the public output first. If a local NDI source disappears, the local operator can switch to another source or local slate. If the whole local program feed disappears, the StreamableRun producer cuts to fallback or backup ingest. If one destination breaks, the cloud producer restarts it while the local show continues.

NDI can make a production feel smooth when everything is on the same LAN. StreamableRun makes the public broadcast more operable when that local system has a bad minute. Use both for the job they are good at.

• Drill source loss: one NDI camera disappears.
• Drill receiver loss: local OBS loses an NDI input.
• Drill bridge loss: remote NDI path drops.
• Drill contribution loss: local program stops reaching StreamableRun.
• Drill destination loss: Twitch, Kick, YouTube, or custom RTMP needs a restart.
• Pass condition: the producer knows whether to fix local NDI, cloud ingest, or platform output.

Other resources

Use these resources to verify current NDI release behavior, Bridge setup, OBS plugin capabilities, and StreamableRun production features before relying on an NDI-heavy workflow.