NDI Discovery Server for Cloud OBS: Stop Losing Remote Sources

The direct answer

If an NDI camera or graphics machine appears on one network but not another, do not start by rebuilding the Cloud OBS scene. First identify whether the problem is source delivery or source discovery. NDI’s Discovery Server replaces mDNS-based automatic discovery with a central registry, which can be useful where multicast is unavailable or undesirable, including many cloud environments. It helps devices find each other; it does not create bandwidth, repair a failed camera, or make a public stream resilient by itself.

For a StreamableRun production, keep the roles clean. Local or remote NDI infrastructure supplies a source to the production side. Cloud Hosted OBS uses the approved source in named Main, Backup, and safety scenes. StreamableRun manages the program and destinations. The producer needs a route that remains understandable when discovery disappears, not a single giant network diagram that mixes source search, video transport, public output, and chat coordination.

Choose a Discovery Server when your team has a specific discovery problem: separated subnets, an environment where multicast is constrained, or many sources where manual discovery is becoming noisy and unpredictable. Do not deploy it because it sounds more professional. A small single-switch show with stable mDNS may need less moving parts, not more.

Separate discovery from the actual media path

A source list is not a confidence monitor. Discovery tells a receiver that a sender exists and how to find it. Once sender and receiver connect, the media follows its own path. That distinction matters during an incident: a source can be listed but black, connected but late, or absent from the list while a backup source is perfectly usable. Put these conditions in different columns on the producer card.

Start with a simple inventory: source name, physical location, sender address or host, receiving production machine, intended Cloud OBS scene, backup scene, and owner. Avoid anonymous names such as `CAMERA` or `NDI SOURCE`. A producer who sees `Venue-Podium-PTZ` and `Venue-Podium-Backup` can make a decision. A producer who sees twelve nearly identical device names has to call an engineer while the audience watches.

Keep output monitoring separate again. A discovered NDI camera does not prove the Cloud OBS program is correct, and a correct program does not prove Twitch, YouTube, Kick, or a custom destination is accepting it. Assign a source operator, a producer, and a viewer-side verifier. That division is the practical advantage of an operating plan: each person has one layer to confirm.

• Discovery: can the receiver find the sender?
• Delivery: is moving video and audio reaching the source?
• Program: is the intended scene correct in Cloud OBS?
• Destination: can a viewer actually play the public output?

Design the registry before you point clients at it

Give the Discovery Server a stable, documented address and record who owns it. The NDI documentation explains that clients can be configured through Access Manager to use the Discovery Server instead of mDNS for locating sources. That is an infrastructure decision, so do it during setup and rehearsal, not by passing an IP address around in a producer chat five minutes before a live show.

Use source groups and names as an operational boundary. A remote guest, a venue camera, a graphics machine, and an engineering test source do not need to live in one undifferentiated list. A clear group lets a producer know which sources are approved for the show and which are still being tested. It also lowers the chance that someone takes an engineering preview to air because its name happened to be near the real camera.

Redundancy is a reasoned choice, not an automatic safeguard. NDI documents support for configuring more than one Discovery Server, so source visibility can survive one registry failure. Test that behavior in the exact client versions and network layout you use. A redundant registry cannot compensate for a production machine that cannot reach the media sender, and it does not replace a backup scene that the producer can take immediately.

• Use a stable address and named owner.
• Configure clients during rehearsal.
• Group approved show sources separately from tests.
• Test registry redundancy separately from media failover.

Build Cloud OBS scenes around known states

Create three camera states in Cloud Hosted OBS: primary source, known backup source, and a safety scene that does not depend on either source. The safety scene can be a clear BRB card, program audio, and a message route for the producer. It should be ready before the first NDI source is selected. This matters because discovery problems often tempt teams to click through source lists while a black frame is public.

Keep scene labels literal. `Main — Podium PTZ`, `Backup — Wide HDMI`, and `Safety — Hold` are useful labels. Add one short note to the producer packet describing what each scene preserves: program audio, remote guest, lower third, or fallback clip. A fancy scene collection is not a recovery plan until a second person can use it without remembering why the first person built it.

When a remote source is available, test it with movement, speech, and the exact graphics layer you expect to use. A static still can conceal a frame-rate, audio, alpha, or timing problem. Use a private StreamableRun destination for the rehearsal, then have a verifier watch the program from an ordinary browser or device. That is how you catch a clean source that still looks wrong after the full production chain.

• Primary NDI scene.
• Known backup input scene.
• Source-independent safety scene.
• Viewer-side verification on a private destination.

Triage a missing source without random changes

When a source vanishes, first ask whether it disappeared from discovery or merely stopped delivering media. If it is missing from the registry, the infrastructure owner checks server reachability and client configuration. If it is listed but unusable, the source owner checks the sender and network path. Meanwhile, the producer moves to the approved backup or safety scene. These tasks can run in parallel because they are different layers.

Do not restart every component in sequence just to feel busy. Restarting the production machine can discard the one working preview you need. Reconfiguring destination output cannot fix an NDI discovery issue. Asking the field streamer to reconnect an SRT phone source will not restore a venue camera. Give each owner a narrow first action and a time-bounded update request.

Use clear calls: `source missing from registry`, `source visible but not usable`, `program on backup`, and `destination verified`. Those phrases preserve evidence without pretending to know the root cause. Once the primary returns, preview it privately, confirm motion and audio, then take it back only when the producer and viewer-side verifier agree it is safe.

• Classify discovery versus media delivery.
• Protect program before diagnosis.
• Assign a narrow action to each owner.
• Preview a recovered source before returning it to air.

Rehearse the failure you are trying to prevent

A real rehearsal includes a controlled discovery failure. In a private window, point a test client away from the registry or stop the test service according to the approved procedure. Confirm the producer recognizes the missing source, moves to the right scene, and does not disturb working destinations. Then restore the service and verify that the source returns with the correct name and group.

Run another test where discovery remains healthy but the source sends bad media. This is the more useful distinction because it proves the team is not treating the source list as a health check. The output verifier should report whether the public program remained usable while the source owner restores the camera or graphics machine.

Write down the recovery time, the commands that were actually used, and anything that surprised the team. Do not turn the record into a fake benchmark. It is a show-specific runbook. The next producer needs to know which backup scene worked, who owns the registry, and where to look for a source without making an untested network change.

Other resources

Read the NDI documentation before deploying Discovery Server and use it to verify client configuration, redundancy, and the distinction between discovery and the media connection. Pair that material with a live-show diagram that names your own source owners, scenes, backup inputs, destinations, and communication path. The documents explain the tool; the diagram makes it runnable under pressure.