Live streaming
A live-streaming service that accepts any common encoder, transcodes to an adaptive stream in real time, and turns every broadcast into an on-demand video without a re-upload.
The problem
Teachers, churches and small broadcasters want their own channel instead of a platform that owns the audience. It gives each channel a stream key: point OBS or a webcam at it, viewers get an adaptive stream, and when the broadcast ends the recording flows straight into the video library.
Challenges
Accepting any encoder without trusting it
Broadcasters arrive over RTMP from OBS, SRT from hardware encoders, or WHIP from a browser. A dedicated media server terminates all three, but the decision about whether a stream key may publish belongs to the application: the media server asks the API for permission on every publish, and only the local transcoder is allowed to read a stream back.
Live transcoding that never corrupts a segment
A single lost packet during live transcoding can corrupt a segment for every viewer at once. The transcoder reads the feed over TCP rather than UDP, produces two renditions with short segments, and is stopped with an interrupt rather than killed, so the playlist is always finalised cleanly.
Broadcasts that die without saying goodbye
Encoders crash, laptops sleep and networks drop, so "the stream ended" is rarely announced. A reaper sweeps every minute: a broadcast with no new segment for two minutes is over, a requested stop gets a short grace period, and half-started streams are cleaned up. Live segments are only removed once the recording is safely stored.
Implementation
Recording without a re-upload
When a broadcast ends, its recording is handed to the on-demand video pipeline as a background job that retries for up to a day, so an outage never loses a recording, and the broadcaster never uploads the same hours twice.
Plans that depend on each other
Live streaming builds on the video platform underneath it, so a channel can only be switched on when that dependency is active. The account layer enforces the relationship rather than each product checking it.
Why this stack
- MediaMTX
- One media server that speaks RTMP, SRT and WHIP and can defer authorisation to the application.
- ffmpeg
- Real-time transcoding to adaptive HLS with predictable, short segments.
- Go
- The permission hooks, reaper and job hand-off are small concurrent services that fit naturally in the same binary as the rest of the platform.
- S3-compatible storage
- Live segments and finished recordings share the object store the video library already uses.
What it does
- Live servers set up from a single command, and moved to a new machine with a reinstall command
- Streams pushed over RTMP, SRT or browser WHIP, or pulled from another source
- Low-latency or standard adaptive HLS playback
- Rewind while live, quality templates, backup sources and ad breaks
- Recordings saved straight into the video library
- Health and status for each server and stream, plus a player check