# smart_rtmpd and a streaming server you unzip and run

> smart_rtmpd is a closed-source streaming media server that takes an RTMP, RTSP or SRT input and republishes it as RTMP, RTSP, HTTP-FLV, WebSocket-FLV, HLS, DASH, SRT and WebRTC, with a single binary and no third-party library dependency. The interesting trade is that the deployment simplicity comes with no source code to read, patch or vendor.

**superconvert/smart_rtmpd** — Smart RTMPD is a high-performance, easy-to-use, multi-system-supported and easy-to-maintain streaming media server. It supports multi-protocol push streaming and multi-protocol pull streaming.

- Repository: https://github.com/superconvert/smart_rtmpd
- Stars: 584 · Forks: 95
- Language: HTML
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/superconvert-smart-rtmpd

## A streaming server whose selling point is deployment

The README positions smart_rtmpd against nginx-rtmp and SRS directly: if you do not understand it, you can think of it as functionally similar to nginx-rtmp and srs, with the differences being performance, cross-platform operation, no dependency, and a deployment and maintenance cycle that is simply unzip and run. That framing is worth taking at face value rather than as marketing, because it tells you what the author is optimising for. This is a server for people who want a stream to appear on several endpoints, not a programmable media platform.

The operator it targets is someone with a single encoder feed, an OBS instance or an RTSP camera, and a set of consumers: an RTMP client, a browser playing HLS, a low-latency WebRTC viewer, an NDI or SRT receiver. The repository's topic list names the same neighbourhood, with nginx, srs, wowza and vmix among the tags, which is the competitive set the author positions the project against.

The claim about hardware is unusual enough to check. The README says the software is relatively small, that even an embedded device can be deployed with it, and that the aim is to squeeze the hardware to lower the operating cost. The repository root carries a c1000k/ directory, which is the conventional name for a connection-handling benchmark, so the performance argument has at least a place to live in the tree.

The audience is an operations person rather than a developer. Nothing here is a library, a plugin or an API for building a product on. It is a relay that you configure, start and leave running.

## One input, seven outputs, and a matrix with sharp edges

The mechanism is a protocol fan-out. A client pushes over SRT, RTMP or RTSP, and the server republishes that stream over rtmp[s], http[s]-flv, ws(s)-flv, http[s]-hls, https[s]-dash, rtsp[s], webrtc and srt. The input and output detail table is where the design becomes concrete, and it is a table with real constraints rather than a list of checkmarks.

The first constraint is video codec. HLS and DASH are marked as only video for an RTMP input carrying h264 with pcma or pcmu audio, and only video for hevc with pcma or pcmu. With aac audio the same rows gain full HLS, DASH and SRT output. In other words, the audio codec choice, not the video codec, decides whether you get an HLS stream with sound.

The second constraint is HEVC and WebRTC. Every hevc row in the WebRTC column is reduced to only audio, either pcma and pcmu or aac converted to opus. An h264 input can leave over WebRTC as h264 or vp8 with either audio type. So if your encoder is set to HEVC, the low-latency WebRTC path is unavailable for your video, and the WebRTC consumers of that stream get audio only.

The third constraint is the WebRTC profile, which the table fixes as video baseline level 3.1. That is a deliberate ceiling and it applies to the video you send out, not to the video you accept in.

The fourth is the codec table above it, which pairs h264 and h265 with either aac or pcmu and pcma, and offers vp8 with opus and h264 with pcma and pcmu specifically for the WebRTC path.

## The URL grammar is fixed: live or rec, nothing else

The URL description table is the shortest and most useful part of the documentation, because it states both the accepted form and the rejected one. The accepted live and recording addresses look like this:

```bash
|rtmp://192.168.1.1:1935/live/stream   |live stream|yes |
|rtsp://192.168.1.105:9554/live/music  |live stream|yes |
|srt://192.168.1.105:9000/rec/space    |record stream|yes |
```bash

The scheme, host and port vary by input, but the app tag does not. As the README puts it, only the "live" or "rec" app tag is supported, with no support for "sky", "class" or "record" as other app tags. The rejected examples are given in the same table, with rtmp spelled rmtp, a sky app tag, a class app tag, and a record app tag, each marked as a bad format.

That single rule does a lot of work in practice. Any stream address your encoders and players construct has to use one of two first path segments, so a deployment where different feeds need different mount points cannot express that here. The default ports are visible in the examples: 1935 for RTMP, 9554 for RTSP and 9000 for SRT. The vod mode uses a different scheme again, with HTTP on port 8080.

There is also a URL rewrite mechanism, listed among the features as support for a URL rewrite mechanism against various flexible business needs, with a rewrite row in the examples table marked as pending. Rewrite is therefore advertised but not documented on this page, which is a gap worth knowing before you plan a rewrite-dependent topology.

## Where it runs: Windows, Linux, FreeBSD, ARM64, Docker

The supported systems are listed as Windows, Linux with Ubuntu and CentOS named, FreeBSD, ARM64 and embedded systems. The README adds that the Linux and FreeBSD builds support multithreading and coroutines, and the claim is that the software runs on mainstream systems and would work even on a customised Linux distribution in principle.

The Docker story is deliberately minimal, which is unusual in a good way. Rather than publishing an image, the README says that for the Docker version you copy smart_rtmpd into the container and run it directly. Since the binary has no third-party library dependency, there is no package manager step and no shared library to resolve, so a container image is the binary and a base image. The repository root even carries rtmpd.zip and liveShow.zip, and a deploy_smart_rtmpd.sh script, so the artefact you deploy is the same artefact the author ships.

Two features matter for operating this in production. Hot plug support is listed, described as allowing smooth upgrade or maintenance while the system is running. And the configuration is described as portable, with a Windows configuration easily copied to Linux, ARM or FreeBSD and the reverse, using a unified data format to satisfy migration needs. For a team that replaces hardware or mixes platforms, that portability claim is the one to test first, since the readme gives no configuration file example to check it against.

The repository also documents cluster and cascade deployment as supported, alongside single-server deployment, and the examples table marks the cluster entry as pending, so the topology support exists but the write-up on this page does not yet cover it.

## The sister product smart_web and the WebRTC path

The README describes smart web as the sister version of smart_rtmpd, being smart_rtmpd with a web management interface added, with stronger features, a process watchdog, support for H264 and HEVC push and pull, remote configuration, log viewing and forwarding configuration. The operating systems named for it are Windows 10, CentOS 8.5, Ubuntu 22.04 and ARM64, and the details sit in smart_web.md in the repository. This is the real alternative to consider if you want management, since the difference is not a feature toggle but a different build with a watchdog and a web console.

For WebRTC specifically, the README points to whip_whep.md, which covers using whip and whep to push from OBS over WebRTC and pull in an H5 page. That path matters because WHIP and WHEP are the ingest and egress protocols that let a browser be a first-class participant rather than a downstream consumer of HLS.

The repository carries several sibling documents. web_dev.md covers the web interface, web_auth.md the authentication interface, webrtc.md and webrtc_im.md cover WebRTC and a WebRTC instant messaging mode, recording.md covers the recorder, and liveshow.md sits alongside the liveShow.zip artefact at the root. There is a web_admin/ directory too, and the repository's primary language is listed as HTML, which fits a web console being the bulk of the shipped code.

The authentication interface deserves attention. The feature list names support for an authentication and verification interface, and web_auth.md is linked from the examples table as the auth interface, but the behaviour of the free build is not described on this page. If you are publishing streams behind a paywall or a login, you need to read that file before you rely on it.

## What the licence situation actually is

The most consequential line for an adopter is short. The README states the software is free and not open source, that commercial application is allowed provided the logo and name are retained, and that source code licensing is limited to companies and available by contact.

That is a different thing from an open source streaming server, and it changes what you can do. You cannot read the implementation, you cannot audit how a stream key or an auth token is handled, you cannot patch a bug on your own schedule, and you cannot redistribute the binary inside your own product or under your own branding. The commercial-use clause is workable for a service you run for yourself, provided you keep the vendor's logo and name in the interface, but it is a constraint that a procurement process will ask about.

The project does offer paid support and OEM work, and the README explains the motivation at length, saying the vendor came from an IM product, references a company called FreeCommunication existing for eighteen years, and argues that a free tool is a route to visibility and funding rather than a refusal to earn money. Whether that reassurance matters to you depends on how much you need continuity.

For a streamed production service, the practical implication is a dependency you cannot inspect. That is a legitimate choice, the same choice nginx-rtmp or a commercial encoder would force, but it should be made deliberately rather than discovered at procurement.

## Release cadence, records and what the examples give you

The repository is not archived, and the last push was on 2026-10-18, the same day as the v.2.0.8 release. The release before it was 2.0.6 on 2026-06-06, and before that v.2.0.3 on 2025-03-10, so the pattern is a handful of tagged releases spread across roughly eighteen months rather than a frequent stream.

For a project that is not open source, release notes are the only visibility you get into what changed, and the tagged version numbers here are the whole upgrade story. There is no changelog file in the repository root, no upgrade guide, and no compatibility statement between versions, so an upgrade means replacing the binary and re-testing your own topology. Nothing in the tree suggests a rollback procedure.

The example directory is more helpful than the documentation here. It holds a .bat file per input and output combination, covering rtmp, rtsp and srt push with h264 or h265 and aac or pcma or pcmu audio, and matching pull scripts for rtmp, rtsp, srt, hls, dash and http-flv, plus vhost.txt and a spreadsheet that maps the protocol matrix. On Windows these scripts are the fastest way to confirm what the server will accept before you wire up a real encoder.

There is also a separate recording path documented at recording.md, a link to a third-party write-up on recording and another on NAT mode, and a link for building ffmpeg with RTMPS support if you need rtmps to a specific destination such as a social platform.

## Conclusion

smart_rtmpd is a good fit for an operator who needs to relay one encoder feed to several delivery protocols on a Windows, Linux, FreeBSD or ARM64 box, including an embedded board, and who values a single unzip-and-run binary over an open plugin ecosystem. It is a poor fit for a team that needs to read the code, patch it, vendor it under its own licence or audit the authentication path, because the project ships binaries and states plainly that the software is free but not open source. Before adopting, confirm your exact input and output codec pairing against the input and output detail table, since HEVC input cannot leave over WebRTC and HLS and DASH carry only video for pcma and pcmu inputs, and verify that the authentication interface in web_auth.md matches what you need, since the free version's behaviour there is not documented on this page.

## FAQ

### What protocols does smart_rtmpd support for push and pull?

A client can push over SRT, RTMP or RTSP, and the server republishes that stream as rtmp[s], http[s]-flv, ws(s)-flv, http[s]-hls, https[s]-dash, rtsp[s], webrtc and srt. The examples directory ships a push and pull script for each of those combinations.

### Is smart_rtmpd open source?

No. The README states the software is free but not open source, that commercial use is allowed provided the vendor's logo and name are kept, and that source code licensing is limited to companies and available by contact.

### Can I run smart_rtmpd on ARM64 or in Docker?

ARM64 is listed among the supported systems alongside Windows, Linux, FreeBSD and embedded systems. For Docker the README says to copy smart_rtmpd into the image and run it directly, since the binary carries no third-party library dependency.

### Why does my HLS stream have no audio?

The input and output detail table marks HLS and DASH as only video when the input audio is pcma or pcmu, for both h264 and hevc video. Add aac audio to the input and the same rows gain full HLS, DASH and SRT output.

### Which stream URLs are valid?

Only the live and rec app tags are supported, so rtmp://192.168.1.1:1935/live/stream and rtsp://192.168.1.105:9554/live/music are accepted while tags such as sky, class and record are marked as a bad format. The default ports shown in the table are 1935 for RTMP, 9554 for RTSP and 9000 for SRT.

## Sources

- [Issues](https://github.com/superconvert/smart_rtmpd/issues)
- [README](https://github.com/superconvert/smart_rtmpd/blob/master/README.md)
- [Releases](https://github.com/superconvert/smart_rtmpd/releases)
- [superconvert/smart_rtmpd on GitHub](https://github.com/superconvert/smart_rtmpd)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/superconvert-smart-rtmpd