Send a live service from your main campus to any number of satellite campuses over ordinary venue internet — using nothing but an S3-compatible bucket you control.
Two OBS Studio plugins. No subscription, no dedicated encoder or decoder hardware, no inbound ports at any site, and no company that can price you out later.
Free software under the GPLv3. Built by the projects team at Stage Audio Works, a worship AVL integrator working across Africa.
Why this exists
Multisite streaming is well served by commercial platforms, and the teams behind them have earned their place. But those platforms are largely unavailable outside the developed world — and where they are available, the recurring cost can exceed a congregation's entire annual AV budget.
This is a set of tools instead of a managed service. Nobody answers the phone. In exchange: you own the storage, you own the content, and the ongoing cost is a few dollars a month of object storage.
The design priority, in order, is reliability, then quality, then simplicity — and latency last. A campus that is a minute behind but never drops a frame is worth far more than one that is two seconds behind and stutters.
Everything is written to disk before it is sent, sent again until the bucket confirms it, and buffered deeply at the far end before it plays. Minutes of the service sit at the campus in advance, so an outage part-way through is something the congregation never sees.
How it works
The main site muxes OBS's encoded frames into CMAF segments and writes them to a bucket. Each campus polls two small JSON files to find what is live, then pulls segments down ahead of playback into a local cache. There is no central server, no database and no vendor — the bucket is a dumb file store, and all of the intelligence is at the edges.
The invariant that makes it reliable: a segment is listed in the manifest only after the bucket has confirmed it stored. If a campus can see an entry, the object exists. Retries, crash resume and deep buffering all build on that one rule.
Very little, and deliberately so. Everything moves over ordinary HTTPS to object storage. There are no inbound connections, no port forwarding, no static IP, no VPN and no firewall rules to negotiate with a building's IT department. It works on connections that would defeat a direct stream: mobile data, LEO satellite, consumer fibre, and networks behind carrier-grade NAT. If a laptop at the site can load a web page, it can usually send or receive a service.
Features
Everything below is built and running today.
Durable store-and-forward upload. Nothing is lost through a dropped link, a crash, or a mid-service restart — the encoder keeps recording to disk and sends the backlog when the connection returns.
Hold the picture for a local welcome, resume, then catch up to live — or sit a set number of minutes behind all service. Scrub back, jump to a marker. What one campus does has no effect on any other.
Six tracks travel inside the same fragment and appear at the campus as separate sources — one download, one playout clock. Put whatever the room needs on them: a mix, individual mics on their own tracks, a click for the band. Label them once and the campus sees “Click”, not “Track 3”.
A Raspberry Pi 5 appliance with HDMI output, a splash and idle screen, and a browser control panel — installed by one script. No OBS at the far end, nothing for a volunteer to click by accident.
A separate container reads the same segments and pushes them to YouTube, Facebook or any RTMP destination — or over SRT to a broadcast partner or hardware decoder. You never upload the service twice.
Both docks serve a plain-language operator page on the church network. Drop a marker from the back of the room, check buffer depth from a phone. No app to install.
Every command is an obs-websocket vendor request, with events on state change. The Companion module puts them on a Stream Deck with buttons that light up — on air, held, behind live, link offline — and drives the Pi appliance directly too.
The campus lists what the room has recorded — what is on air, what finished, and what was cut short by an encoder that died. Even an interrupted service plays back from the beginning as video on demand.
List the room's services with their sizes from the encoder dock and delete one — or everything older than a chosen number of days — with confirmation and a verification pass. The service on air is never offered for deletion.
The Pi appliance can put its sound on the network as an eight-channel AES67 stream rather than leaving it inside the HDMI picture — so it appears in Dante Controller and routes to any Dante device, or to a console that takes AES67 directly. Open RAVENNA stack, one script, and a switch in the player's own page that shows the address it publishes to and whether the clock has locked.
CMAF segments from x264, NVENC, QuickSync or AMF, in H.264 or HEVC. Whatever your main site already encodes with, on whatever GPU it already has.
About 2.7 GB per hour of service at 6 Mbps. On a provider that charges no egress, sending the same service to ten campuses costs the same as sending it to one.
Use cases
The shape of the tool follows one job — carrying a service from a room with a production team to rooms without one. These are the ways that job tends to show up.
A congregation meets in a second building across town. The main campus preaches live; the satellite takes the feed on a screen, runs its own worship set before and after, and holds the picture while its own host welcomes the room. Timeslipping means the satellite's service order does not have to match the main site's minute for minute.
A new site on mobile data or LEO satellite, behind carrier-grade NAT, with no static IP and no IT department. Because everything is outbound HTTPS and the campus buffers minutes ahead, a link that would make a direct stream unwatchable produces a picture the room never sees falter.
A chapel, a youth room, a foyer screen. A Raspberry Pi appliance per room is cheap enough to leave installed and simple enough that nobody needs to operate it — it boots to an idle screen and picks the service up on its own.
The relay container reads the same segments already in the bucket and pushes them out to RTMP or SRT, a few minutes behind on purpose. The main site's uplink carries the service once, no matter how many places it ends up.
Several audio tracks arrive in the same download — a programme mix, mics on their own tracks, a click for the band, whatever the room needs. The campus engineer mixes them in the room rather than taking whatever the main site's stereo bus happened to be doing. From the Pi appliance they can leave as AES67 and land in a Dante network, so the console takes them over the same cable as everything else.
Every service is already sitting in the bucket as playable media. A campus can replay a past one from the recordings list, and a finished service downloads as a single MP4 with every audio track intact.
Tested — v0.1.17-alpha
Run end to end between two machines against real Cloudflare R2, with the Raspberry Pi campus player on real hardware.
Six audio tracks were carried throughout. Timeslipping held a campus a steady two and then three minutes behind live for hours; a scrub back nearly three hours and a return to live both recovered cleanly. Audio and video stayed in sync across the whole run, with the reported A/V offset holding between 0.005 s and 0.021 s through several decoder restarts.
The full picture — everything not yet proven, and the roadmap through storage redundancy, SDI output tiers and a headless encoder appliance — is kept in the repository under Known gaps and Roadmap.
The install guide gets you broadcasting between two machines in about twenty minutes. You need OBS Studio, a bucket, and a token that can read and write it.