ZLMediaKit: a C++ media server that converts between streaming protocols

Why protocol conversion is the whole design

The repository description lists the protocols in one run: WebRTC, RTSP, RTMP, HTTP, HLS, HTTP-FLV, WebSocket-FLV, HTTP-TS, HTTP-fMP4, WebSocket-TS, WebSocket-fMP4, GB28181, SRT, STUN and TURN. That list is not a feature checklist, it is the design. The README states the project supports protocol interoperability, protocol conversion on demand, pull on demand, play before push, and reconnecting a dropped publish within a timeout so players do not notice.

The mechanism matters for expectations. Conversion in this project is remuxing, not transcoding: it repackages the same H.264 or H.265 elementary streams into a different container or transport, which costs almost no CPU. The README states codec support per protocol, and the pattern is consistent throughout. RTSP covers H264, H265, AAC, G711, OPUS, MJPEG, MP3, VP8, VP9 and AV1, with a note that other codecs can be forwarded but not converted. RTMP covers a shorter list ending at OPUS, with the same caveat.

If your two endpoints disagree on codec, this is where the open source version stops and the closed edition begins, which is the single most important thing to understand before you commit to it.

The protocol families and what each one is actually for

The README's feature list is organized by protocol, and reading it that way is the fastest way to understand which family you need.

RTSP and RTMP are the ingest and egress workhorses, each with server, player, publisher and push client roles. RTSP additionally offers four RTP transports: over UDP, over TCP, over HTTP, and RTP multicast, plus Basic and Digest authentication with a configurable asynchronous interface. RTMP covers the browser-shaped variants too, including HTTP-FLV and WebSocket-FLV, which is what makes FLV the bridge between a media server and a web player.

HLS is handled with mpegts or fmp4 output and a built-in HTTP file server, and the README describes cookie tracking used to simulate HLS playback as a long connection, which enables on-demand HLS pull and playback statistics. TS and fMP4 each get HTTP and WebSocket variants, so an MP4-fragment stream can be delivered over a WebSocket when a browser cannot take the plain HTTP path.

GB28181 is the surveillance protocol and gets the most detailed treatment, because it is the hardest one. The README lists RTP servers for UDP and TCP carrying PS, TS or ES, conversion out to RTSP, RTMP and HLS, both active and passive push modes with matching RESTful endpoints, bidirectional voice intercom, and a line about bridging the surveillance protocol stack with the live streaming protocol stack.

WebRTC is the most developed corner of the tree

WebRTC has its own top level directory in the repository, plus a `webrtc/USAGE.md` linked from the README for the ICE-full mode that lets the library act as a WebRTC client for pulling, pushing and peer to peer work. That directory placement is a signal about how much of the codebase this really is.

The feature list covers both directions: WebRTC publish converted out to other protocols, and other protocols converted in for WebRTC playback, with the encoding formats matching RTSP so nothing has to change in the middle. There is a bidirectional echo test for verifying a deployment, simulcast publishing, and TWCC for congestion-driven bitrate adjustment.

Two entries stand out. The README claims single-port, multi-threaded client network connection migration, marking it as unique among open source projects at the time of writing. And it lists support for WHIP and WHEP, which are the ingest and egress protocols that replaced the older signalling conventions for WebRTC streaming, along with datachannel support, RTP and RTX retransmission for loss recovery, GOP buffering for fast start on playback, and WebRTC over TCP for networks that block UDP.

The closed edition adds an RTC traffic proxy specifically to solve the Kubernetes problem where HTTP signalling and the actual media traffic land on different pods. That is a deployment problem rather than a protocol problem, and it is a good reminder that WebRTC behind a pod-per-node scheduler needs deliberate architecture.

Server, C API and the directories that make up the build

The repository positions itself in three ways: a cross-platform streaming solution for mobile and embedded targets, a commercial grade streaming server, and an SDK for network programming. The third one is the `api/` directory, described as a complete standard C API usable as an SDK or callable from other languages.

The tree is broader than a single binary. Alongside `server/`, `src/` and `conf/` there is a `player/` directory, a `golang/` directory for Go bindings, an `ext-codec/` directory for external codec integration, `3rdpart/` for third party code, `srt/` for the SRT protocol, `tests/`, `tools/`, `www/` for web assets, `postman/` for API collection files, and `Android/` for mobile. Build inputs sit at the top: `CMakeLists.txt`, `cmake/`, a `dockerfile` alongside `dockerfile_py` and a `docker/` directory, `build_docker_images.sh`, `sources.list` for the Debian package feed, and `default.pem`.

server/
src/
conf/
api/
player/
webrtc/
golang/

Two configuration details are easy to miss and expensive to discover late. The README states that config files and SSL certificates support hot reload, so certificate rotation does not need a restart, and that virtual hosts are supported to isolate different domains. It also lists traffic statistics, publish and pull authentication, and full IPv6 support as standard behavior.

A CJK-only README, a truncated one, and a license question

Three practical things about the documentation are worth stating directly.

First, the primary README is in Simplified Chinese. An English version exists at `README_en.md`, linked from the top of the Chinese one, and the project's documentation site is at docs.zlmediakit.com. For anyone reading English, the English README is the entry point and the wiki pages it links to are the real reference for the HTTP API and the HTTP hook API.

Second, the licensing story is genuinely ambiguous and you should resolve it yourself. GitHub reports the license as NOASSERTION, meaning nothing was detected automatically, while the README displays an MIT badge pointing at the LICENSE file, and a `LICENSE` file does exist at the root. Do not treat the badge as the last word on a project this size; open the file and read what it actually grants before you build a distribution on top of it.

Third, there are no published releases in the repository. For a library consumed by others this is a real consideration, since you cannot pin a tagged version and must either build from a commit or consume the published Docker images, which the README badges point at under the zlmediakit organization on Docker Hub. The last push recorded is 2026-09-20, so the master branch is where current work lands.

Editorial conclusion

ZLMediaKit is one of the more capable pieces of streaming infrastructure available as open source, and the reason is structural rather than promotional: it implements both ends of most media protocols against a shared core, so conversion happens by remuxing where the codec allows and only needs the closed components when it genuinely cannot. What the open repository gives you is a server, a C API, a player, protocol conversion, on-demand pull and WebRTC with WHIP and WHEP. What it does not give you is transcoding, which the README places in the closed professional edition along with JT1078 support, IPTV variants, S3 recording, WebRTC cluster proxying and AI inference. Read the `conf/` directory and the RESTful API documentation before deploying, and confirm the LICENSE file yourself given that the repository metadata reports no license while the README badge says MIT. The last push was on 2026-09-20.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. ZLMediaKit/ZLMediaKit on GitHub