srs-support
Answer SRS (Simple Realtime Server) questions for developers and users — protocols, configuration, architecture.
Setup & Installation
Install command
clawhub install winlinvip/srs-supportIf the CLI is not installed:
Install command
npx clawhub@latest install winlinvip/srs-supportOr install with OpenClaw CLI:
Install command
openclaw skills install winlinvip/srs-supportor paste the repo link into your assistant's chat
Install command
https://github.com/openclaw/skills/tree/main/skills/winlinvip/srs-supportWhat This Skill Does
Answers questions about SRS (Simple Realtime Server), a C++ media server for real-time streaming. Covers protocols (RTMP, SRT, WebRTC/WHIP/WHEP, HLS, DASH, HTTP-FLV, RTSP, GB28181), codec compatibility, configuration, deployment, and troubleshooting. Answers are grounded in the SRS project knowledge base, not general streaming knowledge.
Answers are sourced directly from the SRS project's own documentation files, so you get accurate, version-specific details rather than generic streaming advice.
When to Use It
- Checking which protocols SRS supports for publish vs playback
- Troubleshooting RTMP or WebRTC stream failures on a live deployment
- Comparing SRS to Nginx-RTMP or Janus before choosing a media server
- Finding the right vhost config options for a Docker-based SRS setup
- Understanding codec compatibility when bridging RTMP and WebRTC streams
View original SKILL.md file
# SRS Support
Help users deploy, configure, operate, monitor, and troubleshoot SRS — a simple, high-efficiency, real-time media server.
This skill is for **operators, users, and DevOps** — answering questions about using SRS, not changing its code.
**Scope:**
- Deployment, configuration, and getting started
- Operating and maintaining SRS in production
- Troubleshooting streaming issues (connection failures, latency, playback problems)
- Monitoring (HTTP API, logs, Prometheus)
- General questions about protocols, codecs, features, and how SRS works at a usage level
- May read source code internally to give better answers, but the goal is always helping users *use* SRS — not explaining the code
**Out of scope:**
- Code changes, bug fixes, or feature development — outside scope of this skill
- Teaching users about SRS internals or source code — you may read source code to answer user questions better, but don't guide users into understanding the code itself. The goal is to help them *use* SRS, not develop it.
- **Oryx** — Oryx is not supported by this AI yet. If the user asks about Oryx, tell them clearly: "Oryx support is planned but not available yet." Do not attempt to answer Oryx-specific questions.
## Workflow
Follow these three steps in order for every question.
## Step 1: Setup
All files are in the current working directory. Find everything from here — no discovery logic needed.
Available directories: `trunk/`, `cmd/`, `internal/`, `cmake/`, `docs/`, `memory/`
All AI tools — OpenClaw, Codex, Claude Code, Kiro CLI — see the same relative paths.
## Step 2: Load Knowledge
Load knowledge in layers. Start minimal, expand only if needed.
**Layer 1 — Always load:**
- `memory/srs-overview.md` — covers protocols, codecs, transmuxing, configuration, features, ecosystem, performance. This answers most general questions.
**Layer 2 — Load the relevant doc file(s) based on the question topic:**
Use this mapping to decide which doc file to load. Only load what's relevant — don't load all of them.
| Topic | Doc file(s) to load |
|---|---|
| RTMP config, tuning, RTMPS | `trunk/3rdparty/srs-docs/doc/rtmp.md` |
| HLS config, latency, encryption, fMP4 | `trunk/3rdparty/srs-docs/doc/hls.md` |
| WebRTC setup, candidate, connection issues | `trunk/3rdparty/srs-docs/doc/webrtc.md` |
| HTTP-FLV, WebSocket FLV | `trunk/3rdparty/srs-docs/doc/flv.md` |
| SRT config, streamid, latency modes | `trunk/3rdparty/srs-docs/doc/srt.md` |
| RTSP playback | `trunk/3rdparty/srs-docs/doc/rtsp.md` |
| HEVC/H.265 protocol support | `trunk/3rdparty/srs-docs/doc/hevc.md` |
| DVR, recording to file | `trunk/3rdparty/srs-docs/doc/dvr.md` |
| HTTP callbacks, authentication | `trunk/3rdparty/srs-docs/doc/http-callback.md` |
| IP allow/deny, access control | `trunk/3rdparty/srs-docs/doc/security.md` |
| HTTP API, stream monitoring | `trunk/3rdparty/srs-docs/doc/http-api.md` |
| Prometheus, Grafana, metrics | `trunk/3rdparty/srs-docs/doc/exporter.md` |
| Ports, firewall, resource planning | `trunk/3rdparty/srs-docs/doc/resource.md` |
| Embedded HTTP server, reverse proxy | `trunk/3rdparty/srs-docs/doc/http-server.md` |
| Nginx for HLS/DASH distribution | `trunk/3rdparty/srs-docs/doc/nginx-for-hls.md` |
| Edge server, CDN clustering | `trunk/3rdparty/srs-docs/doc/edge.md` |
| Origin cluster, proxy server | `trunk/3rdparty/srs-docs/doc/origin-cluster.md` |
| Low latency tuning | `trunk/3rdparty/srs-docs/doc/low-latency.md` |
| Performance profiling, benchmarks | `trunk/3rdparty/srs-docs/doc/performance.md` |
| Ingest external streams | `trunk/3rdparty/srs-docs/doc/ingest.md` |
| Forward to other servers | `trunk/3rdparty/srs-docs/doc/forward.md` |
| FFmpeg transcoding | `trunk/3rdparty/srs-docs/doc/ffmpeg.md` |
| Snapshots, thumbnails | `trunk/3rdparty/srs-docs/doc/snapshot.md` |
| Getting started with Docker | `trunk/3rdparty/srs-docs/doc/getting-started.md` |
| Building from source | `trunk/3rdparty/srs-docs/doc/getting-started-build.md` |
**Layer 3 — Last resort (if you need source code to answer):**
- `memory/srs-codebase-map.md` — load the **entire file** (do not truncate or read partial content). Then: reason about which module/files are relevant to the question based on the map's descriptions, and search only those specific files. **DO NOT grep broadly** (e.g., `trunk/src/` or the repository root). The map exists so you can go directly to the right 2-3 files instead of scanning the whole tree.
## Step 3: Answer by Topic
Classify the question into one of the topics below, then apply that topic's strategy. If a question spans multiple topics, combine the relevant strategies.
**Answering rules (apply to all topics):**
- Ground every answer in the knowledge files and docs — do not guess or invent features
- When you don't have information, say so: "The knowledge base doesn't cover that yet"
- Keep answers practical — include commands, config snippets, or URLs when relevant
- Use the `trunk/doc/source.flv` test file for publish examples (it ships with the repo)
**Protocol Questions**
- State which protocols SRS supports and their role (publish, play, or both)
- Include the version and date when a protocol was added (from the Features list in srs-overview.md)
- Clarify transport: which protocols use TCP vs UDP
- For protocol comparisons, explain the tradeoffs (latency, compatibility, performance)
**Codec Questions**
- Clarify codec support per protocol — not all codecs work with all protocols
- When discussing transcoding, specify the direction (e.g., AAC->Opus for RTMP-to-WebRTC)
- Distinguish built-in transcoding (audio only: AAC<->Opus, MP3->Opus) from external FFmpeg transcoding (video)
- Note that SRS focuses on transmuxing (repackaging without re-encoding), not transcoding
**Configuration Questions**
- Reference `trunk/conf/full.conf` as the complete configuration reference
- For specific features, load the relevant doc file from Layer 2 — it contains detailed config options and examples
- Mention environment variable support for Docker/cloud-native deployments
- For getting started, recommend `trunk/conf/console.conf` for local testing
**Deployment & Getting Started**
- Provide the standard build steps: `cd trunk && ./configure && make`
- Show the basic publish/play workflow with FFmpeg and common players
- For Docker questions, reference `trunk/conf/docker.conf` and load `getting-started.md`
- Note that SRS is Linux-only (use WSL on Windows, macOS works for development)
**Architecture Questions**
- SRS is single-process, single-threaded by design — simple to deploy and operate
- Scale horizontally via origin cluster or edge servers, not by adding threads
- For internal architecture or coroutine questions, this skill doesn't cover that — tell the user it's outside the scope of usage support
**Performance Questions**
- TCP protocols (RTMP, HTTP-FLV) handle thousands of connections
- UDP protocols (WebRTC, SRT) handle hundreds; with audio transcoding, dozens
- Single-threaded — use origin cluster to scale across CPUs
**Comparison Questions**
- Compare against Nginx-RTMP, Janus, Red5 using facts from the knowledge base
- Focus on protocol coverage, language/performance, and use case fit
- Be objective — acknowledge where alternatives have strengths
**Ecosystem Questions**
- **srs-bench** — Benchmarking tool for RTMP, WebRTC, HTTP-FLV, HLS, GB28181
- **state-threads** — Coroutine library used internally by SRS (development topic, not covered by this skill)
- **Oryx** — Tell the user: "Oryx support is planned but not available yet from this AI." Do not attempt to answer Oryx-specific questions.
- SRS only maintains server-side projects — it doesn't maintain client-side tools
## Step 4: Troubleshooting
When the user reports a problem ("it's not working", "stream won't play", "high latency", etc.), follow this troubleshooting strategy.
**Gather information first — ask the user if not provided:**
- SRS version (check with HTTP API: `curl http://localhost:1985/api/v1/versions`)
- Config file being used
- How they publish (tool, protocol, command)
- How they play (tool, protocol, URL)
- Network setup: local machine, LAN, or remote/cloud? Any firewall or NAT?
- Any error messages or log output
**SRS diagnostic tools:**
- **HTTP API** — Check active streams: `curl http://localhost:1985/api/v1/streams`. Check clients: `curl http://localhost:1985/api/v1/clients`. Check server info: `curl http://localhost:1985/api/v1/summaries`. Load the `http-api.md` doc for full API reference.
- **Logs** — SRS uses traceable log with context IDs. Each connection gets a unique context ID, allowing you to trace a stream across the system. Check `trunk/objs/srs.log` or console output.
- **Prometheus** — If configured, check metrics at the exporter endpoint. Load `exporter.md` for setup.
**Common failure patterns and solutions:**
*WebRTC won't connect from remote browser:*
- Most common cause: **candidate misconfiguration**. The `candidate` in `rtc_server` must be set to the server's public IP, not `127.0.0.1` or a private IP. Load `webrtc.md` for details.
- HTTPS is required for WebRTC from non-localhost browsers. Without HTTPS, the browser blocks `getUserMedia`.
- Check that UDP port 8000 is open in the firewall. WebRTC uses UDP by default.
- Use `curl` and `nc` to verify connectivity (see "Connection Failures" section in `webrtc.md`).
*HLS latency is too high (20-30 seconds):*
- Default HLS latency is high by design (segment-based). To reduce: decrease `hls_fragment` (e.g., 2s), decrease `hls_window` (e.g., 10s), and ensure the encoder's GOP/keyframe interval matches the fragment duration.
- Player-side buffering also matters — some players buffer aggressively.
- Load `hls.md` and `low-latency.md` for config details.
- For sub-5-second latency, HLS is the wrong protocol — suggest HTTP-FLV (~1s) or WebRTC (sub-second).
*Stream plays fine in one protocol but not another:*
- Check that protocol conversion is enabled in the config. Transmuxing between sources is disabled by default. For example, `rtmp_to_rtc on` for RTMP-to-WebRTC, `srt_to_rtmp on` for SRT-to-RTMP.
- Check codec compatibility: not all codecs work with all protocols.
*VLC shows high latency even with low-latency protocols:*
- This is a **player-side issue**, not SRS. VLC adds significant client-side buffering. VLC is not a reliable reference for evaluating low-latency playback. Suggest using browsers (for WebRTC/HTTP-FLV) or ffplay instead.
*Stream not found / no playback:*
- Verify the stream is actually being published: `curl http://localhost:1985/api/v1/streams`
- Check that the stream URL matches exactly (app name + stream name)
- Publish must happen before play (except in edge mode)
*SRS behind Nginx/reverse proxy — streams don't work:*
- HTTP-FLV requires chunked transfer encoding — verify Nginx passes it through
- HLS works well behind Nginx with proxy caching
- WebRTC WHIP/WHEP needs proper proxy headers
- Load `http-server.md` for reverse proxy config examples (Nginx, Caddy)
*Connection limit reached:*
- Check `max_connections` in config (default varies by version)
- Monitor active connections via HTTP API: `curl http://localhost:1985/api/v1/summaries`
- For WebRTC, each connection uses more resources than RTMP — dozens with transcoding, hundreds without
*Ports and firewall:*
- Default ports: RTMP 1935 (TCP), HTTP API 1985 (TCP), HTTP streaming 8080 (TCP), WebRTC 8000 (UDP), SRT 10080 (UDP)
- UDP ports are often blocked by firewalls — check explicitly
- Load `resource.md` for the full port reference
Example Workflow
Here's how your AI assistant might use this skill in practice.
User asks: Checking which protocols SRS supports for publish vs playback
- 1Checking which protocols SRS supports for publish vs playback
- 2Troubleshooting RTMP or WebRTC stream failures on a live deployment
- 3Comparing SRS to Nginx-RTMP or Janus before choosing a media server
- 4Finding the right vhost config options for a Docker-based SRS setup
- 5Understanding codec compatibility when bridging RTMP and WebRTC streams
Answer SRS (Simple Realtime Server) questions for developers and users — protocols, configuration, architecture.
Security Audits
These signals reflect official OpenClaw status values. A Suspicious status means the skill should be used with extra caution.