Software and Encoding: OBS, vMix, and the Mac Mini

May 31, 2026 31 min read Audio Engineering

live-productionobsvmixencodingmacosstreamingchurch-tech

Contents

This is the fourth post in our series on broadcasting meetings and church services. So far we have built the signal flow, chosen and placed cameras behind a Blackmagic ATEM switcher, and tamed the audio chain. At the end of the last post the cameras were cut and the program output was leaving the switcher — and that is exactly where this one picks up. We have one clean program feed, and now we have to do something with it: dress it up with graphics, encode it down to a bitrate the internet can carry, push it to a platform, and capture a pristine copy for the archive. This is the production-and-encoding layer, and it is where a surprising number of otherwise-good systems fall apart.

The central question of this post is deceptively simple: what runs your production? A free cross-platform app? A paid Windows powerhouse? A sealed appliance with no operating system to crash? The honest answer is “it depends on how many failure points you can tolerate and how many features you actually need,” and the bulk of what follows is helping you make that trade-off with your eyes open. I will spend extra time on one configuration that comes up constantly in volunteer-run shops and is more nuanced than people expect: running the whole thing on a Mac mini. There is a real, specific reason that machine is both a great choice and a slightly awkward one, and it is worth understanding before you commit.

OBS Studio vs vMix vs Hardware Encoders

Three broad approaches dominate this layer, and they sit at three very different points on the spectrum of cost, capability, and reliability.

OBS Studio is free, open-source, and runs on Windows, macOS, and Linux. The current release as of this writing is the 32.x line, with separate native installers for Intel and Apple Silicon Macs. OBS is genuinely excellent: scene-based compositing, unlimited sources, filters, transitions, a built-in streaming and recording engine, and a deep plugin ecosystem. It is the most widely deployed live-streaming software on the planet, which means an enormous body of tutorials, forum threads, and community knowledge — the same “abundant help when something breaks” advantage that makes mainstream gear worth buying. The catch is that OBS gives you the building blocks and expects you to assemble the production. It has no built-in multi-channel replay, no integrated NDI without a plugin (a good free one exists), no native title editor worth the name, and no instant-replay or scoreboard tooling. For a switched broadcast where the ATEM already does the cutting and you are mostly adding graphics, encoding, and recording, that is fine — OBS does those things very well. For a software-first production where the computer is the switcher and the title system and the replay deck, you will feel the gaps.

vMix is the opposite philosophy: a paid, Windows-only application that bundles a full production studio into one program. Switching, a powerful title designer, instant replay with multiple channels, a real audio mixer, a virtual-set/chroma engine, multi-bitrate streaming to several destinations at once, NDI in and out as a first-class citizen, and a deep input list. vMix is sold as a one-time perpetual license — currently roughly $350 for Basic HD, around $700 for HD, about $1,200 for 4K, and roughly $1,200 for the Pro tier (pricing shifts and major version upgrades can carry a fee, so confirm at purchase). The editions gate input counts and output resolution; the higher tiers unlock more inputs, 4K, and the advanced replay and audio tooling. vMix is a favorite of sports, event, and ambitious church productions because one operator on one capable PC can run an entire multi-camera show with replays and lower-thirds without a separate switcher at all. The two real costs are the license and — more importantly for this post — the platform: vMix runs only on Windows. There is no macOS version, there never has been, and there is no sign of one coming. If your shop is a Mac shop, vMix is simply off the table unless you buy a Windows machine for it.

Dedicated hardware encoders abandon the general-purpose computer entirely. These are sealed appliances — a Blackmagic Web Presenter, the streaming engine built into an ATEM, a Resi or BoxCast box — that take a video input and push a stream out with no operating system to update, no scene to misconfigure, and dramatically fewer ways to fail at 10:55 on a Sunday. They do far less than OBS or vMix: typically no compositing, limited or no graphics, one or a few stream destinations. But what they do, they do reliably, and “boots in fifteen seconds and just streams” is worth a great deal when your operator is a volunteer and your margin for error is zero. We will give these their own section at the end, because they are the right answer more often than software-centric people like to admit.

Here is the comparison that matters when you are choosing:

	OBS Studio	vMix	Hardware Encoder
Cost	Free	~$350–$1,200 one-time (by edition)	~$500–$3,000+
Platforms	Windows, macOS, Linux	Windows only	N/A (appliance)
Switching	Scene-based (manual)	Full production switcher	None (pass-through)
Graphics / titles	Sources + plugins; weak native titler	Strong built-in title designer	Minimal or none
Instant replay	No (plugin workarounds)	Yes, multi-channel (higher tiers)	No
NDI	Via free plugin (in + out)	Native, first-class	Sometimes (model-dependent)
Multi-destination stream	One (more via plugins/restream)	Several simultaneous	Usually one
Recording / ISO	Yes; one clean record + optional sources	Yes; multi-channel ISO record	Some models record to USB
Failure points	Many (OS, app, plugins, drivers)	Many (OS, app, drivers)	Very few
Best for	Mac shops, graphics + encode over an ATEM	Windows software-first productions	Maximum reliability, fewest boxes

The decision tree I actually use: if you already have an ATEM doing your switching and you mostly need graphics, encoding, and a clean record, OBS is the obvious, free, cross-platform answer. If you want a single Windows machine to be the entire production — switcher, titles, replay, encode — and you can field an operator who knows it, vMix is superb and worth its price. If a computer is overkill, or you want to eliminate failure points and you are willing to lose compositing flexibility to get reliability, a hardware encoder wins. None of these is “best.” They are answers to different questions.

Running Production on a Mac Mini

Here is the configuration that keeps coming up, because it is genuinely attractive: a Mac mini as the production computer. It is small, silent, cheap relative to its power, and the current Apple Silicon models are absurdly capable for the money. But it carries three specific constraints — software, ports, and thermals — and the interaction between them is where people get surprised. Let’s take them in order.

Software: OBS yes, vMix no. This is the first and most important fork. vMix does not run on macOS, full stop, so the moment you choose a Mac mini you have chosen OBS (or a niche alternative like Ecamm Live, which is Mac-native and pleasant but far less common). For a switched ATEM-based show this is no loss — OBS is the right tool for that job anyway. But understand that you are giving up vMix’s built-in replay, titler, and multi-destination streaming the instant you pick the Mac. If those features are load-bearing for your production, buy a Windows machine instead. If they are not, the Mac mini is a wonderful little production box.

Encoding: hardware (VideoToolbox) vs x264 software. OBS on Apple Silicon can encode two ways. Apple VideoToolbox uses the dedicated media engine baked into the M-series chip — H.264, HEVC, and on newer chips AV1 — offloading the work from the CPU entirely. x264 is a pure-software CPU encoder. The trade-off is the classic one: hardware encoding is nearly free in terms of CPU load and runs cool, while software x264 produces slightly better image quality at a given bitrate but eats CPU cores. On Apple Silicon the hardware encoder is very good, especially at the conservative bitrates most church and meeting streams use (1080p30 at 4,500–6,000 kbps), where it looks effectively indistinguishable from software for talking-head and stage content. The honest caveat the OBS community has documented: hardware encoders trade a little compression efficiency for speed, so to match x264’s perceptual quality you generally need on the order of 5–10% more bitrate, and at high bitrates and frame rates (1080p60 well above 6 Mbps) the hardware encoder stops scaling quite as cleanly. For a live stream on a Mac mini, use VideoToolbox — the CPU headroom and thermal relief are worth far more than the marginal quality difference, and you will want those CPU cores free for compositing, NDI, and your high-bitrate local recording. Save x264 for a situation where you have CPU to burn and you are squeezing a very tight upload pipe.

Here is the comparison in table form:

	VideoToolbox (hardware)	x264 (software)
Where it runs	M-series media engine	CPU cores
CPU load	Very low	High (scales with preset)
Heat / thermal	Minimal	Significant on a fanless/single-fan mini
Quality per bitrate	Excellent; needs ~5–10% more bitrate to match x264	Best per bit at slower presets
High-bitrate scaling	Stops scaling cleanly above ~6 Mbps 1080p60	Scales well with bitrate
Codecs	H.264, HEVC, AV1 (chip-dependent)	H.264 (and x265 separately)
Recommendation for a mini	Use this for the live stream	Reserve for tight pipes with CPU to spare

The NDI vs capture-card reality on macOS. This is the subtle one. To get your ATEM’s program feed into OBS on a Mac mini, you have two roads. The first is a capture card — a Blackmagic UltraStudio over Thunderbolt, which presents the SDI/HDMI program as a clean, low-latency video device OBS can grab directly. The second is NDI over the network — the ATEM (or another NDI source) sends video as IP packets, and the OBS NDI plugin receives it. NDI is seductive on a Mac because it needs no Thunderbolt device and no extra box: just an Ethernet cable. But NDI on macOS carries all the network caveats we hammered on in the cameras post — it consumes real bandwidth, adds latency, and ties your video reliability to your network’s health — plus it leans on the same CPU you are trying to keep free for encoding. On a Mac mini specifically, where you have a limited number of Thunderbolt ports and a thermally constrained chip, the cleanest, most reliable path for your main program input is a Thunderbolt capture card, and NDI is best reserved for graphics feeds (ProPresenter, which we will get to) where a little latency is harmless and the alpha channel is the whole point. Use the network for graphics; use copper-to-Thunderbolt for the program. That division keeps the fragile thing (the network) out of your most critical path.

Thermal and port constraints. The Mac mini is small, which is its charm and its limitation. The base M4 mini cools passively for light loads and spins a single fan under heavier work; it is extremely quiet, but Apple’s compact thermal design does throttle slightly under sustained, pegged load — early benchmarks put sustained-throttled performance roughly 8–10% below peak. For live streaming with hardware encoding this basically never matters, because VideoToolbox keeps the chip cool. It can start to matter if you insist on x264 software encoding at a high preset, plus heavy NDI, plus a high-bitrate local recording, all at once, for two solid hours — that is the scenario where a fanless-ish mini could warm up and throttle mid-service. The fix is simply to encode in hardware. On ports: the M4 mini gives you three Thunderbolt 4 ports, and the M4 Pro mini gives you three Thunderbolt 5 ports (up to 120 Gb/s), plus USB-A, HDMI, and headphone on both. Three Thunderbolt ports sounds like plenty until you count: your capture card wants one, your fast external recording SSD wants one, and a Thunderbolt dock or a second display wants the third — and now you are full. Plan your port budget before you buy, and prefer the M4 Pro if you want Thunderbolt 5 headroom and more GPU and memory bandwidth for compositing-heavy scenes.

Here is the whole Mac mini production setup, with the deliberate split between the copper-to-Thunderbolt program path and the network graphics path:

   ATEM Television Studio HD8                     ProPresenter
   (switcher, SDI program out)                   (lyrics / lower-thirds,
        |                                          alpha output)
        | SDI PROGRAM                                   |
        v                                               |
   +--------------------+                               | Syphon (same Mac)
   | UltraStudio        |                               |   - or -
   | Recorder           |                               | alpha NDI (network)
   | (Thunderbolt)      |                               |
   +---------+----------+                               |
             |  Thunderbolt cable                       |
             v                                          v
   +=====================================================================+
   |                        MAC MINI  (M4 / M4 Pro)                      |
   |                            OBS  STUDIO                              |
   |   +-------------------------------------------------------------+   |
   |   |  PROGRAM SCENE                                              |   |
   |   |    [ UltraStudio capture  = full-frame switched video ]     |   |
   |   |    [ ProPresenter alpha overlay = lyrics / lower-thirds ]   |   |
   |   +-------------------------------------------------------------+   |
   |        |                                       |                    |
   |        | VideoToolbox (HW) encode              | VideoToolbox (HW)  |
   |        | ~4.5-6 Mbps  H.264                     | 20-50 Mbps .mkv    |
   |        v                                        v                    |
   |   STREAM OUT  -------------------------->   LOCAL ARCHIVE RECORD     |
   +=====|===============================================|===============+
         |                                               |
         v                                               v
   YouTube / Facebook / RTMP-SRT               Fast external SSD
   (the public stream)                         (high-bitrate master)

   Port budget (3 x Thunderbolt):  [1] UltraStudio capture
                                   [2] external recording SSD
                                   [3] dock / second display

The takeaway: a Mac mini running OBS, encoding in hardware, taking its program over a Thunderbolt capture card and its graphics over NDI or Syphon, is a quiet, reliable, and remarkably affordable production box — as long as you respect the software (no vMix), the encoder choice (hardware), the input strategy (capture card for program), and the port budget (three Thunderbolt, plan them).

One Box, Three Jobs: Control, Switching, and the Encode

A question that comes up the moment people see how capable the M4 mini is: can that same machine run the camera controls, drive the ATEM, and do the encoding, all at once? The short answer is yes, comfortably — but the reason it is comfortable is worth understanding, because it corrects a mental model that trips a lot of people up.

The thing to internalize is that only one of those three jobs is actually work for the computer. The ATEM is a hardware switcher: the cutting, dissolving, keying, and downstream graphics all happen inside the box, in dedicated silicon, whether or not a computer is attached. When you run ATEM Software Control on the Mac, you are not asking the Mac to switch — you are running a control surface that sends tiny command packets to the switcher, which does the actual work. Camera control is even lighter: panning, tilting, zooming, and recalling presets are a trickle of VISCA-over-IP packets, a few bytes each, that would not register on a twenty-year-old laptop. The only job that puts real load on the chip is the encode, and as we just covered, VideoToolbox hands that to the M-series media engine and barely touches the CPU. So you are asking the mini to do one real task and two featherweight ones. It is not breaking a sweat.

Job	Who actually does the work	Load on the Mac
Switching (cut / dissolve / key)	The ATEM hardware	None — the Mac only sends commands
Camera control (PTZ, presets)	Tiny VISCA-over-IP packets	Negligible
Graphics / compositing	OBS (GPU compositing)	Light
Encoding the stream	VideoToolbox media engine	The only real load — and it is cheap

This is also the place to clear up the most common misconception, which is that OBS would “control” the cameras and the ATEM. OBS is a compositor and encoder, not a switcher. It receives the already-switched program feed from the ATEM, dresses it up, and streams it — it does not do the live cutting between cameras; the ATEM does. OBS can optionally drive your PTZ cameras: the open-source PTZ Controls plugin adds VISCA-over-IP pan/tilt/zoom and preset recall right inside the OBS window, which is handy if you want one application for everything. But that is OBS borrowing a small control function, not OBS becoming the switcher. Your switching still lives in the ATEM. So the honest picture of “running OBS on the Mac” is this: OBS does the encoding, the graphics, and the recording, and optionally the PTZ control; the ATEM keeps doing the switching no matter what.

Where, then, should the camera control actually live? You have three good options, and they are not mutually exclusive:

ATEM Software Control’s PTZ palette — the Mac app that is already open to configure the switcher has a camera-control page that drives VISCA cameras and recalls presets. Free, and already in front of you.
A hardware joystick — a PTZOptics SuperJoy or similar gives you tactile pan/tilt/zoom and physical preset buttons that work independently of the Mac. For a live operator this is the nicest feel, and crucially it keeps working if the computer hangs.
The OBS PTZ Controls plugin — preset recall and movement inside OBS itself, so a single operator can cut graphics and re-aim cameras from one window.

Granting that the mini can do all three, the real decision is an architectural one, and it is about reliability rather than horsepower. There are two clean ways to wire this, and they differ in where the encode lives and therefore in what happens when something fails.

Architecture A — the ATEM streams, the Mac is just control. Most ATEMs from the Mini Pro up, including the Television Studio HD8, have a hardware streaming encoder built in. Let it push the stream straight to YouTube or RTMP, and the Mac’s only job is to be a control surface — ATEM Software Control plus PTZ presets. The payoff is large: if the Mac wedges, reboots for an update, or a volunteer fat-fingers OBS, the stream keeps going, because the stream never depended on the computer. This is the fewest-failure-points, no-second-takes setup, and it is the right default when your graphics needs are modest.

Architecture B — the ATEM feeds OBS, the Mac encodes. The ATEM program comes into the Mac over the Thunderbolt capture card (exactly as in the diagram above), and OBS does the encoding, the graphics, the ProPresenter overlays, the high-bitrate archive, and any multistreaming. You choose this when you want what OBS adds. The cost is that the encode now lives on the computer, so the computer is back in the critical path: if OBS or the Mac dies mid-service, the stream dies with it.

ARCHITECTURE A -- Mac is control only (most robust)

  Cameras --SDI--> ATEM --[built-in encoder]--> YouTube / RTMP
                    ^
                    | control packets only (VISCA + ATEM cmds)
                 Mac mini  (ATEM Software Control + PTZ presets)
                 -> if the Mac dies, the STREAM KEEPS GOING


ARCHITECTURE B -- Mac encodes (most flexible)

  Cameras --SDI--> ATEM --SDI program--> [capture] --> Mac mini
                    ^                                   (OBS: graphics,
                    | control packets                    encode, archive,
                 Mac mini --------------------------------+ multistream)
                                                           |
                                                           v
                                                    YouTube / RTMP
                 -> if OBS / the Mac dies, the STREAM DIES with it

The pragmatic answer for most rooms: if you mainly need clean switched video and audio out to a single platform, run Architecture A and use the mini purely as a control surface — it is the bulletproof choice, and the M4 is wildly overqualified for just control. Reach for Architecture B only when ProPresenter overlays, a high-bitrate archive, flexible scenes, or multistreaming are genuinely load-bearing — and even then, configure the ATEM’s built-in encoder as a one-click fallback so that if the Mac goes down, you can be back on the air from the switcher in seconds. Either way, the M4 mini has the headroom to be all three things at once; the only real question is how many of your eggs you are comfortable putting in that one basket.

Capture Cards: Getting the Program Into the Computer

Whatever the computer, you need a way to turn the switcher’s SDI or HDMI program output into a video device the software can see. There are three meaningfully different approaches, and the right one depends on whether your computer has PCIe slots, what it has for ports, and how much you are willing to spend.

PCIe DeckLink cards are Blackmagic’s internal capture cards, and they are the gold standard for a desktop tower or a rackmount production PC. They slot into a PCIe lane and present extremely low-latency, rock-solid SDI/HDMI capture to the operating system. The relevant current models: the DeckLink Mini Recorder 4K is a low-profile card with 6G-SDI and HDMI 2.0a inputs capturing up to 2160p30 — the affordable single-input workhorse. The DeckLink Duo 2 gives you four independent 3G-SDI inputs (up to 1080p60) on one card, effectively four capture cards in one, which is how you feed a software switcher multiple SDI cameras. The DeckLink Quad HDMI Recorder does the same trick for four HDMI sources. And at the top, the DeckLink 8K Pro G2 handles Quad Link 12G-SDI and HDMI 2.1 up to 8K for cinema and high-end work. For our use case — capturing a single ATEM program feed into a desktop running OBS — the Mini Recorder 4K is plenty. The catch, of course, is that a DeckLink needs a PCIe slot, which a Mac mini, a laptop, or any small-form-factor machine simply does not have.

UltraStudio Thunderbolt devices solve exactly that. These are external Blackmagic capture boxes that connect over a single Thunderbolt cable and present the same kind of clean, low-latency device a DeckLink does, with no slot required. The UltraStudio Recorder is the small, capture-only unit with 3G-SDI and HDMI inputs up to 1080p60, powered over Thunderbolt — ideal for getting an ATEM program into a Mac mini or a laptop. There are larger UltraStudio models (more I/O, monitoring, higher resolutions) for bigger rigs, but for “one program feed into a Mac mini running OBS,” the Recorder is the natural pick. This is the device that makes the Mac mini production box work cleanly.

The ATEM Mini as a USB capture device. Here is the clever budget path that a lot of small shops land on. The ATEM Mini family (which we covered as switchers) exposes its program output over USB-C as a standard UVC webcam device. Plug the ATEM Mini into your computer over USB and it shows up in OBS as a capture device — no DeckLink, no UltraStudio, no extra money. You get your fully-switched program (with whatever the ATEM put on it — cuts, keys, downstream graphics) straight into OBS as if it were a webcam. This is a completely legitimate and very common way to feed OBS, and it is essentially free if you already own the ATEM Mini. The honest limitations: the ATEM Mini compresses that USB stream as MJPEG, which is not as pristine as an uncompressed DeckLink/UltraStudio capture; only one host can use that USB connection at a time (so you cannot simultaneously record to a USB drive and feed a computer over the same USB on the base models); and you are on HDMI inputs to the switcher, with all the distance constraints that implies. For a small portable kit it is excellent. For a permanent SDI install you have probably already bought a Television Studio HD8, and you will feed OBS from its SDI program out via an UltraStudio or DeckLink.

Capture path	Connection	Best for	Resolution	Notes
DeckLink Mini Recorder 4K	PCIe (internal)	Desktop / rackmount PC	Up to 2160p30	Cheapest clean capture; needs a PCIe slot
DeckLink Duo 2	PCIe (internal)	Software switcher (4 SDI in)	Up to 1080p60	Four independent SDI inputs
UltraStudio Recorder	Thunderbolt	Mac mini / laptop	Up to 1080p60	No slot needed; bus-powered; the mini’s friend
ATEM Mini (USB)	USB-C (UVC)	Portable / budget kits	1080p	Free if you own it; MJPEG-compressed; HDMI-only inputs

Building Scenes, Lower-Thirds, and Graphics

With the program landing in OBS (or vMix), the production software’s first job is composition. In OBS the unit of organization is the scene: a named, ordered stack of sources that you switch between. Even when an ATEM is doing the heavy switching, you will still build a handful of OBS scenes — and the layering order matters, because sources higher in the list draw on top of those below.

A sane scene layout for a switched broadcast looks like this:

Program scene — the ATEM program capture as the bottom layer (your full-frame switched video), with a graphics overlay layer on top.
Pre-service / countdown scene — a holding slide, a countdown timer, and a music bed, shown before the service begins and during transitions.
Lower-third overlay — a graphic, typically anchored to the lower portion of the frame, naming the speaker or referencing a Scripture passage.
Full-screen graphics / hold — an “we’ll be right back” or a sermon-title bumper.

A lower-third is just a graphic with a transparent background composited over the lower portion of the video — a name and title for a speaker, a song title, a giving prompt. You can build these as PNG files with alpha and drop them into OBS as image sources, but the moment you want them to be dynamic — pulling the current speaker’s name, the current song, the current Scripture reference — you want them generated by a graphics application. That is exactly the seam where ProPresenter enters, and it is important enough to get its own section. The key concept to hold onto: a lower-third or any text overlay needs a transparent (alpha) background so the video shows through everywhere the graphic is not, and getting that alpha channel cleanly from your graphics app into OBS is the whole game.

vMix users have it easier here: vMix’s built-in title designer is a genuine strength, letting you build animated lower-thirds, scoreboards, and full-screen graphics with data fields you can update live, all inside the same application. This is one of the concrete things you give up by choosing OBS on a Mac. With OBS you will either hand-build static graphics or — far better — drive your text and lyric graphics from a dedicated presentation program.

ProPresenter, NDI, and Syphon

For churches especially, the dedicated presentation program is almost always ProPresenter, the application running lyrics, Scripture, sermon points, and lower-thirds on the in-room screens. The reason it matters here is that ProPresenter can also send those same graphics — with a transparent background — into your production software, so the words on the wall and the words on the stream come from one source of truth. There are two ways it does this on the platforms that matter, and they map neatly onto our OS discussion.

NDI is the cross-platform path. ProPresenter can output a screen as an NDI source over the network, and crucially it supports alpha-channel (transparent) NDI output — you add an NDI screen in ProPresenter’s screen configuration, enable the Alpha Key tab, and ProPresenter sends just the lyrics/graphics with everything else transparent. In OBS you install the NDI plugin (free), add the ProPresenter NDI source to your overlay layer, and — this is the step people miss — set the source’s color format to one that carries alpha, such as BGRA, or the transparency will not come through and you will get an opaque black box over your video. Done right, this gives you live lyrics keyed cleanly over your program, updating instantly when the operator advances a slide in ProPresenter, with no cable between the two machines beyond Ethernet. The price of admission is the same NDI tax as always: it wants a solid gigabit network, ideally a dedicated or VLAN-isolated switch for AV traffic, or you will drop frames and chase latency.

Syphon is the macOS-only, no-network alternative, and it is lovely precisely because it skips the network. Syphon is an open-source macOS technology for sharing video frames between applications on the same Mac, GPU-to-GPU, with essentially no latency and no Ethernet involved. If ProPresenter and OBS are running on the same Mac mini, ProPresenter can publish a Syphon output and OBS can grab it with the Syphon plugin — again with alpha, configured as a “Straight” alpha key in ProPresenter’s screen settings. This is the cleanest possible graphics path on a single-machine Mac setup: no network dependency, no NDI bandwidth, the lowest latency available. The constraints are that both apps must be on the same Mac (so it does not help if ProPresenter lives on a separate computer at the lyric operator’s station) and that it is macOS-only (Windows/vMix shops use NDI). On the Mac mini production box, if you can run ProPresenter on the same machine, Syphon is the move; if ProPresenter lives on a separate operator’s Mac, use alpha NDI between them.

The principle either way: graphics travel as alpha sources, lyrics come from ProPresenter, and that division keeps your stream’s text identical to the room’s text. Use Syphon when it is one Mac; use alpha NDI when graphics live on the network or across machines.

Recording a Clean ISO While You Stream

Here is a discipline that separates shops that have a usable archive from shops that have a folder of regrettable 3,500-kbps YouTube re-downloads: always record locally, at a higher bitrate than you stream, simultaneously.

Your live stream is, by necessity, compressed to survive the public internet — somewhere around 4,500–6,000 kbps for 1080p in most church and meeting deployments. That is fine for live viewing and terrible as a master. If your only copy of the service is what the streaming platform kept, then your sermon archive, your clips for social, and your re-edits all start from a heavily-compressed source that can never be improved. The fix costs almost nothing: while OBS (or vMix) is streaming, have it also record to a local drive at a much higher bitrate — 20,000–50,000 kbps, or a constant-quality (CRF/CQP) mode, into an MP4 or MOV. This local file is your archive master. It looks dramatically better than the stream, it survives an internet outage that kills the stream entirely, and it is the file your video editor will thank you for.

OBS makes this trivial: the Recording settings are independent of the Streaming settings, so you set streaming to your platform’s recommended bitrate and recording to a high-quality local target, and OBS runs both at once from the same scenes. A few hard-won rules:

Record to a fast local SSD, not a network share and not a nearly-full drive. On a Mac mini, this is often where one of your precious Thunderbolt ports goes — a fast external SSD dedicated to recording. A dropped write mid-service can corrupt the file.
Use a robust container. OBS recording to raw .mp4 will corrupt the entire file if the app or machine crashes mid-record. Record to .mkv (which survives a crash and can be remuxed to .mp4 afterward) or enable OBS’s “automatic remux to mp4” so a crash does not cost you the whole service.
Encode the recording in hardware too, on a Mac mini, so the archive record does not fight your live encode for CPU. VideoToolbox can run both simultaneously with room to spare.

The next level up is the ISO record — recording each input as its own separate, clean file in addition to the program. vMix’s higher tiers do multi-channel ISO recording natively, and the ATEM Television Studio HD8 ISO switcher we recommended in the last post records every camera input as a separate file (plus a DaVinci Resolve project) onto a USB-C drive at the switcher. ISO recording is gold for post-production — it lets an editor re-cut the service after the fact, fix a missed shot, or build a multi-cam edit — but it is a “nice to have,” not a “must have,” for the basic goal of a good archive. At minimum, capture one clean high-bitrate program record every single time you stream. If your budget reaches an ISO-capable switcher or vMix Pro, the per-input records are a wonderful bonus.

The Encoder-Appliance Alternative

For all the power of OBS and vMix, a computer running a live production has a lot of moving parts, and every one of them is a thing that can fail at the worst possible moment: an OS update that rebooted overnight, a driver that flaked, a plugin that crashed, a scene a volunteer accidentally deleted, a fan that finally gave out. Sometimes the right engineering decision is to remove the computer from the critical path entirely and let a sealed appliance do the encoding. You give up compositing and graphics flexibility; you gain a box that boots in seconds and does exactly one job reliably.

ATEM built-in streaming. The simplest version: most ATEM switchers from the Mini Pro up, including the Television Studio HD8 we recommended, have a hardware streaming engine built in. You can stream directly to YouTube, Facebook, or any RTMP/SRT destination from the switcher itself, with no computer in the path at all. If your graphics needs are modest (the ATEM’s own media players and downstream keyers can handle a logo bug and basic lower-thirds), this is the fewest-boxes architecture possible: cameras into the ATEM, ATEM streams out. It is wonderfully robust. What you lose is the rich compositing, the ProPresenter alpha overlays, and the flexible multi-source scenes that OBS/vMix provide.

Blackmagic Web Presenter. When the switcher does not stream (or you want streaming decoupled from switching), a Web Presenter HD or 4K is a small dedicated encoder: it takes an SDI input and streams it out over Ethernet via RTMP (H.264) or SRT (H.264/H.265), with a little built-in screen showing input, audio levels, and bitrate. The 4K model can take a 1080p input and upscale to a 4K stream. It is a clean, reliable, single-purpose box. The notable limitation is that it streams to one destination at a time — no simultaneous YouTube-and-Facebook from the device alone.

Resi and BoxCast. These are the church-and-event-focused streaming platforms whose hardware (and software) encoders are built around solving the problem that wrecks more streams than anything else: a flaky internet connection. Standard RTMP drops frames the instant a packet is lost, and even SRT only recovers within a handful of seconds. Resi’s patented Resilient Streaming Protocol (RSP) takes a fundamentally different approach — a store-and-forward model where the encoder buffers locally (up to ten minutes), verifies and re-sends every frame until the cloud confirms bit-correct receipt, and resumes exactly where it left off if the connection drops entirely. For a building with marginal or congested internet, that is transformative: the stream stays perfect through network hiccups that would freeze or pixelate an RTMP feed. BoxCast offers comparable resilient-encoder hardware and a managed platform. The trade-off is that these are platform commitments with ongoing subscription costs and their own ecosystems, not just a one-time box — you are buying reliability-as-a-service, and for a church whose internet is the weak link, that can be exactly the right purchase.

When does the appliance win over the computer?

Your internet is unreliable and you need store-and-forward resilience (Resi/BoxCast).
You want the absolute fewest failure points and your graphics needs are minimal (ATEM built-in streaming or a Web Presenter).
Your operators are volunteers who cannot troubleshoot an OS, a driver, or OBS at 10:55 on a Sunday.
You do not need OBS/vMix compositing, ProPresenter alpha overlays, or multi-source scenes.

When does the computer win?

You need rich graphics, lower-thirds, ProPresenter overlays, pre-service loops, and flexible scenes.
You want a high-bitrate local archive record alongside the stream (though some appliances record too).
You want to stream to multiple destinations at once.
You have an operator comfortable driving software live.

Wrapping Up

The production-and-encoding layer is where a clean program feed becomes a finished, watchable, archived broadcast — or where an otherwise-solid system picks the wrong moment to fall over. The choices stack up like this. OBS is the free, cross-platform default, and the right call when an ATEM already does your switching and you mainly need graphics, encoding, and a clean record — which describes most volunteer-run shops. vMix is the paid, Windows-only powerhouse worth every dollar when you want one machine to be the whole production, replay and titles included — just remember it locks you to Windows. A hardware encoder — the ATEM’s built-in streaming, a Web Presenter, or a resilient Resi/BoxCast box — is the answer when fewer failure points beat more features, and it is the right answer more often than software people admit.

If I had to compress this post into a starting recommendation for a typical Mac-shop church: a Mac mini (M4 Pro if the budget allows) running OBS, encoding the stream in VideoToolbox hardware, taking the ATEM program over an UltraStudio Recorder on Thunderbolt, pulling lyrics and lower-thirds from ProPresenter over Syphon if it is on the same machine or alpha NDI if it is not, and recording a high-bitrate .mkv archive to a dedicated SSD while it streams. Mind your three Thunderbolt ports, keep the encode in hardware so the little mini never breaks a sweat, and put the fragile thing — the network — only where a hiccup is survivable.

In the next post in the series, we will take that finished, encoded stream and follow it out the door: bitrate and resolution choices for the public internet, getting a reliable connection to your platform, redundancy and bonded/failover internet, and what to monitor so you catch a dying stream in seconds rather than after the service is over.