diff --git a/.claude/settings.local.json b/.claude/settings.local.json index 283abda8b..e314d9ce8 100644 --- a/.claude/settings.local.json +++ b/.claude/settings.local.json @@ -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": [ { diff --git a/.gitignore b/.gitignore index b4b8e99eb..53312040f 100644 --- a/.gitignore +++ b/.gitignore @@ -47,4 +47,4 @@ srs-proxy # For AI /*personal* - +/*workspace* diff --git a/.openclaw/.gitignore b/.openclaw/.gitignore index 03243bb73..7bc63699a 100644 --- a/.openclaw/.gitignore +++ b/.openclaw/.gitignore @@ -4,6 +4,7 @@ /.pi /extensions /skills/llm-switcher +/skills/*workspace* # For speical folders. /personal* diff --git a/.openclaw/TOOLS.md b/.openclaw/TOOLS.md index e5084197b..75f99b24e 100644 --- a/.openclaw/TOOLS.md +++ b/.openclaw/TOOLS.md @@ -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) diff --git a/.openclaw/USER.md b/.openclaw/USER.md index d431db707..2f96978d1 100644 --- a/.openclaw/USER.md +++ b/.openclaw/USER.md @@ -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" | diff --git a/.openclaw/memory/srs-overview.md b/.openclaw/memory/srs-overview.md index 966abdead..18a30596e 100644 --- a/.openclaw/memory/srs-overview.md +++ b/.openclaw/memory/srs-overview.md @@ -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,
hardware encoders, browsers, apps"] + end + + S["SRS"] + + subgraph Players + L["FFmpeg, VLC, ffplay, ExoPlayer,
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 │ -└─────────────────────────────────────────────────────────────────┘ -``` + + +> 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:** diff --git a/.openclaw/skills/srs-support/SKILL.md b/.openclaw/skills/srs-support/SKILL.md index 2247a78b1..661610dff 100644 --- a/.openclaw/skills/srs-support/SKILL.md +++ b/.openclaw/skills/srs-support/SKILL.md @@ -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 diff --git a/.openclaw/skills/srs-support/evals/evals.json b/.openclaw/skills/srs-support/evals/evals.json index 9e18faf4e..841ff9633 100644 --- a/.openclaw/skills/srs-support/evals/evals.json +++ b/.openclaw/skills/srs-support/evals/evals.json @@ -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" + } + ] } ] }