# OBS Teleport moves OBS scenes across a LAN without NDI, with filters still half built

> OBS Teleport is a Go based OBS Studio plugin that transmits scenes between machines on a local network using multicast discovery, in place of an NDI style workflow. It works, but the filter side only supports audio and video sources for now, and the whole design assumes a gigabit LAN with permissive firewalls.

**fzwoch/obs-teleport** — An OBS Studio plugin for an open DistroAV/NDI-like replacement. Pretty simple, straight forward. No NDI compatibility in any form.

- Repository: https://github.com/fzwoch/obs-teleport
- Stars: 647 · Forks: 32
- Language: Go
- License: GPL-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/fzwoch-obs-teleport

## A LAN scene transport that deliberately refuses NDI

OBS Teleport is an OBS Studio plugin for an open DistroAV style replacement, and it states its position on NDI plainly: no NDI compatibility in any form. That is not a limitation smuggled in a footnote, it is the design premise. The project is described as pretty simple and straight forward, and it exists so that a multi machine stream setup can transmit some OBS Studio scenes to the main streaming machine over the LAN without adopting a proprietary video transport.

The audience is specific. If you run OBS on several machines in the same building and need one of them to feed a scene into the machine that actually streams, the plugin gives you a path that stays inside your own network and inside open tooling. It is not aimed at remote production over the internet, and nothing in the project describes a relay, a server component, or an authentication scheme.

The primary language is Go, and the repository layout shows a clean separation of concerns at the top level: announcer.go, discoverer.go, packet.go, sender.go, source.go, output.go, filter.go, frontend.go, pool.go, types.go, plus main.go and a utils.c file. Discoverer, announcer, sender, and source are the pieces you would expect from a plugin that has to find peers, announce itself, push frames, and receive them.

## Peer discovery over multicast is what makes the LAN assumption visible

Sending video to another machine requires answering two questions first: who is out there, and which port are they listening on. The source files suggest the split. discoverer.go handles finding peers, announcer.go handles announcing the local sender, and the dependency list confirms the approach rather than the other way around.

The go.mod file is short and shows only one direct dependency:

```go
module obs-teleport

go 1.26.0

require github.com/schollz/peerdiscovery v1.7.6
```

A peer discovery library is what implements the multicast probing. The project's notes make the network requirement explicit: a connection must be made between sender and receiver, so they must be on the same network and allow multicast for peer discovery. If discovery is not working, or no video and audio is being transmitted, the documented fix is to disable network firewalls. Alternatively you can force the sender to listen on a specific port and set the firewall to allow that port to accept connections.

That last point matters more than it first appears. Multicast discovery is convenient when it works and fragile when a managed network blocks it. The explicit port option is the escape hatch, but it pushes the problem onto whoever administers the firewall, since the receiver still has to find the sender somehow. There is no manual address entry described in the notes, so on a network where multicast is filtered you are dependent on the discovery step working.

## One gigabit of stable bandwidth is the real spec sheet

The project states that having at least 1 Gbps of a stable network connection is kind of required, and highly recommended. That sentence is the honest version of the project's capacity. A teleported OBS scene is a live video stream with audio, and a single uncompressed or lightly compressed video path will consume bandwidth quickly when the resolution and frame rate of a production scene are involved.

The project also says you can try to make a lower quality stream work with less bandwidth, but that this is then up to you to experiment with. In other words, the quality knobs are exposed and the tuning is left to the operator. That is a reasonable division of labour, but it means the answer to a question about capacity is not a number in the documentation. It is a measurement on your own network with your own scene settings, and the plugin will not tell you which setting to lower first.

The stable part of the wording matters as much as the fast part. A link that dips for a second will show up as artefacts in the receiving scene, which is a far more disruptive failure for a live production than a slightly lower resolution would be. Wired gigabit on a dedicated switch is the sane deployment, and the project does not describe any adaptive bitrate behaviour or buffering policy that would smooth out a congested link.

## Filters only work on async sources, so effect filters fall back to output mode

The plugin offers two ways to use it, and they are not equally finished.

In output mode, the sender is enabled globally. The setup steps are short. In OBS, open Tools and choose Teleport, then check Teleport Enabled. That covers the sender side for the whole instance.

In filter mode, the sender is attached to a single source. The steps given are: click the source, right click and choose Filters, then click the plus sign and pick Teleport. A filter attached to a source means the sender pushes only that source's frames, which is what you want when one camera or one scene feeds the remote machine.

The limitation is stated plainly. Only the Audio/Video filter mechanic is implemented on the filter feature, which the project calls Async sources. Adding it as an effect filter for Sync sources is not supported, and the instruction in that case is to revert to the output mode. That is a real constraint with a real cost. If your pipeline depends on placing the plugin at the end of a chain of effects, such as a filter applied after a colour correction or a compositing step, the filter path cannot express that and you must send the pre-effect output instead. Anyone planning a multi stage scene graph needs to know this before designing around the filter.

## Receiving is a source you add to a scene, and pick a stream from a dropdown

On the receiving side the plugin presents itself as a normal OBS source. In a scene you use Sources, then Add, then Teleport. Once the source exists, you select a detected stream from the Teleport drop down.

Two things follow from that design. First, the receiving machine treats a remote machine as a scene element, which is the right mental model for the workflow the plugin targets: a remote camera becomes a layer you can place in a scene, position, and composite like any other source. It also means the plugin participates in the normal OBS scene system, so the usual OBS mechanisms for arranging and switching sources apply to it.

Second, the drop down lists detected streams, so the receiver picks among peers found by discovery rather than typing an address. This is convenient and it is the same reliance on multicast noted earlier. There is no described fallback for entering a host and port by hand for the receiver, and if multicast discovery fails, the list has nothing in it. The sender side offers a fixed port for firewall purposes, but that only helps when the receiver can still see the announcement.

The plugin does not describe how many concurrent remote streams a receiver can hold, nor how the plugin behaves when a sender disappears mid stream. Those are exactly the questions a producer asks when planning a multi machine setup, and the README does not answer them.

## Installation is delegated to the OBS plugin guide and the releases page

There is no install command to copy. The project points you at the OBS Studio documentation, the plugins guide, for how and where to install plugins, and gives the reason plainly: there are too many platforms and installation options available as the scope of this project could explain and maintain. That is an honest boundary rather than an omission, since OBS plugins are distributed per platform and per packaging format.

Binaries can be grabbed from the Releases section of the repository. Most platforms do have an installer that may help with installation, and Flatpak OBS versions can install it via Add-ons from Flathub. Those two sentences cover the practical paths for most users.

Because the project builds on the OBS plugin model, the Go toolchain requirement in go.mod only matters if you intend to build from source. The module declares Go 1.26.0 and pulls in github.com/schollz/peerdiscovery v1.7.6, with golang.org/x/net and golang.org/x/sys as indirect requirements. For most users the released binaries remove that entirely, which is the main argument for taking them over building the plugin yourself.

## Release cadence, licence, and what the project does not promise

The project is active. The last push to the repository was on 2026-10-15, and the tagged releases show a steady run of patch versions through 2026: 0.8.0 on 2026-09-21, 0.7.7 on 2026-05-08, and 0.7.6 on 2026-02-23. The version numbers sit below 1.0, which is normal for an OBS plugin and signals that the interface may still move.

The licence is GPL-2.0, which is worth noting for anyone planning to ship the plugin inside a larger commercial product. The project carries a LICENSE file at the top level, so the terms are available to read directly. As with any GPL component, the practical question is whether your distribution model satisfies the copyleft terms, and that is a legal question rather than a technical one.

What the project does not promise is as informative as what it does. There is no claim of NDI protocol compatibility, no latency figure, no resolution ceiling, and no list of supported OBS versions beyond what the plugin guide implies. The README is deliberately short, and it points at the OBS documentation rather than restating it. For a team deciding whether this replaces an NDI workflow, the deciding evidence is not in the project pages. It is a trial run on your own network with your own scene resolution, checking first that multicast discovery works between the two machines.

## Conclusion

OBS Teleport suits studios that run multiple OBS machines on one wired network and want scene transfer without an NDI licence or SDK. It does not suit anyone relying on effect filters, on discovery across switched networks that block multicast, or on links slower than a gigabit. Before installing, check the go.mod requirement of Go 1.26.0 and the single peerdiscovery dependency, and confirm your firewall allows multicast on the subnet, because that is the first thing that breaks and the README says to disable firewalls as a diagnostic step.

## FAQ

### Is OBS Teleport compatible with NDI?

No. The project states there is no NDI compatibility in any form, and it is built as an open alternative in the DistroAV style for sending OBS Studio scenes over a LAN.

### How do I install the OBS Teleport plugin?

The project refers you to the OBS Studio plugins guide for where to install plugins, and binaries are available from the Releases section of the repository. Flatpak OBS versions can install it via Add-ons from Flathub.

### Why does OBS Teleport not discover the sender on my network?

The sender and receiver must be on the same network and allow multicast for peer discovery. The documented diagnostic is to disable network firewalls, and you can alternatively force the sender to listen on a specific port and allow that port in the firewall.

### Can I add OBS Teleport as an effect filter on a sync source?

Not at the moment. Only the Audio/Video filter mechanic is implemented for async sources, and adding it as an effect filter for sync sources is not supported, so you need to revert to the output mode in that case.

### What network speed does OBS Teleport need?

The project says at least 1 Gbps of a stable connection is required and highly recommended. You can try a lower quality stream with less bandwidth, but the tuning is left to you to experiment with.

## Sources

- [fzwoch/obs-teleport on GitHub](https://github.com/fzwoch/obs-teleport)
- [Issues](https://github.com/fzwoch/obs-teleport/issues)
- [License: GPL-2.0](https://github.com/fzwoch/obs-teleport/blob/main/LICENSE)
- [README](https://github.com/fzwoch/obs-teleport/blob/main/README.md)
- [Releases](https://github.com/fzwoch/obs-teleport/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fzwoch-obs-teleport