OBS NDI Black Screen: Discovery, Frames & OBS Fixes | Callaba
More live video workflow notes and product updates.
An OBS NDI black screen is a boundary problem, not one diagnosis. The sender may be idle, discovery may point to the wrong source, OBS may have an incompatible NDI plugin or runtime, the network may pass discovery but not media, or frames may arrive without being rendered. Check those boundaries in order and keep the OBS log beside the picture.
Trace discovery and video as separate paths
Callaba can verify its NDI side of the path
Callaba lets an operator choose NDI interfaces and discovery servers, synchronize the discovered-device inventory, and inspect whether a saved device is currently discovered. It can also publish supported Callaba inputs as named NDI outputs through NDI adapters. This is useful when Callaba is the sender, receiver, or routed production gateway.
| Question | Callaba check | What still belongs in OBS |
|---|---|---|
| Is the expected source visible? | Synchronize NDI discovered devices and compare the exact name | Confirm DistroAV lists and selects that same name |
| Is the correct network selected? | Review explicit NDI interface and Discovery Server settings | Check the OBS host interface, route and firewall |
| Is Callaba publishing an output? | Start the NDI adapter and inspect its runtime state | Prove received frames and rendering in the OBS log and canvas |
Callaba cannot repair a missing local DistroAV binary, an incompatible NDI runtime, a hidden OBS source, or a host-specific graphics problem. Use its discovery and adapter evidence to narrow the fault. Then finish the receiver-side checks on the OBS machine.
Confirm the current plugin and runtime as one set
The maintained OBS integration is DistroAV, formerly OBS-NDI. Its current upstream requirements list OBS 31.1.1 or higher and NDI Runtime 6.3 or higher. Treat those as a matched baseline, not permission to mix an old plugin binary with a new OBS build.
Open the OBS log immediately after launch. Verify that DistroAV loaded, note its version, and look for a missing runtime, duplicate legacy plugin, unsupported architecture or initialization error. If the NDI source type is absent from the Add Source menu, the problem comes before discovery and media. Reinstall from the upstream package for the host platform, remove a conflicting legacy OBS-NDI installation according to upstream guidance, restart OBS and capture a fresh log.
Prove that the sender is producing changing frames
A discoverable source can still be idle. Put an obvious clock or moving test pattern on the sender, confirm that its NDI output is enabled, and record the exact machine and source name. If the sender exposes programme, preview and dedicated outputs, do not assume they share a name or activation rule.
Test the source in a second receiver on the OBS host. A moving image there proves considerably more than a source appearing in a dropdown. If it is black everywhere, inspect the sender's active output, tally or visibility behaviour, supported pixel format and its own log before touching scene transforms in OBS.
Discovery can work while the media route fails
NDI discovery and NDI media do not prove each other. Local discovery commonly uses mDNS, while an NDI Discovery Server provides a centralized registry and is useful across routed or cloud networks where multicast discovery is unavailable. A sender configured for a Discovery Server may not advertise itself through mDNS, so all intended participants need a consistent plan.
Record the sender and receiver IP addresses, selected interfaces, subnet or VLAN, Discovery Server address and host firewall policy. Avoid testing through an accidental Wi-Fi, VPN or management interface. If the name appears but frames do not, capture traffic or interface counters during a short test and compare them with the sender's transmit state. Do not open broad firewall ranges as a first experiment; define the required NDI paths for the installed version and production topology.
Refresh a stale source selection
Renaming a sender, cloning a workstation or switching discovery modes can leave an OBS source pointed at an old identity. In DistroAV, re-open the NDI Source properties and select the currently advertised source by its complete name. If two senders expose similar labels, rename them deliberately rather than relying on list order.
Create a temporary empty scene with one new NDI Source. Keep its transform at the default, make it visible, place it above opaque layers and watch both the canvas and the log. A fresh source that works while the original stays black isolates the problem to saved scene state rather than the network.
Separate received frames from OBS rendering
If another receiver works and DistroAV reports frames, the remaining fault is likely inside the OBS source or render path. Confirm the eye icon is enabled, the source is inside the current scene rather than only a different nested scene, opacity is nonzero, crop has not removed the image, and the transform is within the canvas. Use Reset Transform and Fit to Screen for a temporary check.
Then test a new scene collection or a portable OBS profile without production plugins. Keep the original untouched for rollback. If only one graphics API, GPU selection or HDR/pixel-format combination fails, preserve the working minimal case and compare OBS logs rather than applying several changes at once.
Do not mistake a held frame for recovery
Current DistroAV releases can keep the last received image after disconnection. That makes a frozen picture possible even though the network feed has stopped. Add motion or a time overlay to the source, and verify that received-frame or packet counters continue to increase. A static logo alone is a poor health check.
Define separate alerts for source missing, bytes not advancing, frames not advancing and OBS render delay. Those signals distinguish discovery loss from an idle sender and from a local rendering bottleneck.
Example: OBS lists the NDI source, but the canvas is black
The source name appears in DistroAV, so the operator first suspects scene ordering. A second receiver on the same machine also shows black. The sender says its dedicated NDI output is active, but network counters on the intended production interface stay flat. The sender was registered with a Discovery Server, while its media route followed an old interface after a VLAN change. Correct the sender interface and route, then verify moving video in the independent receiver, increasing DistroAV frame activity and an advancing picture in OBS. Discovery was healthy; the media path was not.
Use a repeatable black-screen checklist
- Save evidence. Export the OBS log and record OBS, DistroAV and NDI Runtime versions.
- Verify the sender. Add a moving test signal and confirm the exact active NDI output name.
- Cross-check reception. Open the source in a second receiver on the OBS host.
- Inspect discovery. Confirm mDNS or Discovery Server configuration and the selected interfaces.
- Inspect media. Compare sender transmit state, interface traffic and receiver frame activity.
- Reduce OBS. Test one new source in an empty scene with a default transform.
- Verify recovery. Restart the sender and confirm the picture resumes without a stale held frame.
OBS NDI black-screen FAQ
Why does OBS see an NDI name but show no video?
Discovery can succeed while the sender is idle or the media route is blocked. Prove moving frames in another receiver before changing the OBS scene.
Is OBS-NDI still the current plugin name?
The maintained upstream project is now DistroAV. Remove conflicting legacy installations and follow the requirements published for the current DistroAV release.
Should every NDI network use a Discovery Server?
No. It is valuable for routed, large or cloud networks and where mDNS is unsuitable. Use one coherent discovery design rather than mixing settings accidentally.
Can Callaba fix a black DistroAV source in OBS?
Callaba can expose evidence about its NDI interfaces, discovery and adapters. Local plugin, runtime, scene and graphics faults still need to be resolved on the OBS host.