A live stream can be a one-off event (a Sunday service, a product launch, a conference keynote, a wedding, a webinar, a panel at a small festival), an occasional broadcast (a weekly show, a monthly Q&A), or a continuous 24/7 channel. The plumbing the streaming industry has built up for the last fifteen years assumes all three need the same heavy stack: a camera, an encoder, an RTMP push to a streaming server, a cloud transcoder, a packager, a CDN, and a player. Five moving parts, four bills, three places where authentication can fail, and one architecture diagram that nobody on your team can draw from memory.
For a small to mid-size audience, you do not need any of that. Not the streaming server, not the cloud transcoder, not the packager, and not the CDN. Whether you are streaming for two hours on Sunday morning or running a channel that never sleeps, the same simple architecture covers it.
The dirty secret is that on a modern Mac, four of those five boxes already exist inside the laptop on your desk. The H.264 encoder Final Cut Pro uses for export is the same hardware encoder that ships in every Apple silicon chip. The HEVC and AV1 encoders are right next to it. Packaging fragmented MP4 into HLS segments is a few hundred lines of code. Uploading those segments to a web server is HTTPS PUT, which every server already speaks. The streaming server in the middle is not a law of physics. It is just a thing the industry got used to renting.
My Live TV Channel is a macOS app that does the whole chain in one piece of software. Capture, encode, package, publish. The output is broadcast-standard HLS, the same format Netflix, Apple, Disney+ and the BBC ship to their viewers. The destination is whatever HTTPS endpoint you point it at. Your own website on a cheap shared host (no CDN in front of it), an S3 bucket, Cloudflare R2, Bunny Storage, or Akamai MSL4 if you happen to run live events at the scale of a Super Bowl. The app does not care. It writes segments. The internet picks them up.
This article walks through what changes when you collapse the streaming chain into one app, what it costs, and where the limits are.
What you actually need to go live
Three things, in this order.
A Mac with a video input. Any Apple silicon Mac (M1 onward) works. The built-in FaceTime camera is fine for talking-head streams. A USB camera plugs in and shows up as a source. Your iPhone shows up as a Continuity Camera, which is genuinely good as a B-camera for events because Apple does the wireless and the autofocus for you. Pick any built-in, USB, or Continuity Camera as your input. A floating picture-in-picture preview keeps the camera visible while you work in another window.
A place to put HLS segments. This is the only piece that matters and the only piece people overthink. The app uploads small files (.m4s segments, six seconds each by default, plus tiny .m3u8 playlist files) over HTTPS PUT or POST. Anything that accepts HTTPS PUT works:
- A directory on your own web server, with PHP, Python, Node or whatever you already run, accepting the upload and writing it to disk. Most static hosts (cPanel, plain Apache, plain nginx) can be configured to do this in under thirty minutes.
- An Amazon S3 bucket. Optionally with CloudFront in front for global delivery.
- Cloudflare R2 (S3-compatible API, no egress fees), Bunny Storage, Wasabi, Backblaze B2.
- Akamai MSL4, which is the storage tier behind Akamai’s live ingest. Same protocol, scale-tested for the largest live events on the planet.
- Any other endpoint that speaks HTTPS PUT and returns a 2xx code.
A 7-day free trial of the app. After that the live publishing feature requires a weekly subscription that starts at $0.99/week. Camera preview and local recording are always free, which is worth knowing if you only need a recorder.
That is the whole shopping list. There is no streaming server. There is no RTMP. There is no media server VM you need to keep patched. The encoder, the transcoder, the packager and the publisher are inside the app on your Mac. The only thing on the wire is finished HLS, going one way, into a bucket.
What it replaces
It is worth being concrete about what disappears from the architecture diagram.
The streaming server. Wowza Streaming Engine, Nimble Streamer, Ant Media Server, AWS Elemental MediaLive, Mux’s RTMP ingest, and the dozen other services in this category exist for one reason: to receive an RTMP stream from an encoder and turn it into HLS. If your encoder produces HLS directly, the streaming server has nothing to do. You can delete it from the diagram and from the budget.
The cloud transcoder. AWS Elemental MediaConvert, Mux Live, Bitmovin, Google Live Transcoder. They charge by the minute of input and the minute of output. A 1080p stream pushed up at one bitrate, transcoded into four output bitrates, runs into real money fast even for a single afternoon event, and into serious money on a continuous channel. The Apple silicon hardware encoder in your Mac is faster, free, and the same chip family that runs Final Cut Pro’s export. Encoding the four ABR variants directly on the Mac eliminates the transcode line item entirely.
The packager. AWS Elemental MediaPackage, Unified Streaming, Wowza Streaming Cloud’s packager, all of which exist to wrap a stream into HLS or DASH. The app produces broadcast-standard HLS at the source. There is nothing left to package.
The CDN, in the small case. This is the one that surprises most people. CDNs exist for two reasons: terminating heavy global traffic close to the viewer, and absorbing flash-crowd traffic that an origin cannot handle. The cheap web server you already have can deliver HLS segments perfectly well on its own up to a real, finite number of concurrent viewers. The math is straightforward: a 1080p HLS variant at 5 Mbps over a gigabit uplink saturates the link at roughly 200 concurrent viewers (1000 ÷ 5). The 720p variant at 3 Mbps brings that to about 330. The 540p variant at 1.8 Mbps reaches around 550. In a real adaptive-bitrate audience the viewers are spread across all those rungs (mobile users on lower variants, desktop on higher), so a small VPS comfortably carries a few hundred concurrent viewers and often more, depending on the device mix. That covers the vast majority of one-off events and small-to-mid channels. You only need a CDN when the audience consistently outgrows that envelope, which is later than most people think.
Per-GB bandwidth surprises. When your origin is a streaming server you rent and your delivery is a CDN you rent, every viewer-minute touches both meters. Self-hosting moves the meter to your own infrastructure: a $5 VPS with generous bandwidth, an R2 bucket with no egress fees, a CloudFront distribution at your reserved-rate, whatever you have already negotiated. Nobody is going to ring your phone at month-end because your stream went viral.
Platform terms. YouTube and Twitch will give you a free RTMP endpoint and a player, and in return they decide what is monetisable, what is age-gated, what gets recommended, what gets taken down on which week. Self-hosting is not free in time or money, but it does not come with a third-party rulebook. Your stream, your domain, your terms.
What stays the same
Self-hosting is a real shift, and it is honest to be clear about what it does not change.
You still pay for bandwidth somewhere. The bytes have to come from somewhere. The choice is between a streaming SaaS that bundles transcoding plus delivery into one bill, and self-hosting where you separately pay for the storage tier and the egress. For most non-trivial audiences the second is cheaper. For a stream with five viewers, a free YouTube account is cheaper. Match the tool to the audience.
You still need a player. Any HLS player works.
Video.js, hls.js, Shaka Player, the browser’s native HLS in Safari and
on iOS, Apple TV’s AVPlayer, the Roku, Fire TV and Android
players. None of these need anything special from your origin. If your
destination URL serves a valid index.m3u8, every modern
player will play it.
You still need to think about latency. Standard HLS with six-second segments runs at roughly 18 to 30 seconds of glass-to-glass latency. That is fine for talk shows, music sets, sermons, lectures, behind-the-scenes content, gaming highlights, FAST channels, anything that is not an auction or an esports tournament. For sub-five-second latency you need LL-HLS, WebRTC or DASH-LL, and the calculus changes.
You still need uptime, scaled to the broadcast. A Mac on your desk is fine for a one-off event: an SSD, a UPS, a wired connection and you are good for the afternoon. For a long-running or always-on broadcast you want a Mac mini in a cool spot, a UPS, a wired connection, and ideally a second Mac you can fail over to. The app’s local recording feature gives you a backup file in either case. None of this is harder than running a streaming server, and most of it is friendlier.
The five-minute test
The fastest way to find out if this works for you is to publish a test stream to a public endpoint and inspect the result. The app ships with a “HTTP PUT Server” destination type that needs no authentication and no setup on your end:
- Open the app, go to Destinations, tap +.
- Pick HTTP PUT Server.
- Name it “Test”, upload URL
https://ams.ireplay.tv/hls/test/, playback URL the same. - Leave authentication blank.
- Test Connection. The server returns HTTP 201.
- Save.
- Profiles, create a profile, pick the test destination, defaults are fine.
- Live, pick the profile, Go Live. Talk to your camera for thirty seconds, Stop.
- The summary screen shows the playback URL. Open it in Safari, in
ffprobe, in any HLS player.
If it plays, your Mac just acted as the encoder, the transcoder, the packager and the publisher. End to end, with no streaming server in the loop. The bytes you are watching travelled directly from the H.264 encoder on your Apple chip into a public bucket and out to your player. The whole pipeline lived in one app.
That same destination type points at any HTTPS PUT endpoint. Replace the URL with one of your own bucket and you are self-hosting a stream on your own infrastructure.
One-off stream, or a 24/7 channel that wraps it
A single live stream is a complete product on its own. Press Go Live for the duration of the event, Stop when it’s over, leave the recording on your domain as a replay. That is a perfectly valid use of the app and is what most users will do most of the time.
What happens when you are not live is the question that separates an event from a station. If a viewer lands on your channel page on a Tuesday afternoon when nothing is being broadcast, they see a “stream offline” screen and bounce. Most independent broadcasters lose that traffic without realising it.
The companion app, My TV Channel, fills that gap. It is a 24/7 playout tool: feed it your existing video library, and it builds a continuous linear schedule (VOD2Live, sometimes called FAST) that runs around the clock. Viewers who tune in at any time of day always land on something, even when no live event is in progress. The same My TV Channel account you use for playout connects directly to the My Live TV Channel app, so when you press Go Live, your live feed is inserted into the running schedule. Viewers tuned in for VOD2Live see your live broadcast take over. When you stop, the schedule resumes from the right place.
You can adopt this in either order. Start with one-off live events and add 24/7 presence later when the audience is asking for it. Or start with a 24/7 schedule and use the live app to drop in news, breaking moments, Q&A sessions, or scheduled live shows on top.
The live tool, the playout tool, and the publishing tool are three apps that share one storage destination. There is no streaming server anywhere in this architecture, only the storage you chose, the Mac on your desk, and the players in your viewers’ hands.
Honest verdict
If you are streaming a small show with three viewers and no plans to grow, sign up for a free YouTube account and put the embed on your site. You are not the audience for this.
If you are running a paid stream, a members-only broadcast, a Sunday service for your congregation, a niche FAST channel, a corporate live event, an internal town hall or training session rebroadcast to your on-prem web server, a sports league, a wedding broadcast for distant family, a creator-owned linear channel, or anything where platform terms and per-GB bills are real costs, the math gets interesting fast. A Mac mini, a destination bucket or even a plain web server, and a $0.99/week subscription replace a stack of cloud invoices that, taken together, used to start at three figures a month and rise from there. The architecture diagram fits on a sticky note. The number of vendors who can take your stream down with a TOS update goes from “several” to “zero”.
The streaming server in the middle was always optional. The hardware in every Mac on every desk has been quietly waiting to do that job for years. My Live TV Channel is the piece of software that finally lets it.