R3944Realms/srs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

OpenClaw: Improve srs-support skill with evals, latency corrections, and knowledge base refinements (#4651)

Browse Source 
Rewrite srs-support SKILL.md with selective knowledge loading and structured
answering-by-topic sections. Add 15 eval test cases covering protocols, codecs,
scaling, comparisons, deployment, and access control.                       
                          
Correct latency numbers in srs-overview.md: HLS is 10-30s in practice (not  
3-5s), add concrete ranges for SRT (~500ms-1s), WebRTC (~50-400ms), and     
HTTP-FLV (~1-3s). Add VLC player-side buffering warnings throughout.        
                          
Expand knowledge base entries: Security section now covers referer, IP      
allow/deny, and HTTP callback auth (no built-in user management). HTTP Callback
corrected to v0.9. Edge Cluster clarified as viewer scaling with new version
planned. Windows section explains the ST + SRT C++ exception handling blocker. 
                          
Add SRS Community Bot section to MEMORY.md with Telegram/Discord links.     
Update AGENTS.md to answer SRS support questions directly when mentioned. 

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Winlin 2026-03-21 15:28:31 -04:00 committed by GitHub
parent 024342910d
commit aa3da620dc
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
5 changed files with 691 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
openclaw/.gitignore vendored
View File

@ -1 +1,3 @@
.openclaw/workspace-state.json
/.openclaw/workspace-state.json
/.clawhub
/skills/llm-switcher

30
openclaw/memory/srs-overview.md
View File

@ -37,7 +37,7 @@ SRS is a **simple, high-efficiency, real-time media server**. It receives stream
**Players:**
- **VLC** — Cross-platform media player. Plays RTMP, SRT, HLS, HTTP-FLV, RTSP.
- **VLC** — Cross-platform media player. Plays RTMP, SRT, HLS, HTTP-FLV, RTSP. However, VLC often adds significant player-side buffering, so it is not a reliable reference for evaluating low-latency playback.
- **FFmpeg** — Command-line tool. Plays RTMP, SRT, HLS, HTTP-FLV (all protocols except WHEP).
- **ffplay** — FFmpeg's built-in player. Same protocol support as FFmpeg (all except WHEP).
- **ExoPlayer** — Android media player library. Plays HLS, DASH.
@ -62,26 +62,30 @@ SRS is a **simple, high-efficiency, real-time media server**. It receives stream
## Protocols (Each Supports Input AND Output)
- **RTMP** — Publishers: OBS, FFmpeg, Larix. Players: VLC, ffplay. Traditional live streaming.
- **SRT** — Publishers: OBS, vMix, hardware. Players: ffplay, VLC, hardware. Long-distance, professional broadcast.
- **WebRTC** — Publishers: Browsers, apps. Players: Browsers, apps. Real-time communication, conferences.
- **HLS/HTTP-FLV** — Players only: ExoPlayer, mpegts.js, browsers. Wide compatibility playback.
- **SRT** — Publishers: OBS, vMix, hardware. Players: ffplay, VLC, hardware. Long-distance, professional broadcast. In practice, SRT latency is often about 500ms to 1s, so it is in the low-latency / real-time class.
- **WebRTC** — Publishers: Browsers, apps. Players: Browsers, apps. Real-time communication, conferences. In practice, WebRTC latency is often about 50ms to 400ms, making it the lowest-latency protocol in SRS.
- **HLS/HTTP-FLV** — Players only: ExoPlayer, mpegts.js, browsers. Wide compatibility playback. HTTP-FLV is low latency, often about 1 to 3 seconds. HLS is the de facto standard for delivery, but latency is much higher: typically about 10 to 30 seconds. With aggressive tuning of playlist/segment settings and player buffering, HLS can sometimes be reduced to about 5 to 10 seconds, but it is still not a true low-latency protocol in normal practice.
- **RTSP** — Players only: VLC, FFmpeg, ffplay. Surveillance, IP cameras.
## Protocol Transmux (Converting Between Protocols)
SRS converts directly between protocols.
**Latency evaluation note:** End-to-end latency depends not only on SRS and the protocol, but also on the player. Some players, especially VLC, often add significant client-side buffering. Because of that, VLC is not a reliable reference when evaluating low-latency playback.
- **WebRTC to RTMP** — `rtc_to_rtmp on` in vhost config. Transcodes Opus to AAC audio.
- **RTMP to WebRTC** — `rtmp_to_rtc on` in vhost config. Transcodes AAC to Opus audio.
- **SRT to RTMP** — `srt_to_rtmp on` in vhost config. SRT uses MPEG-TS, demuxed to RTMP.
- **SRT to WebRTC** — Converts directly. Transcodes AAC to Opus audio.
- **GB28181 to RTMP** — For surveillance cameras pushing PS streams. Depends on external [srs-sip](https://github.com/ossrs/srs-sip) for SIP signaling.
- **RTMP to HLS** — Segments into .m3u8 + .ts files. 3–5s latency.
- **RTMP to HLS** — Segments into `.m3u8` + `.ts` files. In normal deployments, latency is typically about 10 to 30 seconds. With aggressive tuning of segment duration, playlist window, and player buffering, it can sometimes be reduced to about 5 to 10 seconds.
- **RTMP to HTTP-FLV** — Transmux to FLV over HTTP. ~1s latency.
- **RTMP to HTTP-TS** — Transmux to MPEG-TS over HTTP.
- **RTMP to RTSP** — `rtmp_to_rtsp on` in vhost config. TCP transport only.
- **RTMP to MPEG-DASH** — Segments into DASH manifest + segments.
For live streaming, HLS is the de facto standard for delivery, but it has the highest latency. In normal practice, HLS is typically about 10 to 30 seconds. With aggressive tuning of segment duration, playlist size, and player buffering, it can sometimes be reduced to about 5 to 10 seconds. HTTP-FLV and RTMP are low-latency protocols, typically about 1 to 3 seconds. SRT and WebRTC are also low-latency / real-time protocols. Among them, WebRTC usually has the lowest latency, while SRT is often around 500ms to 1s. When evaluating latency, avoid using VLC as the reference player because its client-side buffering can dominate the observed delay.
## Codecs
**Video Codecs:**
@ -146,7 +150,7 @@ ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
Step 3: Play.
- **RTMP** (VLC): `rtmp://localhost/live/livestream`
- **RTMP** (VLC): `rtmp://localhost/live/livestream` Note: VLC may add large playback latency because of player-side buffering, so it is not suitable for evaluating low-latency performance.
- **HTTP-FLV** (browser): [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.flv)
- **HLS** (browser): [http://localhost:8080/live/livestream.m3u8](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.m3u8)
- **WebRTC** (browser): [http://localhost:1985/rtc/v1/whep/?app=live&stream=livestream](http://localhost:8080/players/whep.html?autostart=true)
@ -182,7 +186,7 @@ By default, transmuxing between sources is disabled. You need to enable it in th
**Clustering:**
- **Origin Cluster** — Used to extend the number of streams SRS can support. It is a cluster of multiple origin servers behind a proxy server. The proxy discovers which origin server a stream is on and routes to it. v3.0, 2018-02
- **Edge Cluster** — The edge cluster of SRS is deprecated because it only supports the RTMP protocol. v1.0, 2014-04
- **Edge Cluster** — Used to extend the number of viewers a stream can support. The current edge cluster is deprecated because it only supports the RTMP protocol, but a new edge cluster is planned to support more protocols. v1.0, 2014-04
- **HLS Cluster** — Built by Nginx. It is a type of edge cluster for HLS. v5.0, 2022-04
**Maintenance:**
@ -190,15 +194,15 @@ By default, transmuxing between sources is disabled. You need to enable it in th
- **HTTP API** — You can query the system status like streams and stream details. You can also use the HTTP API to kick off streams and manage streams. v1.0, 2014-04
- **Log** — SRS provides traceable log. Traceable log means you can trace a stream from edge to origin, from one server to another, from source to consumer. v1.0, 2014-05
- **Prometheus Exporter** — SRS supports a Prometheus exporter. You can export the status of SRS to Prometheus, allowing you to pull the statistics of SRS into Prometheus. It is a very convenient and powerful feature. v5.0, 2022-09
- **HTTP Callback** — Allows you to listen and handle events, for example publish or play events. You can authenticate clients and reject publishers if you want. v2.0, 2014-02
- **HTTP Callback** — Allows you to listen and handle events, for example publish or play events. You can authenticate clients and reject publishers if you want. Since v0.9, 2013-12
**Others:**
- **Ingest** — A feature that uses FFmpeg to pull streams into SRS. v1.0, 2014-04
- **Forward** — SRS can forward streams to other servers. You can also use FFmpeg to forward streams from SRS to other servers. v1.0, 2013
- **Transcode** — SRS uses FFmpeg to transcode streams, especially video and audio to different codecs and sizes. v1.0, 2014-04
- **DVR** — SRS supports recording streams to files. You can use these files as VOD (Video on Demand). You can also use FFmpeg to pull streams from SRS and DVR to file. Besides this, HLS is in fact also a DVR feature. v1.0, 2014-04
- **Security** — SRS supports IP allow list and deny list. You can also use HTTP callback as a security feature for authentication and verification. v2.0, 2015-01
- **DVR** — SRS supports recording streams to files. You can use these files as VOD (Video on Demand). You can also use FFmpeg to pull streams from SRS and DVR to file. Besides this, HLS is in fact also a DVR feature. Since v1.0, 2014-04
- **Security** — SRS supports multiple access-control mechanisms: referer-based hotlink protection (`refer`), IP allow/deny rules (`security`), and HTTP callback for external authentication and verification. SRS does not provide a built-in username/password user management system; authentication is typically implemented by external logic such as HTTP callback or tokens. IP allow/deny rules were added in v2.0, 2015-01
## Vision
@ -263,7 +267,7 @@ SRS has been developed for over 13 years and has accumulated many useful feature
- **Edge Cluster** — SRS supports origin cluster, but the edge cluster only supports RTMP. More protocols need to be supported in the edge cluster.
- **Single-Threaded** — SRS is a single-threaded media server. There are no plans to support multi-threading — you can build a cluster to saturate all CPUs instead.
- **Linux Only** — SRS is designed for Linux and does not support Windows natively. However, you can use WSL (Windows Subsystem for Linux) on Windows.
- **Linux Only** — SRS currently targets Linux and does not support Windows natively. Windows users can run SRS through WSL (Windows Subsystem for Linux). Historically, SRS v5 supported Windows, but SRS v6 removed native Windows support. The key blocker was not Windows itself, but that SRS uses the ST coroutine model, which does not properly support Windows C++ exception handling. This became a severe problem because SRT relies on C++ exceptions, so SRT could not work reliably together with ST on Windows. In other words, this was a real technical blocker, not a product-positioning choice. In the future, AI may help solve this problem — for example by improving exception support in ST or by rewriting SRT-related code to avoid this dependency — so Windows support may become possible again.
- **No Commercial Support** — As a pure open source project, there is no commercial support team. We are exploring how to use AI to maintain the project and support the community.
## Performance
@ -271,8 +275,8 @@ SRS has been developed for over 13 years and has accumulated many useful feature
SRS is a high-performance C++ media server. Performance varies by protocol:
- **RTMP / HTTP-FLV** — Supports thousands of concurrent publishers and players. TCP-based protocols have the best performance.
- **WebRTC** — Supports hundreds of publishers and players. With audio transcoding (e.g., AAC↔Opus), only dozens of connections. UDP-based, so lower throughput than TCP protocols.
- **SRT** — Performance is determined by [libsrt](https://github.com/Haivision/srt). Supports several hundred connections. Also UDP-based.
- **WebRTC** — Supports hundreds of publishers and players. With audio transcoding (e.g., AAC↔Opus), only dozens of connections. UDP-based, so lower throughput than TCP protocols. Typical latency is about 50ms to 400ms.
- **SRT** — Performance is determined by [libsrt](https://github.com/Haivision/srt). Supports several hundred connections. Also UDP-based. Typical latency is about 500ms to 1s.
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.

1
openclaw/skills/srs-support/.gitignore vendored Normal file
View File

@ -0,0 +1 @@
*workspace

83
openclaw/skills/srs-support/SKILL.md
View File

@ -1,49 +1,86 @@
---
name: srs-support
description: Answer SRS (Simple Realtime Server) questions for developers and users — protocols, configuration, architecture, codecs, ecosystem tools, deployment, and troubleshooting. Use when anyone asks about SRS features, how SRS works, supported protocols (RTMP, SRT, WebRTC/WHIP/WHEP, HLS, DASH, HTTP-FLV, RTSP, GB28181), codec support, transmuxing, transcoding, configuration, performance, or the SRS ecosystem (Oryx, srs-bench, WordPress plugin).
description: Answer SRS (Simple Realtime Server) questions for developers and users — protocols, configuration, architecture, codecs, ecosystem tools, deployment, and troubleshooting. Use when anyone asks about SRS features, how SRS works, supported protocols (RTMP, SRT, WebRTC/WHIP/WHEP, HLS, DASH, HTTP-FLV, RTSP, GB28181), codec support, transmuxing, transcoding, configuration, performance, or the SRS ecosystem (srs-bench, state-threads). Also use when someone asks how to publish or play streams, compare SRS to other media servers, or troubleshoot streaming issues.
---
# SRS Support
Answer questions about SRS using the knowledge base in the SRS repository.
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
The user must have the SRS repository cloned locally. The knowledge files live in the `openclaw/` directory inside the SRS repo.
Do **not** hardcode an absolute SRS path. Resolve `SRS_ROOT` dynamically:
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 as `SRS_ROOT`.
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 (or to clone it).
4. Else, ask the user for their SRS repo root.
All paths below are relative to `$SRS_ROOT`.
## Loading Knowledge
On first question, load **all** `srs-*.md` files from `openclaw/memory/` into context:
Load knowledge selectively based on the question topic:
```bash
ls "$SRS_ROOT"/openclaw/memory/srs-*.md
```
- **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.
Read every file found. Do not selectively load or search — load the entire knowledge base. Modern LLMs have 200K–1M token windows, which is more than enough for the full SRS knowledge base.
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.
## Knowledge Files
## Answering by Topic
All files are in `$SRS_ROOT/openclaw/memory/`:
### 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)
- **srs-overview.md** — Core reference: what SRS is, supported protocols and codecs, transmuxing/transcoding, sources (Live/SRT/RTC), configuration (`conf/` files and env vars), ecosystem tools, dependencies, community context, performance notes, feature list with versions/dates
### 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
More `srs-*.md` files will be added over time as the knowledge base grows.
### 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
- Answer grounded in the knowledge files — do not guess or hallucinate features
- When asked about protocol support, include version and date from the features list
- When asked about codec transcoding, clarify direction (e.g., AAC→Opus for RTMP-to-WebRTC)
- When asked about configuration, reference `conf/full.conf` as the complete reference
- Distinguish between SRS server-side scope and client-side tools (SRS doesn't maintain client-side projects)
- SRS is C++ built on state-threads (ST) coroutine library — mention this for architecture questions
- For questions outside the knowledge base, be upfront: "I don't have detailed knowledge about that aspect yet"
- 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

610
openclaw/skills/srs-support/evals/evals.json Normal file
View File

@ -0,0 +1,610 @@
{
"skill_name": "srs-support",
"evals": [
{
"id": 0,
"prompt": "I'm publishing an RTMP stream with H.264+AAC. I want browser viewers to watch via WebRTC. Do I need to configure anything special, and will there be any transcoding?",
"expected_output": "Should explain rtmp_to_rtc config, AAC-to-Opus audio transcoding, H.264 video passthrough, and ideally mention performance impact and playback URL.",
"files": [],
"assertions": [
{
"name": "mentions_rtmp_to_rtc_config",
"description": "Answer mentions 'rtmp_to_rtc on' as the required configuration",
"type": "contains_concept"
},
{
"name": "aac_to_opus_transcoding",
"description": "Answer explains that AAC audio is automatically transcoded to Opus for WebRTC",
"type": "contains_concept"
},
{
"name": "h264_no_transcoding",
"description": "Answer clarifies that H.264 video passes through without transcoding (transmux only)",
"type": "contains_concept"
},
{
"name": "uses_libavcodec_not_external_ffmpeg",
"description": "Answer specifies that audio transcoding uses FFmpeg's libavcodec as a linked library, not an external FFmpeg process",
"type": "contains_concept"
},
{
"name": "performance_impact",
"description": "Answer mentions that audio transcoding reduces WebRTC capacity (dozens of connections vs hundreds for UDP protocols)",
"type": "contains_concept"
},
{
"name": "disabled_by_default",
"description": "Answer mentions that rtmp_to_rtc is disabled by default and must be explicitly enabled",
"type": "contains_concept"
},
{
"name": "whep_playback",
"description": "Answer mentions WHEP endpoint or playback URL for WebRTC viewing",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not claim SRS does video transcoding or mention features not in the knowledge base",
"type": "absence"
}
]
},
{
"id": 1,
"prompt": "I just cloned the SRS repo on my Linux box. How do I build it, push a test stream, and watch it in my browser?",
"expected_output": "Should provide build steps, run command with console.conf, FFmpeg publish command using doc/source.flv, browser playback URLs (HTTP-FLV/HLS), correct ports, and mention HTTP API or SRS console for checking streams.",
"files": [],
"assertions": [
{
"name": "build_steps",
"description": "Answer includes build steps: cd srs/trunk, ./configure, and make",
"type": "contains_concept"
},
{
"name": "run_with_console_conf",
"description": "Answer shows running SRS with console.conf (./objs/srs -c conf/console.conf)",
"type": "contains_concept"
},
{
"name": "ffmpeg_publish_with_test_file",
"description": "Answer shows FFmpeg publish command using the bundled doc/source.flv test file",
"type": "contains_concept"
},
{
"name": "rtmp_publish_url",
"description": "Answer includes RTMP publish URL like rtmp://localhost/live/livestream",
"type": "contains_concept"
},
{
"name": "browser_playback_urls",
"description": "Answer provides browser playback options: HTTP-FLV (.flv) and/or HLS (.m3u8) URLs",
"type": "contains_concept"
},
{
"name": "correct_ports",
"description": "Answer mentions correct default ports: RTMP 1935, HTTP 8080, or API 1985",
"type": "contains_concept"
},
{
"name": "api_or_console_for_checking",
"description": "Answer mentions HTTP API or SRS console for checking/monitoring streams",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not include hallucinated steps like npm install, Docker required, or incorrect commands",
"type": "absence"
}
]
},
{
"id": 2,
"prompt": "My network is unstable with frequent packet loss. Should I use SRT or RTMP to push a live stream to SRS? What's the difference?",
"expected_output": "Should recommend SRT for unstable networks, explain TCP vs UDP difference, mention srt_to_rtmp conversion, and note tool support.",
"files": [],
"assertions": [
{
"name": "recommend_srt_for_unstable_network",
"description": "Answer recommends SRT for unstable networks because it handles packet loss better than RTMP",
"type": "contains_concept"
},
{
"name": "tcp_vs_udp_transport",
"description": "Answer explains that RTMP uses TCP and SRT uses UDP",
"type": "contains_concept"
},
{
"name": "srt_version_and_libsrt",
"description": "Answer mentions SRT supported since v4.0 and/or uses libsrt",
"type": "contains_concept"
},
{
"name": "srt_to_rtmp_conversion",
"description": "Answer mentions srt_to_rtmp config for converting SRT to RTMP for downstream playback (HLS, HTTP-FLV, etc.)",
"type": "contains_concept"
},
{
"name": "tool_support",
"description": "Answer mentions that common tools like OBS and FFmpeg support both SRT and RTMP",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate features not in the knowledge base",
"type": "absence"
}
]
},
{
"id": 3,
"prompt": "Does SRS support H.265? Which protocols can I use with HEVC streams?",
"expected_output": "Should list H.265 support since v6.0, enumerate supported protocols, mention WebRTC HEVC in v7.0, and clarify no video transcoding.",
"files": [],
"assertions": [
{
"name": "hevc_since_v6",
"description": "Answer mentions H.265/HEVC supported since v6.0 via Enhanced RTMP",
"type": "contains_concept"
},
{
"name": "supported_protocols",
"description": "Answer lists protocols that support HEVC: RTMP, HTTP-FLV, HTTP-TS, HLS, MPEG-DASH, SRT, GB28181, DVR",
"type": "contains_concept"
},
{
"name": "hls_fmp4_v7",
"description": "Answer mentions HLS fMP4/LLHLS support for HEVC in v7.0",
"type": "contains_concept"
},
{
"name": "webrtc_hevc_v7",
"description": "Answer mentions WebRTC HEVC supported in v7.0 with Safari and/or Chrome 136+ playback",
"type": "contains_concept"
},
{
"name": "no_video_transcoding",
"description": "Answer clarifies that SRS transmuxes H.265 video without re-encoding (no built-in video transcoding)",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate unsupported HEVC features or incorrect protocol support",
"type": "absence"
}
]
},
{
"id": 4,
"prompt": "I need to serve 10,000 RTMP viewers. SRS is single-threaded — how do I scale it?",
"expected_output": "Should explain edge cluster for scaling viewers (deprecated, RTMP only), distinguish from origin cluster (for more streams), mention single-threaded design, and HLS cluster option.",
"files": [],
"assertions": [
{
"name": "single_threaded_design",
"description": "Answer explains SRS is single-threaded by design with no multi-threading support",
"type": "contains_concept"
},
{
"name": "edge_cluster_for_viewers",
"description": "Answer mentions edge cluster as the solution for scaling viewers",
"type": "contains_concept"
},
{
"name": "edge_cluster_deprecated_new_planned",
"description": "Answer notes that edge cluster is currently deprecated (only supports RTMP), but a new version is planned",
"type": "contains_concept"
},
{
"name": "origin_cluster_distinction",
"description": "Answer distinguishes origin cluster as being for extending the number of streams, not for scaling viewers",
"type": "contains_concept"
},
{
"name": "tcp_performance",
"description": "Answer mentions that TCP protocols (RTMP, HTTP-FLV) support thousands of connections per instance",
"type": "contains_concept"
},
{
"name": "hls_cluster_option",
"description": "Answer mentions HLS cluster (built with Nginx) as an alternative for HLS viewers, since v5.0",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate multi-threading config or incorrect clustering features",
"type": "absence"
}
]
},
{
"id": 5,
"prompt": "I'm choosing between SRS and Nginx-RTMP for a live streaming project. We need RTMP ingest and multiple playback options. Which one should I pick?",
"expected_output": "Should compare protocol coverage, maintenance status, Enhanced RTMP support, and be objective about both.",
"files": [],
"assertions": [
{
"name": "nginx_rtmp_protocol_limits",
"description": "Answer mentions Nginx-RTMP supports RTMP and HLS, but not WebRTC, SRT, or HTTP-FLV",
"type": "contains_concept"
},
{
"name": "srs_protocol_coverage",
"description": "Answer mentions SRS supports RTMP, HLS, HTTP-FLV, WebRTC, SRT, MPEG-DASH, and more",
"type": "contains_concept"
},
{
"name": "both_support_rtmp_ingest",
"description": "Answer notes both support RTMP ingest from OBS/FFmpeg",
"type": "contains_concept"
},
{
"name": "enhanced_rtmp",
"description": "Answer mentions SRS supports Enhanced RTMP (e.g., HEVC over RTMP) and keeps up with RTMP protocol evolution",
"type": "contains_concept"
},
{
"name": "maintenance_status",
"description": "Answer mentions SRS is actively maintained (community and AI-assisted) while Nginx-RTMP has not been maintained for about a decade",
"type": "contains_concept"
},
{
"name": "objective_comparison",
"description": "Answer is objective and acknowledges Nginx-RTMP strengths (e.g., Nginx ecosystem integration)",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate features about either server",
"type": "absence"
}
]
},
{
"id": 6,
"prompt": "I have IP cameras that push GB28181 streams. Can SRS receive them? What do I need besides SRS?",
"expected_output": "Should explain GB28181 support, external srs-sip requirement, downstream delivery options, and v5 vs v6 differences.",
"files": [],
"assertions": [
{
"name": "gb28181_publishing_support",
"description": "Answer confirms SRS supports receiving/publishing GB28181 streams",
"type": "contains_concept"
},
{
"name": "ps_over_tcp",
"description": "Answer mentions GB28181 uses PS (Program Stream) over TCP",
"type": "contains_concept"
},
{
"name": "external_srs_sip_required",
"description": "Answer mentions SRS requires an external SIP server (srs-sip) for SIP signaling in v6+",
"type": "contains_concept"
},
{
"name": "downstream_delivery",
"description": "Answer mentions GB28181 streams can be converted to RTMP for downstream delivery (HLS, HTTP-FLV, WebRTC, etc.)",
"type": "contains_concept"
},
{
"name": "v5_vs_v6_rewrite",
"description": "Answer mentions GB28181 supported since v5.0 but completely rewritten in v6 — v5 had an embedded SIP server, v6 removed it and requires external srs-sip",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate features like a built-in SIP server in v6+",
"type": "absence"
}
]
},
{
"id": 7,
"prompt": "I keep hearing \"transmuxing\" and \"transcoding\" — what's the difference? Which one does SRS do?",
"expected_output": "Should explain transmuxing vs transcoding, SRS focus on transmuxing, built-in audio-only transcoding, and external FFmpeg for video transcoding.",
"files": [],
"assertions": [
{
"name": "transmuxing_definition",
"description": "Answer explains transmuxing = repackaging media into a different protocol format without re-encoding",
"type": "contains_concept"
},
{
"name": "transcoding_definition",
"description": "Answer explains transcoding = re-encoding media to a different codec",
"type": "contains_concept"
},
{
"name": "srs_focuses_on_transmuxing",
"description": "Answer states SRS focuses on transmuxing, not transcoding",
"type": "contains_concept"
},
{
"name": "builtin_audio_transcoding_only",
"description": "Answer mentions SRS has built-in audio transcoding only (AAC↔Opus) for WebRTC interop",
"type": "contains_concept"
},
{
"name": "no_builtin_video_transcoding",
"description": "Answer clarifies no built-in video transcoding — use external FFmpeg for that",
"type": "contains_concept"
},
{
"name": "external_ffmpeg_transcoding",
"description": "Answer mentions SRS has an external transcoding feature that uses FFmpeg",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate transcoding features",
"type": "absence"
}
]
},
{
"id": 8,
"prompt": "I'm on Windows 10. Can I install and run SRS directly?",
"expected_output": "Should explain Linux-only, v5 Windows history, WSL/Docker workarounds, and future possibility.",
"files": [],
"assertions": [
{
"name": "currently_linux_only",
"description": "Answer states SRS is currently Linux-only and does not run natively on Windows",
"type": "contains_concept"
},
{
"name": "v5_windows_history",
"description": "Answer mentions SRS v5 had Windows support but it was removed in v6 because AI couldn't maintain it",
"type": "contains_concept"
},
{
"name": "future_windows_possible",
"description": "Answer mentions Windows support may return in the future if AI becomes powerful enough to maintain it",
"type": "contains_concept"
},
{
"name": "wsl_workaround",
"description": "Answer suggests using WSL (Windows Subsystem for Linux) to run SRS on Windows",
"type": "contains_concept"
},
{
"name": "macos_for_dev",
"description": "Answer mentions macOS works for development but Linux is the target platform",
"type": "contains_concept"
},
{
"name": "docker_option",
"description": "Answer mentions Docker as another option for running SRS on non-Linux systems",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate a Windows installer or native Windows build",
"type": "absence"
}
]
},
{
"id": 9,
"prompt": "I'm streaming a live event and want to save a recording. Can SRS record streams to files?",
"expected_output": "Should explain DVR feature, VOD use, HLS as recording with on_hls callback, and external FFmpeg option.",
"files": [],
"assertions": [
{
"name": "dvr_support",
"description": "Answer mentions SRS supports DVR — recording streams to files",
"type": "contains_concept"
},
{
"name": "vod_use",
"description": "Answer mentions recorded files can be used as VOD (Video on Demand)",
"type": "contains_concept"
},
{
"name": "dvr_since_v1",
"description": "Answer mentions DVR supported since v1.0",
"type": "contains_concept"
},
{
"name": "hls_as_recording",
"description": "Answer mentions HLS can be used as a form of recording (segments to .ts files) with on_hls callback to notify your system to manage the files",
"type": "contains_concept"
},
{
"name": "external_ffmpeg_recording",
"description": "Answer mentions using FFmpeg to pull streams from SRS and record externally",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate recording features",
"type": "absence"
}
]
},
{
"id": 10,
"prompt": "I want the lowest possible latency for my viewers. What protocol should I use in SRS? What's the latency difference between HLS and WebRTC?",
"expected_output": "Should compare latency across protocols, warn about player-side latency trap, and mention SRT as low-latency option.",
"files": [],
"assertions": [
{
"name": "webrtc_lowest_latency",
"description": "Answer states WebRTC has the lowest latency — sub-second, real-time",
"type": "contains_concept"
},
{
"name": "srt_low_latency",
"description": "Answer mentions SRT also offers low latency — around 500ms to 1s, widely used in live streaming",
"type": "contains_concept"
},
{
"name": "http_flv_latency",
"description": "Answer mentions HTTP-FLV has around 1 second latency",
"type": "contains_concept"
},
{
"name": "hls_latency",
"description": "Answer mentions HLS has 3–5 seconds latency due to segmenting",
"type": "contains_concept"
},
{
"name": "player_side_latency_trap",
"description": "Answer warns that latency is an end-to-end problem and the player matters — VLC adds huge latency even with low-latency protocols, use browsers with WebRTC for true low latency",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate latency numbers or claim sub-second HLS",
"type": "absence"
}
]
},
{
"id": 11,
"prompt": "I want to live stream from my iPhone to SRS. What app should I use and what protocol?",
"expected_output": "Should recommend Larix Broadcaster, mention browser WHIP option, and suggest protocols.",
"files": [],
"assertions": [
{
"name": "larix_broadcaster",
"description": "Answer recommends Larix Broadcaster as a mobile streaming app for iOS/Android supporting RTMP, SRT, WHIP",
"type": "contains_concept"
},
{
"name": "browser_whip_option",
"description": "Answer mentions publishing via browser using WHIP (WebRTC) as an option",
"type": "contains_concept"
},
{
"name": "rtmp_simplest",
"description": "Answer mentions RTMP as the simplest protocol option for mobile publishing",
"type": "contains_concept"
},
{
"name": "srt_for_unstable",
"description": "Answer mentions SRT as a good option if the network is unstable",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate an SRS mobile app or claim OBS works on phones",
"type": "absence"
}
]
},
{
"id": 12,
"prompt": "I don't want everyone to watch my stream. How do I control who can publish or play in SRS?",
"expected_output": "Should explain HTTP callback auth, IP allow/deny lists, HTTP API for kicking streams, and no built-in user management.",
"files": [],
"assertions": [
{
"name": "http_callback_auth",
"description": "Answer mentions HTTP callback for authentication — listen to publish/play events and accept or reject clients",
"type": "contains_concept"
},
{
"name": "ip_allow_deny_list",
"description": "Answer mentions IP allow list and deny list for basic security",
"type": "contains_concept"
},
{
"name": "http_callback_since_v2",
"description": "Answer mentions HTTP callback supported since v2.0",
"type": "contains_concept"
},
{
"name": "http_api_kickoff",
"description": "Answer mentions HTTP API can be used to kick off/stop streams or disconnect publishers/viewers",
"type": "contains_concept"
},
{
"name": "no_builtin_user_management",
"description": "Answer clarifies no built-in username/password system — use HTTP callback to integrate with your own auth service",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate built-in user management features",
"type": "absence"
}
]
},
{
"id": 13,
"prompt": "I want to try SRS quickly without building from source. Can I run it in Docker?",
"expected_output": "Should explain Docker support, docker.conf, environment variables, ports to expose including UDP, and same publish/play workflow.",
"files": [],
"assertions": [
{
"name": "docker_supported",
"description": "Answer confirms SRS supports Docker deployment",
"type": "contains_concept"
},
{
"name": "docker_conf",
"description": "Answer mentions using conf/docker.conf for Docker configuration (e.g., no daemon mode)",
"type": "contains_concept"
},
{
"name": "env_variables",
"description": "Answer mentions SRS supports environment variables for configuration — useful for Docker/cloud-native deployments",
"type": "contains_concept"
},
{
"name": "ports_to_expose",
"description": "Answer mentions ports to expose: RTMP 1935, HTTP 8080, API 1985, and UDP ports for SRT and WebRTC",
"type": "contains_concept"
},
{
"name": "same_publish_play",
"description": "Answer mentions you can publish and play the same way as a native build",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate incorrect Docker image names or commands",
"type": "absence"
}
]
},
{
"id": 14,
"prompt": "I see SRS supports WebRTC. Can I use it to build a video conferencing app like Zoom?",
"expected_output": "Should explain SRS can work for small-scale conferencing but the main challenge is the application layer, not the SFU.",
"files": [],
"assertions": [
{
"name": "small_scale_possible",
"description": "Answer explains SRS can work for very small-scale conferencing (1-to-1, 2-3 participants) via browser or smartphone",
"type": "contains_concept"
},
{
"name": "sfu_stream_count",
"description": "Answer explains SRS is an SFU — for 3 participants that means 9 streams to forward",
"type": "contains_concept"
},
{
"name": "application_layer_is_main_challenge",
"description": "Answer explains the biggest challenge for conferencing is not the SFU but the application layer: chat, hand-raising, recording (needs transcoding), SIP integration, etc.",
"type": "contains_concept"
},
{
"name": "no_turn_no_p2p",
"description": "Answer mentions SRS does not support TURN or P2P",
"type": "contains_concept"
},
{
"name": "not_for_large_scale",
"description": "Answer clarifies SRS is not the right fit for large-scale conferencing",
"type": "contains_concept"
},
{
"name": "no_hallucination",
"description": "Answer does not hallucinate built-in room management, MCU, or conferencing features",
"type": "absence"
}
]
}
]
}