Adaptive HLS video, delivered from our own edge.
The player below pulls a segmented HLS stream from our CDN — the same delivery path we build for clients.
The source is encoded once into an H.264 and AAC ladder, then split into short segments with a playlist describing them. A player requests the playlist, then pulls segments as it needs them — so playback starts almost immediately and only the watched part is ever downloaded.
Those segments are static files, which is what makes this scale: once a segment is cached at an edge, serving it to the next ten thousand viewers costs nothing extra. No media server sits in the request path.
Contribution is deliberately open-ended, so a broadcaster can use whatever they already have.
RTMP or SRT from OBS and hardware encoders, or WebRTC published straight from the browser.
ffmpeg produces the rendition ladder and segments it for HLS, recording an archive copy at the same time.
Segments are served from our CDN, so viewer numbers are limited by cache capacity rather than server count.
A finished broadcast becomes an on-demand recording immediately, using the same player and the same delivery.
The same pipeline covers both. A live broadcast writes segments as it goes and the playlist grows; an on-demand recording is a fixed playlist of segments that already exist. Players treat them identically, so one integration covers both cases.
Latency is a dial rather than a fixed property — standard HLS sits a few seconds behind, low-latency HLS brings that down to around two, and genuine sub-second delivery is a different transport we can put in where a conversation depends on it.
Whether that is a launch event, a training library, or live streaming built into an app you are planning, we have the pipeline already.