NDI lets XSplit Broadcaster receive video sources over a local network, including feeds from another Broadcaster instance or an NDI-enabled application. To add one, open Add Source > Video/Network Stream and select the NDI stream that appears in the list.
The source still depends on the sending device or application and Broadcaster being discoverable in the local-network workflow. After adding it, choose the audio routing option that suits your production; if the picture stutters or falls out of sync, try XSplit’s Standard quality setting and check the network path before changing other parts of the scene.
What NDI does in XSplit
NDI is a way to send video sources over IP on a local network. In XSplit Broadcaster, that can mean receiving a feed from another Broadcaster instance or from an application that provides an NDI output. It is different from capturing a window on the same computer: the source is being made available across the network and then selected inside Broadcaster.
Think of the sending application as the source and Broadcaster as the receiver. The sender has to make an NDI feed available, and the receiving computer has to be able to discover it in the expected local-network workflow. XSplit’s NDI overview describes both sending and receiving over a local network. It does not make every device, application or remote connection an NDI source automatically.
There are two distinct directions you may encounter. To bring a camera, application or second computer into a scene, add an NDI stream as a source. To pass your completed Broadcaster production to another compatible device or application on the network, use Broadcaster’s NDI output capability. The first receives a source; the second sends the finished production. They are related, but they are not the same setup step.
If your aim is to build a long-running YouTube channel, it helps to keep the production signal path understandable: identify where each picture and sound comes from, then test the scene before relying on it. For example, a devotional channel might use a second computer to provide a title or visual feed while Broadcaster combines it with the rest of the scene. A YouTube live bitrate guide for sports replay loops concerns the outgoing stream to YouTube, not the bandwidth needed by an NDI source inside your local production. Treat those as separate parts of the chain.
Check the local network and NDI source
Before opening Broadcaster, confirm that the sending side is actually offering an NDI feed. This could be another Broadcaster instance or an NDI-enabled application. A camera or computer does not become an NDI source merely because it is on the same Wi-Fi network; it needs a compatible source workflow that exposes a feed.
Then check that the sending device and the computer running Broadcaster are operating in the intended local-network context. NDI carries the source over IP on that network, so a source that is not listed may point to discovery or network conditions rather than to a scene-layout problem. If you are using separate network names, guest Wi-Fi, a VPN or managed office network, check whether those conditions affect local device discovery. These are sensible things to investigate, not documented XSplit requirements or a promise that changing one will solve the issue.
XSplit’s documentation does not specify a universal port list, firewall recipe or compatibility matrix for every sender and receiver combination. Avoid copying port values from an unrelated setup or assuming a firewall change is necessary. If you need to make network changes, use the documentation for your actual source and network equipment, and involve whoever manages the network where appropriate.
Wired Ethernet can be a useful option when you are diagnosing a busy or inconsistent wireless connection, but XSplit’s receiving instructions do not require a particular cable or say that wired networking guarantees a stable feed. Compare like with like: test the same source and scene, then note whether discovery or playback behaviour changes. For a small studio, the useful question is not whether a cable sounds more professional; it is whether the network path you have is behaving consistently under the load of your actual production.
If the NDI stream appears in Broadcaster’s list, discovery is at least working at that moment. If it does not, first verify the sender is active and intended to publish a feed, then check the local-network conditions and source documentation. Do not troubleshoot scene scaling or audio routing before the feed is visible; those steps cannot make a missing source appear.
Add an NDI source to a scene
In XSplit Broadcaster, open Add Source > Video/Network Stream. Select the desired NDI stream from the list. This is XSplit’s documented path for adding an NDI source, as described in its Video/Network Stream instructions.
Once selected, check that the source appears in the scene. If it is not positioned or sized as intended, adjust it using the ordinary scene controls available in your Broadcaster version. The important distinction is that selecting the feed adds it to the production; arranging it determines how it appears in the composition. Keep a note of which source name corresponds to which sending computer or application if the list contains several similar entries.
Test the scene with the source visible before starting a public broadcast. Look for a current image rather than a frozen frame, and check whether other scene elements still layer as expected. If this is a recurring channel, review your scene collection and video loop workflow as a separate example of why rehearsing scene changes matters; the mechanics differ, but the principle of confirming the active composition before a long session applies.
If the intended use is to send the whole Broadcaster production outward, do not look for the receiving source path as though it were the output control. XSplit also documents outputting a production as an NDI stream for compatible network devices and software. Check the current Broadcaster documentation for that send-side procedure, since the receive steps above only add an incoming source.
Choose the feed
The list of available NDI streams is where you choose which sender to use. If there are multiple entries, identify the right one from the source name and, where possible, verify the sender before selecting. A camera feed and a desktop feed may both be valid NDI sources, but selecting the wrong one can look like a composition mistake when the actual issue is simply that the wrong source was added.
A source list that is empty is different from a source that appears but shows the wrong content. An empty list calls for checking whether the sender is publishing and whether it is discoverable in the local network. A visible but unexpected picture calls for checking the selected source and the sending application. Keep these cases separate so you do not make unrelated network or scene changes.
For a production that includes a remote guest, do not assume local NDI discovery is equivalent to a remote contribution service. XSplit’s NDI Remote support article says that feature is offline and under review, and points readers seeking remote guests towards VDO.Ninja. Its status may change, so check the current XSplit NDI Remote guidance rather than planning a production around an old description. This is a different use case from receiving an NDI source available on your local network.
Route NDI audio
An NDI source can carry audio as well as video, and XSplit documents audio routing choices for the source: System Sound, the documented default, or Stream Only. Which one suits you depends on how the rest of the production handles sound. XSplit’s source menu introduction provides its source-level guidance; check the controls in your installed version if the interface differs.
System Sound may suit a setup where you want the source audio to be heard through the system’s sound output. Stream Only is the alternative when you want the source audio routed to the stream rather than treated as system sound. Do not assume one is universally correct: the right choice depends on whether you monitor sound locally, whether the source should be heard by viewers, and how other audio sources are configured.
Make a brief test recording or private rehearsal and listen for both the NDI source and any other intended audio. Watch for an echo if the same sound is arriving through more than one path, such as an NDI feed plus a separate desktop capture. Also check whether the source is silent because the sending application is not providing audio, rather than assuming the Broadcaster route is at fault. If you change routing, test the complete path again instead of judging by a setting label alone.
For a music, study or news channel, document the route alongside the source name: what sends the sound, which option you selected, and where you listened for the result. This small note makes it easier to recover after a restart or scene edit. It is also useful to keep NDI audio distinct from the YouTube stream’s other sound sources; a guide to streaming a radio station to YouTube Live can help frame the separate question of what audio belongs in a channel’s programme, though it does not describe XSplit’s NDI controls.
Troubleshoot a stuttering feed
When the picture stutters or audio and video become desynchronised, first test XSplit’s documented quality option for the NDI source. XSplit says to switch the source quality to Standard in these cases; Standard receives audio and video at lower bandwidth. This is a vendor recommendation, not a guarantee that every stutter will stop or a measured performance claim.
| What you observe | First check | What it tells you |
|---|---|---|
| The source is not listed | Confirm the sender is publishing an NDI feed and review local-network discovery conditions | The problem is before scene playback |
| The source is listed but the picture stutters or falls out of sync | Try the Standard quality setting for that source | XSplit says this uses lower bandwidth for receiving audio and video |
| The image is smooth but sound is missing or doubled | Review the source’s System Sound or Stream Only routing and the sender’s audio | The issue may be in the audio path rather than video delivery |
| The feed works in one scene but not as expected in another | Confirm the selected source and scene composition | The feed can be present while the wrong source or layout is active |
If Standard does not resolve the problem, avoid changing several things at once. Check whether other network-heavy tasks are running, whether the sender is itself struggling, and whether the receiver’s computer is handling the rest of the production. Those checks can help distinguish a network condition from a source-side or production workload issue, but they are diagnostic possibilities rather than XSplit-specific guarantees.
Repeat the test with the same source and a simple scene if you can. If a simple scene is stable but a more complex production is not, compare the additional sources and tasks before concluding that NDI alone is responsible. If the source remains inconsistent, note when it happens and what was active; that gives you concrete information to take to the relevant source or network documentation.
For a 24/7 channel, a stuttering input deserves attention before you build the rest of the broadcast around it. A looped video that does not depend on a live NDI source has a different failure profile; see the OBS loop guide for that alternative workflow. It is not a replacement for NDI when you need a live camera or application feed, but it can help you decide whether the source needs to be live at all.
A long-running broadcast also needs a plan for what viewers see if a source is unavailable. Keep a fallback scene or a clearly tested static element ready if your format permits it, and check it before going live. That does not repair the NDI feed; it makes the production less dependent on an untested assumption about one input.
Make the workflow fit a long-running channel
NDI is most useful when the source you need is already available on the local network and you want to bring it into Broadcaster without treating it as a remote guest connection. For a local news loop, that might be an application feed supplying a graphic; for a study channel, it might be a second computer’s visual contribution. Write down the sender, the selected feed, the audio route and the quality setting you tested. This gives you a short recovery checklist rather than a vague memory of what worked.
If you are producing a fixed video loop rather than combining live local sources, a different workflow may be simpler. If the source can be prepared as a file and does not need to change during the broadcast, compare that with a scene that depends on a sending computer staying available. StreamNeo can remove the need to keep your own computer switched on when your channel is simply broadcasting an uploaded video file continuously; that is a different job from receiving an NDI camera or application feed into XSplit.
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
Can XSplit Broadcaster receive NDI from another computer?
Yes, XSplit documents receiving NDI streams from other Broadcaster instances and NDI-enabled applications through the Video/Network Stream source path. The sender and receiver need to be discoverable in the local-network workflow; this is not a promise that any computer on any network will appear automatically.
Where do I add an NDI feed in XSplit?
Use Add Source > Video/Network Stream, then select the desired NDI stream from the list. If the stream is absent, check the sender and local-network discovery before troubleshooting scene layout.
Which NDI audio option should I use?
XSplit documents System Sound as the default and also offers Stream Only. Choose based on how you want to monitor and send the source audio, then test for silence or duplicate sound in the complete production.
What should I try first if an NDI feed stutters?
XSplit’s guidance is to switch the source quality to Standard, which receives audio and video at lower bandwidth. If the issue continues, check the sending application and local-network conditions without assuming that one setting guarantees a fix.