Streamlabs Desktop can receive an NDI feed as a source, but it does not create or send that feed by itself. First, a separate sender application must transmit video over your local network; then you can select its active stream in a Streamlabs scene.
The key prerequisite is the NDI SDK redist on both computers, followed by a reboot. If you use Streamlabs Desktop version 1.20.6 or later, its receiving guide calls for NDI SDK 6 or higher.
What you need before receiving NDI
Think of this as two jobs on two ends of a local network. The sender captures something, such as an OBS output, a screen region or mobile video, and transmits it as NDI. Streamlabs Desktop on the receiving computer discovers that transmission and adds it to a scene as a source. Starting Streamlabs alone does not make an NDI feed appear.
Before installing anything, identify which computer will send and which will receive. They may be separate machines, or sender software and Streamlabs may run on one computer if the software path supports that arrangement. The receiver instructions specifically ask for the NDI redist on the receiver computer and on the computer running the sender. If you have two machines, do not install only on the Streamlabs machine and assume the sender has everything it needs.
You also need an application that can actually transmit an NDI stream. Streamlabs’ receiving guide does not require one particular sender. Its related guides describe OBS Studio 31 or later with the DistroAV plugin and NDI Runtime 6 as one desktop route, and Scan Converter 2, vMix or a mobile device as other sender possibilities. See Streamlabs’ OBS Studio NDI output guide and its guide to Scan Converter 2, vMix and mobile senders for their respective setup details.
Choose the sender according to what you want to receive. If you want a composed OBS programme output, an OBS-based sender is a natural fit. If the goal is to show a computer screen or selected area, a screen-capture sender may suit it better. A mobile sender may be appropriate for a camera feed. None of those choices changes the receiver’s basic job: it can only select a stream that another application has made available.
It helps to keep the purpose narrow while testing. Send a simple, recognisable image before building a complicated scene or relying on audio. If a test image cannot be found, adding more overlays or changing scene layout will not solve discovery. If you are planning a continuous YouTube channel, this local NDI hand-off is only one part of the wider broadcast setup; the OBS workflow for streaming Indian folk music around the clock covers a different stage of that work.
Install the NDI SDK redist on both computers
Streamlabs’ receiver instructions call for the NewTek NDI SDK redist on the receiving computer and on the computer that runs the sender. Obtain the appropriate redist from the official NDI or Streamlabs instructions and follow its installer prompts on each machine. Avoid substituting an unrelated plugin package or an older runtime simply because it appears in a search result: the version requirement for this receiving workflow is specific to Streamlabs Desktop.
If sender and receiver are separate computers, make a small checklist: redist installed on sender, redist installed on receiver. If they are the same computer, install the prerequisite for that computer and restart it after installation. In either arrangement, keep track of which machine you are checking; otherwise it is easy to confirm the receiver and overlook the sending side.
A redist is a software dependency, not the NDI sender itself. Installing it does not capture your desktop, select an OBS scene or begin transmission. You still have to configure the chosen sending application and start its output. Likewise, installing sender software does not add a received feed to Streamlabs automatically. The two applications perform different parts of the route.
For a channel built from recorded material, NDI may be useful when one application needs to hand a live picture to another, but it is not the same thing as sending a video file directly to YouTube. Decide whether you actually need a local feed between applications. If the goal is simply to loop a finished file, the guide to streaming pre-recorded videos with FFmpeg on Linux describes a separate approach.
Reboot and check the version requirement
After installing the redist, reboot the relevant computer or computers before testing. Streamlabs explicitly includes a reboot in its receiving procedure. A machine that has not restarted can leave you chasing a missing source even though the installer appeared to finish normally.
Next, check the Streamlabs Desktop version on the receiving computer. The current Streamlabs receiver article says that Streamlabs Desktop 1.20.6 and later requires NDI SDK 6 or higher. Keep the qualification attached to the number: it is the requirement stated for those versions of the receiving application. Do not carry over older runtime advice from a different OBS plugin guide as though it replaced this Streamlabs-specific requirement.
If you cannot tell whether your installed redist meets the SDK requirement, return to the official receiving instructions and verify the installed package against the version of Streamlabs Desktop you use. Do not guess from a sender tutorial alone. The sender can have its own plugin and runtime requirements, while the receiver still needs the prerequisite stated in Streamlabs’ receiving documentation.
The check that separates receiver setup from sender setup is straightforward: can the sender application show that it is actively outputting an NDI stream before you open the source properties in Streamlabs? If not, you are still configuring the sender. If it is transmitting but Streamlabs cannot list or display it, focus on receiver installation, discovery and network permissions. This saves time because the same blank preview can result from failures at either end.
Start the NDI stream on the sender
On the sending computer, open the sender application and configure the output you intend to share. The exact controls depend on the application. In an OBS-based route, the output is created with the relevant NDI sending plugin; a screen utility instead transmits a display or region; a mobile route sends from the device. Streamlabs Desktop is not a substitute for these sender controls.
Start the NDI output and leave it running while you configure the receiver. Use a clear test scene or image so you can distinguish a working feed from a frozen or black output. If the sender offers separate programme and preview outputs, choose deliberately: the receiver will display what that sender output provides, not necessarily everything visible on the sender’s monitor.
Check the audio path separately from the picture. Do not assume that every kind of sender output carries audio in the same way. Streamlabs notes, for example, that audio from an OBS Browser source using the Dedicated Output NDI filter is not transmitted because of Browser source limitations. If your chosen route has that limitation, arrange another audio method and verify it independently rather than diagnosing an audio-only problem as failed video discovery.
A useful hand-off test is to keep the sender visibly active, then move to the receiving computer and look for the stream by its sender-provided name. If the sender has an output status or preview, confirm that first. If the source is absent in Streamlabs, you have not yet proven that the receiver is at fault; the sender may not be outputting, may be targeting another output, or may have stopped.
Add the NDI source in Streamlabs Desktop
Once the sender is transmitting on the local network, open Streamlabs Desktop on the receiving computer and select the scene where the feed belongs. In the Sources panel, click the + icon above the list and add NDI Source. In the source properties, choose the active stream you want to receive.
Streamlabs says active NDI streams on the local network are detected automatically. In normal setup, that means you should not have to type a source address into the source properties. Select the named stream from the available choices, apply the source, and check that it appears in the scene preview. If several senders are active, use a recognisable name or stop unrelated test senders temporarily so you can identify the intended one.
Then confirm how the source sits in the scene. A source can be present but covered by another layer, scaled outside the visible canvas or placed in a different scene from the one you are viewing. Check the source list and layer order as well as the preview. These are scene-layout problems, not evidence that NDI discovery failed.
If the feed is visible, test movement and any expected sound before proceeding. A still image could be a paused sender output; a moving image without audio could reflect the sender’s audio path rather than a receiving error. Once the source behaves as expected, save the scene and avoid changing several unrelated settings at once. A small, controlled test is easier to repeat after a reboot.
NDI is a local hand-off, not a requirement for every always-on channel. If your immediate aim is a file-based broadcast and you want your computer off, StreamNeo turns an uploaded video into a 24/7 YouTube live stream, removing the need to keep a local sender and receiver chain running for that file-based route. It does not receive NDI and is YouTube-only, so keep it distinct from this Streamlabs workflow.
Test discovery and troubleshoot a missing feed
Troubleshoot in order, starting with the sender. Confirm that its application is open and its NDI output is active. Then check that both machines are connected to the same intended local network and that neither has switched to a guest or public network profile. Streamlabs’ receiving guidance specifically says to ensure both computers use the private network profile.
If NDI Source is missing from the add-source list, return to the SDK installation and reboot steps. Streamlabs identifies an incorrect NDI SDK installation or a missed reboot as causes to check when the source is unavailable. Verify the redist on both the sender and receiver, especially if you have recently updated Streamlabs Desktop to version 1.20.6 or later and need SDK 6 or higher.
If NDI Source exists but the sender’s stream is not listed, check whether the sender is actually transmitting. Keep the output active and refresh your view of the available source choices by reopening or checking the source properties. Then review the private network profile and firewall permissions. Allow both the sending application and Streamlabs Desktop through the firewall, following the normal prompts or controls for your operating system.
If the stream is listed but the preview is blank, the receiver has discovered a named feed, so test the sender’s output content next. Check that the correct scene, screen region or camera is being transmitted and that it is not paused or obscured on the sender. If the picture works but sound does not, isolate the audio path; the OBS Browser-source limitation noted above is one example where a specific output does not carry its source audio.
Change one thing at a time and retest. For example, first verify active output, then check the network profile, then firewall permission. Avoid inventing port rules or changing router settings based on generic advice: Streamlabs’ reviewed receiver instructions do not give port numbers or prescribe particular router changes. If a managed network blocks local device discovery, its administrator may need to review the policy, but start with the documented checks.
When you are documenting a setup for someone else, note the Streamlabs version, SDK version, sender application and whether the sender reports an active output. Those details make a useful fault report without implying that a setup is guaranteed to work on every network. If NDI is one part of a larger YouTube workflow, keep the transmission method separate from channel planning and content rights; the guide to copyright considerations for repeated YouTube live music addresses a different but important operational question.
Choose a sender that matches the material
The receiver procedure stays much the same, but the sending route changes what you can share and what you must configure. Use the comparison below as a selection aid, not as a ranking: choose the method that produces the specific picture you need and has a workable audio path.
| Sender route | Useful when you need | What to check before receiving |
|---|---|---|
| OBS Studio with DistroAV | An OBS output such as a programme view | OBS and the plugin are configured to send NDI; the documented example uses OBS Studio 31+ and NDI Runtime 6 |
| Scan Converter 2 | A full display or selected screen region | The correct screen or region is being captured and transmitted |
| Mobile device | A mobile-originated video feed | The device sender is active on the same local network and its audio behaviour suits the use |
Streamlabs’ companion material is the source for these examples, rather than a claim that every route has identical setup steps. Follow the relevant sender’s own documentation for its controls and prerequisites. In particular, do not treat the NDI Runtime named in an OBS sender guide as a reason to ignore the receiver guide’s SDK 6-or-higher requirement for Streamlabs Desktop 1.20.6 and later.
A practical choice is the least complicated sender that can deliver the picture and sound you actually need. If a devotional channel only needs to bring an OBS composition into Streamlabs, an OBS output may avoid an unnecessary screen capture. If you need to send a specific software window or an area of the desktop, a screen-capture utility may be more direct. If the content originates on a mobile device, a mobile sender avoids first routing it through a desktop capture scene.
For a workflow that will run for long periods, include the sender computer and application in your operating plan. NDI reception depends on an active local sender; shutting down or suspending that sender removes the feed even if Streamlabs remains open. If your concern is recovering the YouTube broadcast after a disconnection rather than transferring a local feed, the automatic restart guide covers that separate failure mode.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does Streamlabs Desktop send an NDI feed by itself?
No. In this workflow, Streamlabs Desktop receives an NDI stream as a source. A separate sender application must capture and transmit the feed over the local network before it can be selected.
Which NDI SDK version do I need?
Streamlabs’ receiver guidance says Streamlabs Desktop version 1.20.6 and later calls for NDI SDK 6 or higher. Install the NDI SDK redist on both the receiving computer and the computer running the sender, then reboot.
Why is NDI Source missing from the source list?
Check that the NDI SDK redist was installed correctly and that you rebooted after installation. If the source is available but no stream appears in its properties, confirm the sender is actively transmitting, both computers use the private network profile, and the firewall permits the sender application and Streamlabs Desktop.
Can I use an OBS Studio sender?
Yes, Streamlabs documents an OBS Studio 31-or-later route using the DistroAV plugin and NDI Runtime 6. That is a sender-side example; it does not remove the separate receiver prerequisite or make Streamlabs Desktop the sender.