NDI over Internet: A Complete Engineering Guide

The short answer

You can move NDI over the internet. You should not treat it like a LAN signal.

NDI works best on managed local networks with predictable bandwidth, low jitter, and clean discovery. The public internet gives you the opposite: NAT, packet loss, upload limits, hotel Wi-Fi, cellular swings, and firewalls that change the game mid-show.

That does not kill NDI for remote production. It just changes the architecture.

Most teams need one of three patterns:

• NDI Bridge between two controlled sites
• NDI inside the local site, then SRT between sites
• NDI inside the local site, then WebRTC for browser preview or return video

Pick the pattern before you pick the tool.

Why NDI over internet gets messy

NDI solves a local production problem. It lets cameras, graphics systems, switchers, replay machines, and software tools find each other on an IP network and pass video with low latency.

A studio LAN usually gives NDI what it wants:

• High bandwidth
• Short round-trip time
• Minimal packet loss
• Simple device discovery
• Private IP addresses under one admin team

The internet breaks that neat setup.

Discovery fails first. NDI devices often rely on local network discovery, and that discovery does not cross most routers by default. Then bandwidth bites. A high-quality NDI feed can demand far more upstream capacity than a field site can provide. Jitter adds the next hit. A stream that looks fine for 20 minutes can fall apart when someone at the venue starts a cloud backup.

Do not debug this during rehearsal. Design around it.

Start with the signal type

Before you move any NDI feed across a WAN, split your sources into three groups.

Production-critical feeds need the best path. Think program return, iso cameras, clean feed, graphics key/fill, or a source that the director may take live.

Operational feeds need low latency, but they can take lower quality. Think multiviewer, confidence monitor, producer preview, or talent return.

Convenience feeds help the team, but they should never threaten the show. Think lobby cam, backstage cam, remote logging, or a low-priority screen share.

Each group deserves a different transport decision. If you push every NDI source through the same path, the least important feed can hurt the most important one.

Pattern 1: NDI Bridge between controlled sites

NDI Bridge makes sense when you control both sides of the link and you want to preserve the NDI workflow across locations.

Use it for:

• Studio-to-studio contribution
• A remote control room that pulls feeds from a known venue
• A production company with repeat venues
• A private VPN or static internet setup

Plan the connection like a production circuit. Measure real upload speed at the venue. Do it at show time, not at 10 a.m. on an empty network. Check packet loss. Check jitter. Check firewall rules. Confirm who owns the router.

NDI Bridge can use compressed video modes, including NDI HX workflows, which helps on bandwidth-limited links. Still, treat bandwidth as a budget. A link that can handle one feed may choke on four.

The common mistake: teams test one camera, see a clean picture, then add graphics, return, replay, and preview. The total load changes the result.

Pattern 2: NDI locally, SRT between sites

This pattern fits broadcast contribution better than many pure NDI-over-WAN setups.

Keep NDI inside the venue. Convert the selected feed to SRT at the edge. Send SRT over the public internet. Convert back to SDI, NDI, or another format in the control room.

Use it for:

• Remote sports production
• Field contribution over fiber, 5G, or satellite
• Guest studios
• Venues with unstable uplink
• Cloud ingest

SRT gives you a latency buffer and packet recovery. That matters. A 200 ms or 500 ms buffer can recover lost packets before viewers see artifacts. You trade a small amount of delay for a much cleaner feed.

This pattern also makes security simpler. SRT supports encryption and caller/listener modes. You still need firewall planning, but you avoid pretending that a wide-area network behaves like a switch.

Pattern 3: NDI locally, WebRTC for preview and return

WebRTC shines when a person needs to watch or interact in near real time from a browser.

Use it for:

• Producer preview
• Talent return
• Director monitoring
• Remote guest confidence video
• Talkback-adjacent workflows

Do not use WebRTC as a magic replacement for every contribution link. WebRTC protects timing first. When the network gets ugly, it drops quality to keep latency low. That works for a producer preview. It may not work for a feed you plan to cut live.

Use WebRTC where stale video hurts more than lower quality.

Bandwidth planning that actually helps

Start with upload. Field sites usually fail there.

Build a table like this before the show:

Then add headroom. A 20 Mbps uplink should not carry 20 Mbps of video. Keep at least 30 percent free for bursts, overhead, control traffic, and ugly network moments.

If the venue offers 100 Mbps down and 10 Mbps up, you have a 10 Mbps venue. Plan from the smaller number.

NAT and firewall checks

Every remote production plan needs a network owner. Not a camera operator with a password. A real owner.

Ask these questions early:

• Can we open inbound UDP if the workflow needs it?
• Do we need caller mode so the venue initiates the connection?
• Does the network block nonstandard UDP?
• Can we use a VPN without adding too much latency?
• Who can change firewall rules during rehearsal?
• Does the venue run traffic shaping?

If nobody can answer, assume trouble. Use a workflow that calls out from the venue to your receiver or cloud service.

Monitoring beats guessing

Do not rely on "looks good here."

Track:

• Packet loss
• Round-trip time
• Jitter
• Encoder bitrate
• Decoder buffer
• Dropped frames
• Audio/video sync
• CPU and GPU load

Put those numbers on one screen. When the feed breaks, you need to know whether the encoder, network, decoder, or software path caused the failure.

Where Medialooks fits

Medialooks Video Transport fits teams that need to move SDI or NDI sources between locations with low latency and less network setup. It builds on SRT, adds ICE-based NAT traversal, and gives production teams a practical way to connect remote sources over the public internet.

Medialooks Video SDK fits teams that build their own production software. It lets developers ingest NDI, SDI, SRT, WebRTC, RTMP, and file sources inside one application instead of stitching together separate media stacks for every protocol.

The practical rule

Use NDI where it feels at home: inside the production site. For the internet leg, choose the transport based on the job:

• Use SRT for high-quality contribution over rough networks.
• Use WebRTC for browser preview and return video.
• Use NDI Bridge when you control both endpoints and want an NDI-native workflow.

That architecture saves time. It also saves the show.