srs-support

为开发人员和用户解答 SRS（简单实时服务器）问题 - 协议、配置、架构、编解码器、生态系统工具、部署和故障排除。当有人询问 SRS 功能、SRS 工作原理、支持的协议（RTMP、SRT、WebRTC/WHIP/WHEP、HLS、DASH、HTTP-FLV、RTSP、GB28181）、编解码器支持、转复用、转码、配置、性能或 SRS 生态系统（srs-bench、状态线程）时使用。当有人询问如何发布或播放流、如何将 SRS 与其他媒体服务器进行比较或解决流问题时也可以使用。

## 概述（中文）

为开发人员和用户解答 SRS（简单实时服务器）问题 - 协议、配置、架构、编解码器、生态系统工具、部署和故障排除。当有人询问 SRS 功能、SRS 工作原理、支持的协议（RTMP、SRT、WebRTC/WHIP/WHEP、HLS、DASH、HTTP-FLV、RTSP、GB28181）、编解码器支持、转复用、转码、配置、性能或 SRS 生态系统（srs-bench、状态线程）时使用。当有人询问如何发布或播放流、如何将 SRS 与其他媒体服务器进行比较或解决流问题时也可以使用。

## 原文

# SRS Support

Answer questions about SRS — a simple, high-efficiency, real-time media server — using the project's knowledge base.

This skill is for **answering questions and providing guidance**. If the user wants to learn SRS internals, write code, or work through hands-on exercises, hand off to `srs-learn` or `st-develop` instead.

## Setup

Resolve `SRS_ROOT` dynamically (do not hardcode paths):

1. If `SRS_ROOT` env is set and contains `openclaw/memory/srs-overview.md`, use it.
2. Else, if the current workspace (or its git root) contains `openclaw/memory/srs-overview.md`, use that.
3. Else, if `~/git/srs/openclaw/memory/srs-overview.md` exists, use `~/git/srs`.
4. Else, ask the user for their SRS repo root.

All paths below are relative to `$SRS_ROOT`.

## Loading Knowledge

Load knowledge selectively based on the question topic:

- **Always load first:** `openclaw/memory/srs-overview.md` — this covers protocols, codecs, transmuxing, configuration, features, ecosystem, performance, and most support questions.
- **Load on demand:** `openclaw/memory/srs-coroutines.md` — only load this when the question is specifically about SRS architecture internals, coroutines, State Threads, or how SRS handles concurrency. Most user questions don't need this. Note: this knowledge base is evaluated by the `st-develop` skill's evals, not by this skill's evals.

As the knowledge base grows, new `srs-*.md` files will appear. List `openclaw/memory/srs-*.md` to discover them, and load only the ones relevant to the question.

## Answering by Topic

### 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 `conf/full.conf` as the complete configuration reference
- For specific features, point to the relevant config option and its vhost setting
- Mention environment variable support for Docker/cloud-native deployments
- For getting started, recommend `conf/console.conf` for local testing

### Deployment & Getting Started
- Provide the standard build steps: `cd srs/trunk && ./configure && make`
- Show the basic publish/play workflow with FFmpeg and common players
- For Docker questions, reference `conf/docker.conf`
- Note that SRS is Linux-only (use WSL on Windows, macOS works for development)

### Architecture Questions
- SRS is C++ built on State Threads (ST) — a coroutine library providing Go-like concurrency
- Single-threaded by design — scale horizontally via clustering, not multi-threading
- Load `srs-coroutines.md` only if the user wants deeper architectural detail
- For deep-dive architecture learning, suggest using the `srs-learn` skill instead

### 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, the foundation of SRS
- **Oryx** — Mention it exists as an integrated solution but don't go into detail (out of scope for this skill)
- SRS only maintains server-side projects — it doesn't maintain client-side tools

## Answering Guidelines

- Ground every answer in the knowledge files — 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 `doc/source.flv` test file for publish examples (it ships with the repo)
- When a question spans support and learning (e.g., "how does the RTMP handshake work internally?"), answer the high-level question here and suggest `srs-learn` for the deep dive