Developers · Graphics
Same machine, no network.
Sending video between two apps on one computer by encoding it and pushing it through the network stack is a habit, not a requirement. macOS and Windows both have a shared-texture path built for exactly this, and it fits neatly on the end of an Airlive receiver.
The habit worth breaking
The usual way to get a camera into VJ software or a renderer is a network video format — publish it, subscribe to it, done. It works, and when the source and the destination are on two machines it is the right answer.
When they are on the same machine, it means encoding frames, handing them to the network stack, and decoding them again a few microseconds later, purely so two processes can talk. You pay latency and CPU for a journey of zero distance.
What the platforms already provide
Syphon — macOS
Shares GPU textures between applications on one Mac. A "server" publishes, any number of clients subscribe. Widely supported in VJ and media software, and it is one of the video inputs ProPresenter accepts.
Spout — Windows
The same idea for Windows: a sender, receivers, and an SDK that hides the GPU work. There is also a virtual-webcam receiver, which is a convenient escape hatch into apps that only take a camera.
Both are same-machine only, by design. That is the trade: no network reach, and in exchange, no encode.
Where this belongs in the chain
Your receiver already ends up with decoded frames. Publishing them as a texture is a short final stage rather than a new project:
- Receive and decode as any receiver does — discovery, framing, H.264 (AVCC, length-prefixed).
- Keep the frame on the GPU where you can. Decoding to a texture and publishing it directly avoids a round trip through system memory that would undo much of the benefit.
- Publish through the Syphon server or Spout sender API with a stable, recognisable name — that name is what the operator picks in the other app.
- Subscribe in Resolume, TouchDesigner, a Unity or Unreal project, or anything else that speaks it. The camera appears as a source with no configuration.
When it is genuinely better
- Live visuals. A camera feeding effects and mapping in real time, where every millisecond is visible to the audience.
- Engines. A live texture on a surface in Unreal or Unity — a virtual set, a screen inside a scene, an AR layer.
- Presentation on one Mac. If Bridge and ProPresenter share a machine, Syphon is the shorter path to the same result the venue screens guide reaches over the network.
- Heavily loaded machines. When the box is already rendering, giving back an encode and a decode per feed is real headroom.
When to stay on the network
- Two machines. No amount of wishing makes shared textures cross a network. Republish over NDI or SRT instead.
- Cross-platform delivery. Syphon is macOS, Spout is Windows. Something feeding both wants a network format.
- Recording or streaming out. Those need encoded video anyway, so the texture path buys nothing at the far end.
The honest summary
This is a narrow optimisation with a clear rule: same machine, keep it on the GPU; different machines, put it on the network. Knowing which one you're in saves more latency than most of the tuning people do afterwards — and the constraint list is unchanged either way. The protocol carries no audio, discovery is local, and the receiver password is access control rather than encryption.