Not the same as streaming
A second site is a different problem from a public stream, and treating them as the same is where multi-site setups go wrong.
The audience is a room, not a person. A hundred people watching together, on a large screen, in a space set up for it. A stall that a single viewer at home would shrug at is a room full of people looking at a frozen frame.
Delay matters more. If the two sites are in contact (a shared start time, a video call between them, people texting family across sites) a large lag becomes noticeable and awkward.
The consequence of failure is higher. A viewer at home who loses a stream refreshes or gives up. A room of a hundred people who lose the service have nowhere to go and nothing to do, and someone standing at the front has to handle it.
And you know exactly who is receiving. This is the useful difference. A public stream goes to whoever finds it; a second site is a specific screen in a specific building. That means you can control access properly rather than relying on an obscure link.
Enrolled screens
The model that fits is enrolment: the receiving screen is registered once and afterwards recognised.
Practically, that means someone at the second site sets the screen up a single time, an invitation link and a code, and from then on it reconnects by itself whenever it is switched on. No login before each service. Nobody at the far end needs to understand anything.
That last property is what makes multi-site sustainable. If the second site needs a technical person present before every service, you have not solved distribution; you have created a second staffing requirement in a building that probably has fewer volunteers than your main one.
Fast or resilient... you must choose
There is a genuine trade-off here, and it is worth understanding because the right answer differs by situation.
Low delay. The far site stays close to real time... under a second is achievable over a direct connection. Good when the sites interact, when timing matters, or when a visible lag would be strange.
The cost: with almost no buffer, there is nothing to absorb a network hiccup. A brief interruption is visible.
Buffered. The far site deliberately runs some seconds behind, holding a reserve. A dropout of a few seconds is invisible, because the buffer covers it while the connection recovers.
The cost: the far site is permanently behind. If the sites are in any kind of contact, that gap is noticeable.
How to choose: if the two sites communicate during the service, take low delay and accept occasional visible interruptions. If they run independently, the second site simply receives, take the buffer, because a room that never sees a dropout is worth more than a room that is a few seconds behind.
If the connection at the second site is unreliable, take the buffer regardless. A resilient link that lags beats a fast one that stutters, in a room.
What the second site needs
A screen with a browser. As with any receiving screen, the display device does the work. No specialist decoder.
A network connection. Ideally a wired one at the far site. This is the piece that most often needs attention, and it is worth attending to before the first service rather than after the first failure.
Somebody to turn it on. That is the whole job, once enrolment is done.
A plan for when it fails. This is the part people skip. Someone at the second site should know what to do if the screen goes dark: who to call, whether to wait, and what happens if it does not come back. Not because failure is likely, but because a room of people needs someone with an answer.
The honest constraints
Some things to know before planning around this.
This is a higher-tier capability. Sending to a second site is not part of the free or entry-level plans. Worth establishing before you build a plan around it.
Your upload still matters. You are sending one stream out of the originating building, so this is far better than serving every viewer individually. But that one stream must be steady, and a venue with a jittery connection will have a second site that shows it.
Someone still runs the service. Multi-site distributes the output, not the operation. The main site is still producing, and if that machine has trouble, both rooms have trouble.
When a second site is the wrong answer
Worth saying, because the technology being available does not make it right.
If the second site's audience would be better served by a public stream they watch at home, do that instead... it is simpler and it fails more gracefully.
If nobody at the second site can take responsibility for the room, the technology will not fill that gap. A screen in a room with nobody accountable for it is a failure waiting for an audience.
And if the second site is next door, this is the overflow-room case, which is simpler: keep it on your own network and skip the complexity entirely.
The summary
A second site is a room, not a viewer. Design for that: enrol the screen so nobody needs to log in, choose your delay trade-off deliberately based on whether the sites talk to each other, and make sure someone at the far end knows what to do if it stops.
Get those three right and the second building becomes routine. Get them wrong and you have built something that works in testing and fails in front of a hundred people.