A single-channel broadcast platform with playback controls, chat moderation and follower updates.
The application runs one live channel and the conversation around it. A broadcaster sends in the live feed. Viewers watch in their browsers, and the owner moderates the chat from the same administration area.
This live streaming platform case study covers that connecting work. We connected broadcast intake to playback preparation, channel status and audience updates. The video segments can sit on different storage and delivery setups, while a single application still owns the live channel. The scope stays with one owner and one channel.
The challenge
Starting a broadcast kicks off several separate jobs at the same moment. The incoming connection has to be checked. Playback qualities get prepared, and the first video segments must be ready before anyone can watch. Channel status and notifications then follow that progress.
A short drop in the feed should not fire a run of repeated go-live alerts. The viewer side needs some slack as well. A player recovering from buffering can struggle to catch up if it keeps getting pushed toward the newest segment.
What we built
A broadcaster's software links up over RTMP and identifies itself with a stream key. Only one broadcaster can be live at any moment, and the application goes offline when that feed stops.
Viewers get a browser player with several playback-quality options and embedding support. The owner sets the output variants and the latency from that same area. Live playlists do double duty here. They carry the playback information and also signal that a viewer is present.
WebSocket chat adds message visibility controls and text filtering. It also brings address bans and a set of custom emoji into the room. Viewers can sign in through supported external identity flows. The owner handles moderation from that interface.
Follower notifications, browser alerts and signed webhooks tie the channel to its wider audience. Delayed go-live notifications and a repeat-alert guard smooth over short breaks in the broadcast.
Segment delivery through encoder callbacks
The server passes the feed to FFmpeg. As output becomes ready, the encoder sends playlists and segments to a small local HTTP receiver. The receiver checks the path and classifies the file, then hands it to the chosen storage handler.
Local disk and compatible object storage both sit on this output path. A configured serving endpoint can push that delivery through a cache or a CDN when needed. The application still owns the live channel's state throughout.
Playback recovery and chat filtering
The player keeps comparing its own playback time against the live edge of the stream. With enough video buffered, it can lift the playback speed a little. After a rebuffer it eases off that catch-up behaviour. Latency settings control the balance between segment length and the buffering margin the player keeps.
Chat filtering makes an explicit allow-or-deny decision before a message goes through. The owner can also step in to moderate messages or change their visibility while the broadcast is still running.
Persistent follower deliveries
Outgoing federation deliveries live in SQLite. Workers claim queued rows with a deadline, retry failures with backoff and honour any provider retry instructions. When a newer status supersedes a pending update, a shared coalescing key lets the queue replace the older one.
Plugins run inside a WebAssembly host. Each one declares its permissions and runtime limits. It has to stay within them when it extends chat or channel behaviour.
Project success
The owner can accept an authenticated broadcast feed, pick its output qualities and latency, and moderate the chat beside it. Viewers get browser playback and embedding, with filtering and visibility controls over the conversation. Follower updates wait in an outgoing queue until they are handled, retries after a failed delivery included.
Storage and serving configuration decide how the generated video reaches the audience. The client can therefore run the broadcast channel and all its audience tools together. Delivery capacity is managed through that chosen setup.
Technology stack
Backend
Go, chi
Live video
RTMP, FFmpeg, HLS
Player and interface
Next.js static export, Video.js
Chat and persistence
WebSockets, SQLite, sqlc
Extensions and federation
WebAssembly, Extism, wazero, ActivityPub
Other engagements
Recognize the pattern?
If one of these looks like your situation, the discovery call is where we find out how close.
