OvenMediaEngine: a sub-second latency streaming server you run yourself

What OvenMediaEngine replaces in a live streaming stack

The README describes OvenMediaEngine (OME) as a sub-second latency streaming server that can deliver large-scale, high-definition live streams over Low Latency HLS (LLHLS) and WebRTC. The intended audience is an engineer building a live service rather than renting one: someone who has a source (a camera, an encoder, a browser) and wants viewers to see it with latency measured in fractions of a second, not the five to thirty seconds typical of segmented HLS.

The project is written in C++ and licensed AGPL-3.0. It runs on Linux: the README lists Docker, Ubuntu 18+, Rocky Linux 8+, AlmaLinux 8+ and Fedora 28+ as supported platforms, and notes that other Linux packages may work. There is no Windows or macOS target in that list.

The problem it addresses is the gap between ingest and playback protocols. Encoders push RTMP or SRT; browsers speak WebRTC and HLS. OME sits in the middle, accepts five ingest protocols (WebRTC, SRT, RTMP, RTSP, MPEG2-TS) plus OVT pull, optionally transcodes to adaptive bitrate renditions with its embedded transcoder, and serves the result over LLHLS and WebRTC. That single hop is the reason to consider it instead of stitching together an ingest daemon, a transcoder and a packager.

Ingest, transcode, package: the data path through OME

The README splits the pipeline into three stages. Ingest accepts push (WebRTC, WHIP with simulcast, SRT, RTMP, E-RTMP, MPEG-2 TS over UDP) and pull (RTSP, OVT). The embedded live transcoder then produces ABR renditions: video in VP8, H.264, H.265 (hardware only), AV1, or pass-through; audio in Opus, AAC, or pass-through. Output goes to viewers over LLHLS or WebRTC.

WebRTC output is where the sub-second claim lives, and the README lists the machinery that supports it: an embedded WebSocket signalling server, WebRTC over TCP backed by an embedded TURN server, retransmission with NACK, ULPFEC for VP8, H.264 and H.265, and in-band FEC for Opus. Those are the pieces that keep a stream alive when packets drop, which is the normal condition on the public internet.

LLHLS output carries a different feature set: DVR (live rewind), dump for VoD, ID3v2 timed metadata, DRM (Widevine, FairPlay, PlayReady) and WebVTT subtitles. Legacy HLS version 3 is also supported with a MPEG-2 TS container and DVR. Note that the docker-compose.yml comments say LLHLS and WebRTC should use different ports if both are enabled, which is a configuration detail worth reading before you copy the sample.

Scaling is handled by clustering in an origin-edge structure: the origin ingests and transcodes, edges relay to viewers. The repository ships separate origin and edge services in docker-compose.yml, with the edge exposing 4333 for signalling and LLHLS, 3479 for TURN, and 10004-10007/udp for WebRTC candidates.

Installing OvenMediaEngine with Docker and sending a first stream

The README's quick start points at the Quick Start Guide and Manual at docs.ovenmediaengine.com, and gives a Docker one-liner as the shortest path. Set OME_HOST_IP to the address viewers will reach, because the server advertises it as an ICE candidate.

docker run --name ome -d -e OME_HOST_IP=Your.HOST.IP.Address \
-p 1935:1935 -p 9999:9999/udp -p 9000:9000 -p 3333:3333 -p 3478:3478 -p 10000-10003:10000-10003/udp -p 10000:10000/tcp \
ovenmedialabs/ovenmediaengine:latest

Those ports map to specific roles in docker-compose.yml: 1935/tcp is the RTMP provider, 9999/udp is SRT, 9000/tcp is OVT for origin-to-edge traffic, 3333/tcp is WebRTC signalling and LLHLS, 3478/tcp is the WebRTC TURN server, and 10000-10003/udp are WebRTC candidates, described there as four ports for thread distribution. Port 10000/tcp is a direct TCP ICE candidate.

If you want the XML configuration on the host rather than inside the container, the README shows a variant with named volumes. The files then appear under /var/lib/docker/volumes/<volume_name>/_data, for example /var/lib/docker/volumes/ome-origin-conf/_data.

docker run --name ome -d -e OME_HOST_IP=Your.HOST.IP.Address \
-p 1935:1935 -p 9999:9999/udp -p 9000:9000 -p 3333:3333 -p 3478:3478 -p 10000-10003:10000-10003/udp -p 10000:10000/tcp \
-v ome-origin-conf:/opt/ovenmediaengine/bin/origin_conf \
-v ome-edge-conf:/opt/ovenmediaengine/bin/edge_conf \
ovenmedialabs/ovenmediaengine:latest

For a first test, the README offers a WebRTC live encoder at demo.ovenplayer.com/demo_input.html and a player at demo.ovenplayer.com, with and without TLS. The intended flow is to publish from the browser encoder and watch the same stream back in the player, which exercises the WebRTC path end to end without installing an encoder. The README does not document the exact URL path or stream name to enter in those pages, so expect to consult the Quick Start Guide for that step.

If you prefer to build rather than pull, the Dockerfile documents the build arguments: USE_LOCAL=false, USE_GPU=false and OME_ENABLE_JEMALLOC_LG_PAGE_MAX=false are the defaults, with build commands such as docker build -t ovenmediaengine:dev -f Dockerfile . and a --build-arg USE_LOCAL=true variant for local sources. A GPU build uses nvidia/cuda:12.0.1-devel-ubuntu22.04 as its base and runs with --gpus all.

Where OvenMediaEngine is the wrong choice

The AGPL-3.0 licence is the first constraint. If you plan to offer a modified OvenMediaEngine as a network service to users, the licence carries source-availability obligations that a permissive licence would not. The repository also ships a CLA.md and a LICENSE-3RD-PARTY file, which is a sign that third-party components were audited, but the README does not explain what those obligations mean for a commercial deployment. Read the licence text and the third-party file before you build a product on this.

The second constraint is operational. WebRTC needs a UDP path to the candidate ports, and the README's own port list includes 10000-10003/udp and a TURN server on 3478/tcp. On networks where UDP is filtered, or behind symmetric NAT without a reachable TURN relay, WebRTC delivery degrades or fails outright. LLHLS is the fallback, but LLHLS is not sub-second in the same way, and the docker-compose.yml comment warns that LLHLS and WebRTC should be on different ports if both are enabled, so a dual-protocol deployment is a configuration exercise, not a default.

Third, the README lists no Windows or macOS support. If your team develops on laptops and deploys on Linux, that is fine; if you need a desktop build, this is not it. The README also does not document rollback or downgrade between releases, so version pinning is on you. There is no GUI mentioned anywhere in the README; control is via XML configuration, a REST API, and the launcher script ome_launcher.sh -c origin_conf seen in docker-compose.yml.

OvenMediaEngine compared with an RTMP-only media server

The obvious alternative is a classic RTMP ingest server paired with HLS output, the model most tutorials still describe. The difference is in the last mile. RTMP is a TCP protocol and HLS is segmented; latency accumulates in the segment buffer, which is why those stacks are measured in seconds. OME keeps RTMP as an ingest option (port 1935 in the Docker examples) but does not depend on it for delivery, offering WebRTC and LLHLS instead.

A second alternative is to assemble the pipeline from separate open source components: one process for ingest, one transcoder such as FFmpeg, one packager for LLHLS. That gives you control over each stage and lets you swap parts. OME bundles all three plus an embedded signalling server and TURN server in one binary and one configuration tree. The trade-off is the reverse of modularity: you get fewer moving parts and a single port list to manage, but you also inherit the project's choices about codecs, DRM and clustering rather than picking your own. The README lists a REST API and admission webhooks, so automation is possible, but the extension surface is the project's, not a plugin ecosystem.

A third option is a commercial managed streaming service. That removes the port, TURN and transcoding work entirely. It also removes your control over latency and cost at scale. OME exists for the case where that trade is unacceptable.

Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-23. Recent releases are v0.21.0 on 2026-08-13, v0.20.5 on 2026-03-26 and v0.20.0 on 2025-12-19. The cadence is roughly a feature release every few months with patch releases between, which matters if you pin versions: the gap between v0.20.0 and v0.21.0 is about eight months, and v0.20.5 sits in the middle.

Upgrade cost is dominated by configuration, not code. The Docker examples mount origin_conf and edge_conf as volumes, and the server is launched with ome_launcher.sh -c origin_conf. If a release changes configuration keys, you will be editing XML on the host rather than rebuilding. The README does not publish a migration guide or a compatibility statement between releases, so the honest position is that you should read the release notes for each version you cross and keep your configuration under version control.

On licence: AGPL-3.0 is a strong copyleft licence. The README and repository do not offer guidance on commercial use beyond the licence file itself, and there is a CLA.md for contributors. If your deployment is internal, the calculus is different from a public service. This is not legal advice; read LICENSE and LICENSE-3RD-PARTY and decide with someone qualified.

Editorial conclusion

Adopt OvenMediaEngine if you need sub-second latency and can run a Linux server with the port set the README lists, including UDP 10000-10003 and TCP 3478 for TURN. Do not adopt it if you want a managed service, a GUI, or a permissive licence for a closed product, since the code is AGPL-3.0. Before committing, verify that UDP is not blocked on your network path, because WebRTC candidate ports 10000-10003/udp and the TURN port 3478 are the parts most likely to fail behind a corporate firewall.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. OvenMediaLabs/OvenMediaEngine on GitHub
3. Project website
4. README
5. Releases