openclaw/memory/srs-overview.md
SRS is a simple, high-efficiency, real-time media server. It receives streams from publishers and delivers them to players.
┌─────────────────────────────────────────────────────────────────┐
│ PUBLISHERS │
│ FFmpeg, OBS, Larix, vMix, hardware encoders, browsers, apps │
└─────────────────────────────┬───────────────────────────────────┘
│
▼
┌───────────┐
│ SRS │
└───────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ PLAYERS │
│ FFmpeg, VLC, ffplay, ExoPlayer, IJKPlayer, browsers, hardware, │
│ apps │
└─────────────────────────────────────────────────────────────────┘
Publishers:
Players:
Tools:
SRS converts directly between protocols.
rtc_to_rtmp on in vhost config. Transcodes Opus to AAC audio.rtmp_to_rtc on in vhost config. Transcodes AAC to Opus audio.srt_to_rtmp on in vhost config. SRT uses MPEG-TS, demuxed to RTMP.rtmp_to_rtsp on in vhost config. TCP transport only.Video Codecs:
Audio Codecs:
Only AAC, MP3, and Opus are supported (v7.0.102+). Other audio codecs are rejected.
Codec Transcoding (Built-in):
rtmp_to_rtc on).rtc_to_rtmp on).Audio transcoding uses FFmpeg's libavcodec API (linked as a library), not an external FFmpeg process. No built-in video transcoding — SRS transmuxes video without re-encoding. Use external FFmpeg for video transcoding.
RTSP Output Codec Limitation: SRS RTSP output (rtmp_to_rtsp on) only supports H.264 + AAC, even though the RTSP protocol itself supports many more codecs. This is an SRS implementation limitation, not a protocol limitation.
Which underlying transport (TCP or UDP) each protocol uses in SRS:
The simplest way to use SRS: publish an RTMP stream and play it.
Step 1: Build and run SRS.
cd srs/trunk
./configure && make
./objs/srs -c conf/console.conf
Default config conf/console.conf listens on RTMP port 1935, HTTP API port 1985, HTTP server port 8080. HLS and HTTP-FLV are enabled by default.
Step 2: Publish RTMP. Use FFmpeg to push a stream (a test file doc/source.flv is included in the repo).
ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
Step 3: Play.
rtmp://localhost/live/livestreamAbout the features supported by SRS.
Protocols — The streaming protocols supported by SRS.
Transmuxing — SRS supports transmuxing between different protocols.
Live Source — If a packet enters the live source, it can be delivered by RTMP, HLS, HTTP-FLV, and HTTP-TS protocols. Other features like DVR and transcode can also be enabled.
SRT Source — For SRT source, the input and output are SRT packets.
RTC Source — For RTC source, the input is WHIP and the output is WHEP.
SRT to Live Source — SRS supports converting SRT source to live source.
RTC to Live Source — SRS supports converting RTC source to live source.
Live to RTC Source — SRS supports converting live source to RTC source.
By default, transmuxing between sources is disabled. You need to enable it in the config.
Clustering:
Maintenance:
Others:
SRS was created as a personal open source project. As a software engineer, William has benefited from countless open source projects — large and small — and has always appreciated the contributions of the open source community. Creating and maintaining SRS for over a decade is his way of giving back. The history is simple: it's open source culture.
SRS is a niche open source project — a media server with ~150,000 lines of code. Media servers are not used by everyone, so the user base will never be massive. This makes monetization impractical and undesirable.
But small doesn't mean worthless. Even a small, niche open source project provides real value to the developers who use it and to the broader open source community and culture. The core vision of SRS is to remain a pure open source project, with no commercial or business approach. Attempting to monetize a niche open source project would kill its community — especially when the community is small, the project needs to stay driven by volunteers and genuine contribution.
The challenge with this model has always been manpower. Volunteer-driven projects struggle to maintain consistent development and support. But AI changes this equation. AI can serve as an open source project maintainer — handling code, community support, and project health at a scale that wasn't possible before. This is the approach SRS is actively pursuing.
SRS is a media server, but the project also maintains several related tools. All projects are server-side — we don't maintain client-side projects like FFmpeg or WebRTC.
SRS is a professional, C++-based media server purpose-built for the live streaming industry.
SRS is a media server focused on transmuxing — converting between protocols without changing the codec. For example, publishing RTMP with H.264 and delivering it as HTTP-FLV, HLS, MPEG-DASH, or WebRTC, all in H.264. Transmuxing means repackaging the media stream into a different protocol format, not re-encoding.
SRS implements almost all protocol code itself — RTMP, HLS, MPEG-DASH, MP4, HTTP-FLV, HTTP-TS, WebRTC. The goal is to keep as much code as possible in a single repository, which is easier to maintain — especially with AI. Depending on many third-party projects across different repositories makes maintenance harder.
Despite the goal of self-contained code, SRS does use some third-party libraries (all MIT-compatible licenses):
The long-term goal is to rewrite as many dependencies as possible into SRS itself, using AI. Protocols like SRT and server libraries like state-threads are candidates for rewriting. Crypto libraries (OpenSSL, libsrtp) and codec libraries are not planned for rewriting — they are too specialized and security-sensitive. Having all code in a single repository makes it more stable and easier for AI to maintain.
SRS has an open source community, but it is not a highly active one. There are several reasons for this.
Most maintainers are based in China — William worked in China for about 15–17 years, so most contributors are friends and colleagues from that time. After moving to Canada, he expanded connections with developers worldwide, especially in North America, but the community remains small.
The media server space is a niche industry. Not many developers need a media server — unlike client-side tools like FFmpeg or WebRTC that everyone uses, media servers serve a smaller audience. And when commercial media services exist, even fewer people build their own. This limits the size of any open source media server community, not just SRS.
SRS has been developed for over 13 years and has accumulated many useful features. But there is still a lot of work to do — many features to add, bugs to fix, and improvements to make. The project is maintained by volunteers with limited time, and development is not rapid.
AI as Maintainer — William is actively working on introducing AI as a project maintainer — not just for bug fixes or code generation, but as a full maintainer like himself. The approach is to build a comprehensive knowledge base so that AI can understand the project deeply: the architecture, design decisions, history, and community context. The goal is to have an AI maintainer within roughly six months (mid-2026). This is an experiment in using AI to maintain complex software projects — not just small ones, but projects like media servers written in C++ where you can't simply let AI generate code and push it to production. For any complex backend server or service, you need confidence that AI truly understands what it's doing before trusting it with real changes. The approach SRS is developing — building a deep knowledge base so AI can act as a real maintainer — applies broadly to any project where correctness and reliability matter.
How to Participate:
SRS is a high-performance C++ media server. Performance varies by protocol:
In general, UDP-based protocols (WebRTC, SRT) have lower performance than TCP-based protocols (RTMP, HTTP-FLV). SRS focuses on being a dedicated media server — it's not overly complicated, and performance is refined and improved with each version.
SRS uses both config files and environment variables to configure features.
Config files are in the conf/ folder. Key files:
SRS also supports configuration via environment variables. This is especially useful for Docker and cloud-native deployments — you can set environment variables in YAML files or other platforms without needing a separate config file. It's convenient to copy and paste, making documentation clearer. In the SRS docs, environment variables are often used to show how to run SRS with different configurations.