OpenClaw: Improve SRS support skill with docs integration, troubleshooting, and workspace updates (#4655)
Enhance the srs-support skill with doc-based knowledge layers, a full troubleshooting section, and new eval cases. Update workspace config files with model auth notes, voice dictation dictionary, and gitignore patterns. srs-support skill: - Reframe skill scope: operators and users, not developers - Add Layer 2 doc file mapping (25+ topic-to-doc-file entries) so the skill loads relevant doc files instead of jumping to source code - Add Step 4 troubleshooting section covering WebRTC candidate issues, HLS latency tuning, stream-not-found diagnostics, reverse proxy problems, VLC buffering trap, and firewall port reference - Add Oryx out-of-scope policy (planned but not available yet) - Add 6 new eval cases (ids 15-20) for troubleshooting scenarios - Fix unicode arrows in evals for cross-platform compatibility Workspace updates: - TOOLS.md: Add model auth refresh instructions and git commit workflow - USER.md: Add voice dictation dictionary for speech-to-text corrections - srs-overview.md: Replace ASCII diagram with Mermaid, expand browser publisher description for mobile WHIP support - .claude/settings.local.json: Add read-only shell command permissions - .gitignore: Add workspace pattern exclusions --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Winlin
GitHub
parent
8a53cb59f1
commit
5f47cee19c
|
|
@ -1,4 +1,29 @@
|
|||
{
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Bash(find:*)",
|
||||
"Bash(ls:*)",
|
||||
"Bash(cat:*)",
|
||||
"Bash(head:*)",
|
||||
"Bash(tail:*)",
|
||||
"Bash(wc:*)",
|
||||
"Bash(grep:*)",
|
||||
"Bash(rg:*)",
|
||||
"Bash(file:*)",
|
||||
"Bash(stat:*)",
|
||||
"Bash(tree:*)",
|
||||
"Bash(du:*)",
|
||||
"Bash(diff:*)",
|
||||
"Bash(which:*)",
|
||||
"Bash(type:*)",
|
||||
"Bash(realpath:*)",
|
||||
"Bash(dirname:*)",
|
||||
"Bash(basename:*)",
|
||||
"Read",
|
||||
"Glob",
|
||||
"Grep"
|
||||
]
|
||||
},
|
||||
"hooks": {
|
||||
"SessionStart": [
|
||||
{
|
||||
|
|
|
|||
2
.gitignore
vendored
2
.gitignore
vendored
|
|
@ -47,4 +47,4 @@ srs-proxy
|
|||
|
||||
# For AI
|
||||
/*personal*
|
||||
|
||||
/*workspace*
|
||||
|
|
|
|||
1
.openclaw/.gitignore
vendored
1
.openclaw/.gitignore
vendored
|
|
@ -4,6 +4,7 @@
|
|||
/.pi
|
||||
/extensions
|
||||
/skills/llm-switcher
|
||||
/skills/*workspace*
|
||||
|
||||
# For speical folders.
|
||||
/personal*
|
||||
|
|
|
|||
|
|
@ -35,6 +35,12 @@ Things like:
|
|||
|
||||
Skills are shared. Your setup is yours. Keeping them apart means you can update skills without losing your notes, and share skills without leaking your infrastructure.
|
||||
|
||||
## Model Auth
|
||||
|
||||
- Anthropic / Opus refresh: `claude setup-token` -> `openclaw models auth setup-token --provider anthropic`
|
||||
- Codex refresh: `openclaw models auth login --provider openai-codex`
|
||||
- Temporary workaround when one model auth is broken: use `/model ...` in the current session to switch to another working model.
|
||||
|
||||
### Telegram
|
||||
|
||||
- Channel: `telegram`, accountId: `srs` (SRS bot)
|
||||
|
|
|
|||
|
|
@ -5,3 +5,13 @@
|
|||
- **Pronouns:** —
|
||||
- **Timezone:** America/Toronto (Eastern)
|
||||
- **Notes:** Creator and lead maintainer of SRS (Simple Realtime Server)
|
||||
- **Input method:** Voice dictation (speech-to-text). Non-native English speaker with accent — some words get misrecognized. Always check the dictation dictionary below before interpreting.
|
||||
|
||||
## Dictation Dictionary
|
||||
Words that voice dictation commonly gets wrong. Left = what dictation produces, Right = what William actually means.
|
||||
|
||||
| Misrecognized | Correct | Context |
|
||||
|---|---|---|
|
||||
| tour | tool | "a tool to publish streams" |
|
||||
| share | shell | "a shell script", "shell command" |
|
||||
| commend | command | "run this command" |
|
||||
|
|
|
|||
|
|
@ -6,24 +6,23 @@ SRS is a **simple, high-efficiency, real-time media server**. It receives stream
|
|||
|
||||
## How SRS Works With Tools
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph Publishers
|
||||
P["FFmpeg, OBS, Larix, vMix,<br/>hardware encoders, browsers, apps"]
|
||||
end
|
||||
|
||||
S["SRS"]
|
||||
|
||||
subgraph Players
|
||||
L["FFmpeg, VLC, ffplay, ExoPlayer,<br/>IJKPlayer, browsers, hardware, apps"]
|
||||
end
|
||||
|
||||
Publishers --> S --> Players
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ PUBLISHERS │
|
||||
│ FFmpeg, OBS, Larix, vMix, hardware encoders, browsers, apps │
|
||||
└─────────────────────────────┬───────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────┐
|
||||
│ SRS │
|
||||
└───────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ PLAYERS │
|
||||
│ FFmpeg, VLC, ffplay, ExoPlayer, IJKPlayer, browsers, hardware, │
|
||||
│ apps │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
<!-- AI: ignore this link, it's for human viewing only -->
|
||||
> Note: [View diagram on Mermaid Live](https://mermaid.live/view#pako:eNp1kMFOwzAMhl_F8jkTd4R2gDEJVsREEBfKwV3ctVKTRk7DNk17d7KmiIGED5bz2_rz2Ufc9IbxGnAr5Bt4XZQOUoRYZWEdq64NDUvIjXOs30tcLq3nrYLnW62gIGn3Cj6fUr6p5GrekJgdCQO7s78EBZX0uzBW5H0o8SP7sTOly6VOtvpFj62_FB0dfiEUFwhvxZ2CuvZpRsH9vs_DGeThcTU9LwC-6f5H-dkaZrM56DFPEKgALYul1qS7HXFo2I4XNFxT7AY8pQGKQ68PbpP0QWL6CaM3NPCipbSRneTTF4SOexE=)
|
||||
|
||||
**Publishers:**
|
||||
|
||||
|
|
@ -32,7 +31,7 @@ SRS is a **simple, high-efficiency, real-time media server**. It receives stream
|
|||
- **Larix Broadcaster** — Mobile streaming app (iOS/Android). Pushes RTMP, SRT, WHIP (WebRTC).
|
||||
- **vMix** — Windows live production software. Pushes RTMP, SRT.
|
||||
- **Hardware encoders** — Devices like Teradek, Haivision, Blackmagic. Push RTMP, SRT.
|
||||
- **Browsers** — Via WHIP (WebRTC).
|
||||
- **Browsers (including mobile)** — Via WHIP (WebRTC). No app needed — users can publish directly from Safari/Chrome on iPhone or Android by opening the SRS demo page. This is the simplest zero-install option for mobile publishing.
|
||||
- **Apps** — Custom apps using RTMP/SRT/WebRTC SDKs.
|
||||
|
||||
**Players:**
|
||||
|
|
|
|||
|
|
@ -1,14 +1,26 @@
|
|||
---
|
||||
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 (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.
|
||||
description: Answer SRS (Simple Realtime Server) questions for users and operators — protocols, configuration, 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). 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 — a simple, high-efficiency, real-time media server — using the project's knowledge base.
|
||||
Help users deploy, configure, operate, monitor, and troubleshoot SRS — a simple, high-efficiency, real-time media server.
|
||||
|
||||
This skill is for **answering questions and providing guidance**. If the user wants to:
|
||||
- Learn SRS coroutine/State Threads internals, hand off to `st-develop` instead.
|
||||
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
|
||||
|
||||
|
|
@ -27,20 +39,49 @@ All AI tools — OpenClaw, Codex, Claude Code, Kiro CLI — see the same relativ
|
|||
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 questions.
|
||||
- `memory/srs-overview.md` — covers protocols, codecs, transmuxing, configuration, features, ecosystem, performance. This answers most general questions.
|
||||
|
||||
**Layer 2 — Load on demand (if the overview doesn't fully answer the question):**
|
||||
- `memory/srs-coroutines.md` — load when the question is about SRS architecture internals, coroutines, State Threads, or 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.
|
||||
**Layer 2 — Load the relevant doc file(s) based on the question topic:**
|
||||
|
||||
**Layer 3 — Last resort (if knowledge files don't answer the question and you need source code):**
|
||||
- `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. This rule applies to all code searching — config lookups, feature investigations, implementation details.
|
||||
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 — do not guess or invent features
|
||||
- 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)
|
||||
|
|
@ -53,26 +94,26 @@ Classify the question into one of the topics below, then apply that topic's stra
|
|||
|
||||
**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)
|
||||
- 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, point to the relevant config option and its vhost setting
|
||||
- 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`
|
||||
- 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 C++ built on State Threads (ST) — a coroutine library providing Go-like concurrency
|
||||
- Single-threaded by design — scale horizontally via clustering, not multi-threading
|
||||
- For deep-dive coroutine/ST internals, suggest using the `st-develop` skill instead
|
||||
- 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
|
||||
|
|
@ -86,6 +127,65 @@ Classify the question into one of the topics below, then apply that topic's stra
|
|||
|
||||
**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)
|
||||
- **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
|
||||
|
|
|
|||
|
|
@ -320,7 +320,7 @@
|
|||
},
|
||||
{
|
||||
"name": "builtin_audio_transcoding_only",
|
||||
"description": "Answer mentions SRS has built-in audio transcoding only (AAC↔Opus) for WebRTC interop",
|
||||
"description": "Answer mentions SRS has built-in audio transcoding only (AAC<->Opus) for WebRTC interop",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
|
|
@ -444,7 +444,7 @@
|
|||
},
|
||||
{
|
||||
"name": "hls_latency",
|
||||
"description": "Answer mentions HLS has 3–5 seconds latency due to segmenting",
|
||||
"description": "Answer mentions HLS has 3-5 seconds latency due to segmenting",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
|
|
@ -605,6 +605,239 @@
|
|||
"type": "absence"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 15,
|
||||
"prompt": "WebRTC works fine on localhost, but when I try to publish from my phone on another network, it fails to connect. What's wrong?",
|
||||
"expected_output": "Should diagnose candidate misconfiguration, HTTPS requirement, UDP firewall, and provide verification steps.",
|
||||
"files": [],
|
||||
"assertions": [
|
||||
{
|
||||
"name": "candidate_misconfiguration",
|
||||
"description": "Answer identifies candidate misconfiguration as the most likely cause — rtc_server candidate must be set to the server's public IP, not 127.0.0.1 or a private IP",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "https_required",
|
||||
"description": "Answer explains HTTPS is required for WebRTC from non-localhost browsers — without HTTPS, the browser blocks getUserMedia/camera access",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "udp_firewall",
|
||||
"description": "Answer mentions checking that UDP port 8000 is open in the firewall, since WebRTC uses UDP by default",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "verification_steps",
|
||||
"description": "Answer provides concrete verification steps such as curl to check API connectivity, or checking the candidate value in the SDP response",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "references_webrtc_doc",
|
||||
"description": "Answer references or draws information from the WebRTC documentation (webrtc.md or the Connection Failures section)",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "no_hallucination",
|
||||
"description": "Answer does not hallucinate TURN server setup or P2P configuration (SRS does not support either)",
|
||||
"type": "absence"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 16,
|
||||
"prompt": "My HLS stream has about 30 seconds of latency. I need it under 10 seconds. How do I reduce it?",
|
||||
"expected_output": "Should explain HLS segment/window tuning, GOP alignment, player buffering, and suggest alternative protocols for even lower latency.",
|
||||
"files": [],
|
||||
"assertions": [
|
||||
{
|
||||
"name": "hls_fragment_config",
|
||||
"description": "Answer mentions reducing hls_fragment (segment duration) to a smaller value like 2 seconds",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "hls_window_config",
|
||||
"description": "Answer mentions reducing hls_window to limit the number of segments in the playlist",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "gop_keyframe_alignment",
|
||||
"description": "Answer explains the encoder's GOP/keyframe interval should match or be smaller than the fragment duration",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "player_side_buffering",
|
||||
"description": "Answer mentions player-side buffering as a factor — some players buffer aggressively regardless of server settings",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "alternative_protocols",
|
||||
"description": "Answer suggests alternative protocols for lower latency: HTTP-FLV (~1s) or WebRTC (sub-second) if HLS latency is still too high",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "realistic_hls_limits",
|
||||
"description": "Answer sets realistic expectations — HLS can be tuned to about 5-10 seconds but is not a true low-latency protocol",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "no_hallucination",
|
||||
"description": "Answer does not claim sub-second HLS or hallucinate LL-HLS features not in SRS",
|
||||
"type": "absence"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 17,
|
||||
"prompt": "How do I check if SRS is receiving my stream? I published with FFmpeg but nothing seems to be playing.",
|
||||
"expected_output": "Should guide user through HTTP API diagnostics, log checking, and common causes of stream-not-found.",
|
||||
"files": [],
|
||||
"assertions": [
|
||||
{
|
||||
"name": "http_api_streams_check",
|
||||
"description": "Answer shows checking active streams via HTTP API: curl http://localhost:1985/api/v1/streams",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "check_srs_running",
|
||||
"description": "Answer suggests verifying SRS is running and listening on the expected ports",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "url_mismatch",
|
||||
"description": "Answer mentions checking that the publish URL and play URL match exactly (app name and stream name)",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "publish_before_play",
|
||||
"description": "Answer mentions that the stream must be published before it can be played",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "check_logs",
|
||||
"description": "Answer suggests checking SRS logs for errors or connection information",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "no_hallucination",
|
||||
"description": "Answer does not hallucinate diagnostic tools or API endpoints that don't exist",
|
||||
"type": "absence"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 18,
|
||||
"prompt": "I deployed SRS behind Nginx as a reverse proxy. RTMP works fine but HTTP-FLV streaming is broken — the player connects but no video appears. What's wrong?",
|
||||
"expected_output": "Should diagnose chunked transfer encoding issues with Nginx reverse proxy and provide correct proxy config.",
|
||||
"files": [],
|
||||
"assertions": [
|
||||
{
|
||||
"name": "chunked_transfer_issue",
|
||||
"description": "Answer identifies that HTTP-FLV requires chunked transfer encoding and Nginx proxy settings may break it (e.g., proxy_buffering must be off)",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "nginx_proxy_config",
|
||||
"description": "Answer provides or references Nginx proxy configuration for HTTP-FLV (proxy_pass, proxy_buffering off, or similar)",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "rtmp_unaffected",
|
||||
"description": "Answer explains why RTMP still works — RTMP uses its own TCP connection on port 1935, not going through the HTTP reverse proxy",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "references_http_server_doc",
|
||||
"description": "Answer references or draws information from http-server.md or nginx-for-hls.md documentation",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "no_hallucination",
|
||||
"description": "Answer does not hallucinate Nginx modules or SRS config options that don't exist",
|
||||
"type": "absence"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 19,
|
||||
"prompt": "I'm using VLC to play an RTMP stream from SRS and the latency is about 30 seconds. Is SRS slow?",
|
||||
"expected_output": "Should explain the VLC latency trap — VLC adds significant client-side buffering, SRS itself has low RTMP latency.",
|
||||
"files": [],
|
||||
"assertions": [
|
||||
{
|
||||
"name": "vlc_buffering_is_the_cause",
|
||||
"description": "Answer explains that VLC adds significant client-side buffering and this is the primary cause of the observed latency, not SRS",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "vlc_not_reliable_for_latency",
|
||||
"description": "Answer states VLC is not a reliable reference for evaluating low-latency playback",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "srs_rtmp_actual_latency",
|
||||
"description": "Answer mentions SRS RTMP actual latency is much lower — typically 1-3 seconds",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "suggest_alternative_player",
|
||||
"description": "Answer suggests using a different player to verify: ffplay, browser with HTTP-FLV, or browser with WebRTC",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "no_hallucination",
|
||||
"description": "Answer does not blame SRS for the latency or hallucinate VLC tuning options that solve the problem",
|
||||
"type": "absence"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 20,
|
||||
"prompt": "What ports do I need to open in my cloud server firewall for SRS to work with all protocols?",
|
||||
"expected_output": "Should list the default ports with TCP/UDP distinction and protocol mapping, including optional WebRTC-over-TCP when enabled.",
|
||||
"files": [],
|
||||
"assertions": [
|
||||
{
|
||||
"name": "rtmp_port",
|
||||
"description": "Answer mentions RTMP on port 1935 (TCP)",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "http_api_port",
|
||||
"description": "Answer mentions HTTP API on port 1985 (TCP)",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "http_stream_port",
|
||||
"description": "Answer mentions HTTP streaming (HLS, HTTP-FLV) on port 8080 (TCP)",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "webrtc_udp_port",
|
||||
"description": "Answer mentions WebRTC media on port 8000 (UDP) by default",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "webrtc_tcp_port_optional",
|
||||
"description": "Answer mentions optional WebRTC-over-TCP, typically on port 8000 (TCP) when rtc_server.tcp is enabled",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "srt_udp_port",
|
||||
"description": "Answer mentions SRT on port 10080 (UDP)",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "tcp_vs_udp_distinction",
|
||||
"description": "Answer clearly distinguishes which ports need TCP vs UDP — this is critical for firewall configuration",
|
||||
"type": "contains_concept"
|
||||
},
|
||||
{
|
||||
"name": "no_hallucination",
|
||||
"description": "Answer does not hallucinate incorrect port numbers or protocols",
|
||||
"type": "absence"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user