NDI Bridge is the documented NDI tool to investigate when you need to make production sources available across sites over the internet. Its Host and Join modes connect NDI networks across a WAN; Local mode is for local proxying or transcoding, not a substitute for a reachable WAN endpoint.
Bridge helps connect NDI infrastructures, but it does not make internet conditions predictable or configure every part of your network for you. You still need to choose the roles, arrange reachability, decide how much compression and delay your production can tolerate, and test the actual path.
When an NDI production needs to cross locations
NDI is often simplest when cameras, computers and receivers share one local production network. Crossing locations changes the problem: you must make selected sources available to another network while accounting for the upload and download capacity, latency and configuration at both ends. A studio sending a camera feed to an editor in another city, for example, is not just extending a cable; it is establishing a path between two independently managed networks.
Start by writing down the production requirement. Which sources must the remote site see? Does video travel in one direction, or must each site contribute sources for the other? How many receivers will use each source, and what delay can the production accept? A single camera feed for a programme with conversational timing has different constraints from a set of feeds used for editing or monitoring.
Keep this separate from your YouTube broadcast workflow. NDI moves production sources between compatible NDI tools; it does not itself send a stream to YouTube. If the aim is to keep finished video playing continuously on YouTube, this guide on running a recorded gameplay rerun channel addresses a different stage of the workflow. Decide where NDI fits before choosing equipment or changing your router.
What NDI Bridge does
NDI Bridge connects NDI infrastructures across a WAN. Think of it as a way to make selected sources from one production network available to another through configured Bridge endpoints. NDI describes the product as connecting remotely over a WAN; that describes its role, not a promise about the quality or consistency of an internet path.
Bridge offers Host and Join modes for connecting separate networks, as well as Local mode for proxying or transcoding sources within a local network. The distinction matters: using Bridge locally to prepare or adapt sources does not by itself create a connection to a remote site. For remote operation, both ends must use compatible settings and the Host must be reachable as configured.
The official NDI Bridge documentation explains the modes and encoding controls. NDI’s Bridge product page gives current product information, including encryption and system requirements. Software availability, requirements and interface details can change, so check those pages when you install rather than relying on an old screenshot or a copied configuration.
A useful way to frame Bridge is as a connection tool, not as an internet service that removes network decisions. You still need permission to configure the network, a reachable endpoint, enough capacity for the chosen media, compatible codecs and a way to diagnose problems. If those conditions are outside your control, involve the person who administers the network before planning a live production around it.
Host and Join roles across a WAN
In a typical arrangement, one Bridge endpoint acts as Host and a remote endpoint joins it. The Host is the point the Join side must reach. Decide which site will host by considering where you can configure the router and where a suitable public address is available, rather than assuming the main studio must always be Host.
Before configuring either side, agree on the direction and scope of the connection. Decide which sources should cross the link and which should remain local. Then assign the Host and Join roles according to the documented workflow and configure both ends consistently. If the production is bidirectional, check that the intended sources can be made available in both directions; do not assume that selecting roles automatically gives every device on both networks unrestricted visibility.
Bridge uses an encryption key, and NDI states that endpoints must use the same key. Treat it as a credential: share it only with the intended participants, use a secure method to send it, and avoid leaving it in a public message or a document accessible to the whole team. A connection that fails because the two endpoints have different keys is a configuration issue, not evidence that the internet path is necessarily broken.
If you are accustomed to entering a link in a browser and inviting a guest, that is a different model. NDI Remote is discontinued and offline according to NDI’s documentation; do not build a current workflow around the assumption that it remains available. Bridge is for connecting NDI infrastructures, so it requires planning at the network and endpoint level.
Use Local mode for proxying or transcoding
Local mode is useful when you need Bridge to proxy sources or apply a supported transcode on the local network. Proxying can help present selected sources to local receivers without treating Local mode as a WAN tunnel. Transcoding can adapt media for a connection or decoder, but it changes the media workflow and may require compatible support at both ends.
Bridge encoding choices depend on the incoming source type. NDI documentation describes H.264 or HEVC transcoding for NDI HX. For High Bandwidth NDI, configuration can use SpeedHQ, pass the signal through, or use no transcoding. These are not interchangeable quality switches: compare the source format, the desired output, decoder support and the capacity available between sites. Confirm the current controls and supported combinations in the Bridge documentation before settling on a preset.
Compression can reduce the amount of data that needs to travel, which can be useful when WAN capacity is limited. In return, encoding and decoding require compatible support and may alter image characteristics or add processing delay. If you choose HEVC, check the receiving system’s decoder support; NDI notes that Windows 10 and later may require a separate Microsoft Store licence for an HEVC decoder. Verify the current vendor guidance and licensing before a production depends on that format.
Local proxying or transcoding is not a cure for a weak internet connection. It can change what is sent and how much data it uses, but the WAN still has to carry the resulting stream. If the source is a high-bandwidth feed and you cannot sustain its transport needs, lowering the load or changing the production plan is more useful than expecting a mode selection to overcome the path.
Check reachability and the network port
The Host must be reachable from the Join side. NDI says Bridge can discover the public IP address, but it cannot configure the router’s port-forwarding rule for you. At least one location needs a public IP address, and a network port must be translated or forwarded to the local IP address of the Bridge Host. This is often the point at which you need help from the site’s network administrator or internet provider.
NDI documents port 5990 as the default, while allowing a different port to be selected. Treat that as a documented default, not an instruction to open it blindly. Check the current NDI port-forwarding guide, choose the port according to your configuration, and forward it to the correct Host machine. Confirm that firewall rules permit the intended traffic and that the machine keeps the local address used by the forwarding rule.
A common source of confusion is that a public IP address alone does not prove the Bridge computer is reachable. The router still needs the appropriate forwarding configuration, and upstream network arrangements may affect whether inbound connections can reach it. If you cannot configure the router, or do not know whether the address is public and reachable, ask the responsible administrator to verify those points rather than repeatedly changing Bridge settings.
Keep security in the same conversation as reachability. Limit access to the intended endpoint and protect the shared encryption key as you would other credentials. NDI says Bridge uses 256-bit encryption, but that does not remove the need to choose who receives the key, keep endpoint settings consistent and follow your organisation’s security practices. Do not publish connection details in a public channel for convenience.
Connect sources and verify both sites
Once Host reachability, Join settings and the key are in place, connect the endpoints and test with the actual sources and receiving software. Begin with one source and one receiver, then add the remaining sources and destinations in stages. This makes it easier to tell whether a problem follows one format, one endpoint or the network path as a whole.
Check that the intended source appears at the remote site and that its picture and audio are usable for the job. Confirm which side is sending and receiving, and check that the selected source is the one you expect. If the workflow is meant to be bidirectional, test a source in each direction. A source visible in a local list does not by itself prove that the other site can receive it reliably.
Use Bridge diagnostics to inspect send and receive rates, round-trip time, packet loss and buffer behaviour. NDI’s Bridge logging documentation describes the available diagnostic information. Record what you observe at both endpoints, along with the source format and encoding choice, so you have a baseline to compare after a network or configuration change. A brief successful connection is a useful check, but it is not evidence that the path will behave the same way during a longer programme.
If a source fails, check in a consistent order: confirm that both endpoints are running the expected software and matching key; verify the Host address, port and forwarding target; confirm that the source is available locally; then inspect diagnostics and codec compatibility. Avoid changing several settings at once, since that makes it harder to identify what resolved the issue. If the aim is ultimately to deliver a continuous prerecorded YouTube channel, keep the delivery workflow distinct from the NDI contribution link; this guide to keeping a YouTube playlist going when one video fails covers continuity at that later stage.
Plan for variable capacity and delay
A wired gigabit local network and an internet WAN are different planning problems. NDI says gigabit networking is essential to production workflows. Its bandwidth guidance says a typical 1080p60 NDI stream can reach up to 150 Mbps per stream, but that is local/workflow guidance, not a promised internet bitrate or a universal upload-speed requirement. The actual demand depends on the media and configuration, and NDI advises planning around average utilisation because bandwidth is not deterministic.
At each site, consider sustained upload and download capacity, other traffic competing for it, the number of simultaneous sources and receivers, and the quality level the production needs. A network that carries one feed may not comfortably carry several at once. A gigabit Ethernet switch and cabling may suit a wired local production network, but they do not raise your internet service rate or ensure WAN stability. Select local networking equipment for the devices and ports you actually need, not as a supposed fix for a remote path.
Bridge’s configurable buffer stores video data and can help continuity when latency or available bandwidth varies, at the cost of added delay. That trade-off should be tested against the programme: extra delay may be acceptable for a remote source used in a recorded segment, but disruptive for a live conversation that depends on quick replies. Increase or adjust buffering only after observing the actual path, and verify that the resulting delay remains workable.
| Planning factor | What to check | Practical consequence |
|---|---|---|
| Source format and quality | HX or High Bandwidth source; required image detail | Determines which Bridge encoding choices may be relevant |
| Capacity at both sites | Sustained upload and download while normal traffic is present | Constrains how many feeds can be carried together |
| Delay tolerance | Whether contributors need conversational timing | More buffering can smooth variation but adds delay |
| Receiver count | How many destinations need each source | Changes the overall production load and distribution plan |
| Codec support | Encoder and decoder availability at both endpoints | A format choice is only useful if both systems can handle it |
| Network access | Ability to configure router forwarding and protect credentials | Determines whether a reachable Host can be established and maintained |
Test at the times and under the conditions when the production will actually run. If the connection degrades when other household or office use increases, schedule a test during that activity rather than relying on a quiet-hour result. Keep an alternative plan for a missing source: a local recording, a different shot or a clearly defined decision to continue without the remote feed. For a YouTube output, the final encoder settings are a separate concern; see the FFmpeg CBR bitrate checklist for that distinct delivery step.
No Bridge mode can make the WAN deterministic. If you cannot obtain a reachable Host, cannot sustain the media load or cannot accept the likely delay, simplify the source plan, reduce the transport load where the workflow permits, or choose a different contribution method. Be explicit with presenters and operators about what happens when the remote source freezes or disappears, instead of assuming the link will recover unnoticed.
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 NDI Bridge stream directly to YouTube?
No. Bridge connects NDI production networks across a WAN; it is not a YouTube output workflow. You still need a separate production or encoding step to send the programme to YouTube Live.
Does Bridge configure my router for me?
No. NDI says Bridge can find the public IP, but it cannot create the router’s port-forwarding rule. The Host must be reachable through a configured port, so involve the network administrator if you do not control the router.
Should I use Host, Join or Local mode?
Use Host and Join for the WAN connection between sites, assigning the reachable endpoint as Host and configuring the other side to join it. Local mode is for local proxying or transcoding use cases; it does not, on its own, connect a remote network.
Will buffering make a variable internet path reliable?
Buffering can help smooth variation by storing video data, but it adds delay and cannot guarantee a stable path. Test the buffer behaviour with your real sources and timing needs, then decide whether the trade-off is acceptable.
StreamNeo is useful when the production problem is keeping a finished video running on YouTube after your own computer is switched off; it does not replace NDI Bridge for connecting live production networks across sites.