srs/memory/srs-codebase-map.md
winlin 57d1062e91 Code name: Free. v8.0.0
"Free" represents the new era of open source development empowered by AI. Both freedom and free — the AI agent is not just free labor, it is like a copy of myself, or even tens of copies, all deeply understanding this project, how to deliver high-quality code, and how to serve the community. AI handles all the dirty work — the boring tasks, the documentation, the coding — and often does it better than I could, with ten times the power. We built an AI robot for the community to answer questions and help users learn this project, and we used AI to almost entirely rewrite the SRS Proxy server — its structure, its workflow — so that AI agents can comprehensively manage and maintain it. With AI I have power, and I have choice: no longer waiting for other developers to contribute, I am free to manage this project, freed from the labor of maintaining it alone. This is a fantastic, amazing new era for building and sustaining open source projects and communities.
2026-05-17 12:34:04 -04:00

373 lines
27 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# SRS Codebase Map
⚠️ **CRITICAL RULE:** Only files explicitly listed in this document are trusted. AI must NOT discover, reference, or use any file that is not listed here. If a file is not in this map, it does not exist for AI purposes.
This file helps AI navigate the SRS project. Instead of grepping blindly, AI should use this map to reason about which part of the codebase is relevant to a question, then go directly to the right files.
## Code Structure
SRS has three codebases:
### C++ Media Server Code
The C++ media server (`trunk/src/`) serves as both origin server and edge server. It uses the ST (State Threads) coroutine library and is the full-featured server with all SRS capabilities.
`main/` — Entry point:
- `main_server` — The `main()` function, starts the server
`core/` — Foundational definitions:
- `core` — Core includes, macros, config generated by configure
- `core_version` through `core_version8` — Version definitions per major release
- `core_autofree` — SrsUniquePtr smart pointer (RAII)
- `core_deprecated` — Deprecated SrsAutoFree, kept for compat
- `core_performance` — Performance tuning constants (merge-read, etc.)
- `core_platform` — Platform abstraction (32/64-bit, PRId64, large file support)
- `core_time` — Time types and conversions (srs_utime_t, ms/us)
`kernel/` — Low-level building blocks, no network, no protocol logic:
Media codecs/containers:
- `kernel_codec` — Codec definitions, H.264/H.265/AAC parsing, sequence headers
- `kernel_aac` — AAC transmuxer (raw AAC stream output)
- `kernel_mp3` — MP3 transmuxer
- `kernel_flv` — FLV tag reader/writer, muxer/demuxer
- `kernel_mp4` — MP4/fMP4 box reader/writer
- `kernel_ts` — MPEG-TS muxer/demuxer
- `kernel_ps` — PS (Program Stream) muxer/demuxer (GB28181)
- `kernel_packet` — Media packet: raw undecoded frame with timing info
Buffers & I/O:
- `kernel_buffer` — SrsBuffer: binary read/write cursor over a byte array
- `kernel_stream` — SrsSimpleStream: growable byte buffer
- `kernel_io` — Abstract I/O interfaces (ISrsReader, ISrsSeeker, ISrsWriter)
- `kernel_file` — File reader/writer implementations
RTC primitives:
- `kernel_rtc_rtp` — RTP packet structure, encode/decode
- `kernel_rtc_rtcp` — RTCP packet types, encode/decode
- `kernel_rtc_queue` — RTP ring buffer and reorder queue
Utilities:
- `kernel_error` — Error code definitions and SrsCplxError
- `kernel_log` — Log levels and ISrsLog interface
- `kernel_consts` — Global constants (chunk sizes, timeouts, limits)
- `kernel_utility` — System time, string helpers, bit buffer
- `kernel_kbps` — Bandwidth statistics (ISrsProtocolStatistic, ISrsClock)
- `kernel_balance` — Load balancing algorithms (round-robin)
- `kernel_hourglass` — Timer/hourglass coroutine (periodic callbacks)
- `kernel_pithy_print` — Sampled logging (print every N seconds, not every call)
- `kernel_factory` — Abstract factory interfaces (ISrsKernelFactory)
- `kernel_resource` — Resource management interfaces (ISrsResource, disposing)
- `kernel_st` — ST coroutine wrappers (ISrsCoroutine, ISrsCoroutineHandler)
`protocol/` — Protocol implementations (wire formats, parsing, serialization):
RTMP:
- `protocol_rtmp_stack` — RTMP chunk stream, message parsing, AMF commands
- `protocol_rtmp_conn` — RTMP client/server handshake and command exchange
- `protocol_rtmp_handshake` — RTMP handshake (simple and complex)
- `protocol_rtmp_msg_array` — Shared message array with auto-free
- `protocol_amf0` — AMF0 encoding/decoding
HTTP:
- `protocol_http_stack` — HTTP message, header, URI, serve mux, handler
- `protocol_http_conn` — HTTP connection parsing (request/response)
- `protocol_http_client` — HTTP client for outbound requests
- `protocol_http_stack_llhttp` — llhttp parser (from Node.js)
- `protocol_http_stack_llhttpadapter` — llhttp adapter for SRS
- `protocol_http_stack_llhttpapi` — llhttp API integration
- `protocol_http_stack_llhttphttp` — llhttp HTTP integration
RTC/WebRTC:
- `protocol_rtc_stun` — STUN packet parsing/building
- `protocol_sdp` — SDP parsing/building
- `protocol_rtp` — RTP packetizer (H.264/Opus → RTP packets)
Other protocols:
- `protocol_srt` — SRT socket wrapper
- `protocol_rtsp_stack` — RTSP message parsing
Media:
- `protocol_raw_avc` — Raw H.264/H.265 stream (Annex-B ↔ AVCC conversion)
- `protocol_format` — Media format: extract metadata, codec info from RTMP stream
Infrastructure:
- `protocol_io` — Protocol-level I/O interfaces (ISrsProtocolReader/Writer)
- `protocol_st` — ST initialization, socket helpers, TCP/UDP wrappers
- `protocol_stream` — SrsFastStream: merge-read buffered stream
- `protocol_conn` — Base connection interface (ISrsConnection)
- `protocol_log` — Thread context for logging (SrsThreadContext)
- `protocol_json` — JSON parsing (SrsJsonAny)
- `protocol_utility` — URL parsing, stream URL helpers
- `protocol_protobuf` — Protobuf encoding helpers (for Prometheus/exporter)
`app/` — Application logic (server features, connections, business logic):
Server core:
- `app_server` — SrsServer: main server, manages listeners and connections
- `app_config` — Configuration parsing and access
- `app_listener` — TCP/UDP listener management
- `app_reload` — Config hot-reload handler interface
- `app_st` — Coroutine implementations (SrsFastCoroutine, SrsExecutorCoroutine)
- `app_log` — File-based logger implementation
RTMP:
- `app_rtmp_conn` — RTMP client connection lifecycle (publish, play)
- `app_rtmp_source` — RTMP live source: manages consumers, GOP cache, hub
HTTP:
- `app_http_api` — HTTP API endpoints (/api/v1/...)
- `app_http_conn` — HTTP connection handler (routes to static/stream/api)
- `app_http_hooks` — HTTP callback hooks (on_connect, on_publish, etc.)
- `app_http_static` — HTTP static file serving
- `app_http_stream` — HTTP live streaming (FLV, TS, AAC, MP3 over HTTP)
- `app_http_client` — HTTP client utilities
WebRTC:
- `app_rtc_server` — RTC server: manages RTC connections
- `app_rtc_conn` — RTC connection: publish/play session, DTLS/SRTP
- `app_rtc_source` — RTC source: manages RTC consumers and tracks
- `app_rtc_api` — WHIP/WHEP API endpoints
- `app_rtc_codec` — Audio transcoding (AAC ↔ Opus via FFmpeg)
- `app_rtc_dtls` — DTLS certificate and handshake
- `app_rtc_network` — RTC network I/O, UDP mux
SRT:
- `app_srt_server` — SRT server: manages SRT connections
- `app_srt_conn` — SRT connection lifecycle (publish, play)
- `app_srt_source` — SRT source: manages SRT consumers
- `app_srt_listener` — SRT listener (bind/accept)
RTSP:
- `app_rtsp_conn` — RTSP connection handler
- `app_rtsp_source` — RTSP source
GB28181:
- `app_gb28181` — GB28181 SIP signaling and PS stream ingestion
HLS/DASH:
- `app_hls` — HLS muxer (TS segments + M3U8 playlist)
- `app_dash` — DASH muxer (fMP4 segments + MPD manifest)
- `app_fragment` — Fragment/segment interface for HLS/DASH
DVR:
- `app_dvr` — DVR recording (FLV/MP4 to disk)
Edge/Forward/Bridge:
- `app_edge` — Edge mode: pull/push from origin
- `app_forward` — Forward: push stream to another RTMP server
- `app_stream_bridge` — Bridge between sources (RTMP↔RTC↔SRT)
Ingest/Transcode:
- `app_ingest` — Ingest: pull external streams via FFmpeg
- `app_encoder` — Transcode: FFmpeg transcoding management
- `app_ffmpeg` — FFmpeg process wrapper
Utilities:
- `app_security` — Security: allow/deny rules for publish/play
- `app_refer` — Referer check
- `app_statistic` — Server/stream/client statistics
- `app_heartbeat` — HTTP heartbeat to API server
- `app_utility` — System info, disk/CPU/memory stats
- `app_process` — Child process management
- `app_async_call` — Async HTTP callback execution
- `app_recv_thread` — Background RTMP message receive thread
- `app_ng_exec` — exec hooks (on_publish exec)
- `app_factory` — Application-level factory (file I/O, paths)
- `app_coworkers` — Origin cluster coordination
- `app_latest_version` — Version check against upstream
- `app_caster_flv` — HTTP-FLV push ingest (stream caster)
- `app_mpegts_udp` — MPEG-TS over UDP ingest
- `app_stream_token` — Stream publish token management
- `app_circuit_breaker` — Circuit breaker for overload protection
- `app_hds` — HDS (Adobe HTTP Dynamic Streaming)
**File naming convention:** All C++ source files use `srs_{module}_{topic}.cpp/.hpp` — e.g. `srs_app_rtmp_conn.cpp`, `srs_protocol_amf0.hpp`, `srs_kernel_flv.cpp`.
**Config**
Config (`trunk/conf/`) is only for the C++ media server. The next-generation Go server does not use these config files.
- `srs.conf` — Default config
- `full.conf` — Full reference config with all options documented
- Feature-specific configs: `rtc.conf`, `srt.conf`, `hls.conf`, `dvr.*.conf`, `edge.conf`, `forward.*.conf`, `gb28181.conf`, `dash.conf`, etc.
### State Threads Code
State Threads (`trunk/3rdparty/st-srs/`) is the coroutine library used by the C++ media server only. The Go server does not use ST.
- `sched.c` — Scheduler (thread creation, context switch, run loop)
- `io.c` — I/O: poll/epoll/kqueue wrappers, socket operations
- `event.c` — Event system
- `stk.c` — Stack allocation and management
- `sync.c` — Mutex, condition variable
- `key.c` — Thread-local storage
- `common.c`/`common.h` — Shared internals
- `public.h` — Public API
- `md.h` — Platform detection and context switch macros
- `md_linux.S`, `md_linux2.S`, `md_darwin.S`, `md_cygwin64.S` — Assembly context switch per platform
### Next-Generation Server Code
The next-generation server (`cmd/` + `internal/`) is written in Go and maintained by AI. It is the future of SRS. Currently it only supports proxy, but work is ongoing to support the full feature set including origin, edge, and proxy servers.
`cmd/proxy` — A stateless reverse proxy that sits in front of one or more SRS C++ origin servers. Accepts client connections (RTMP, HTTP-FLV/HLS, WebRTC WHIP/WHEP, SRT), resolves a backend origin via the load balancer, and transparently proxies traffic. Does not cache streams or process media — only forwards bytes. Configuration entirely via environment variables (or `.env` file), no config file. Supports two deployment modes: single-proxy (in-memory LB) and multi-proxy (Redis-based shared LB for horizontal scaling behind a network load balancer). Entry point: `cmd/proxy/main.go`.
`internal/bootstrap` — Server startup and lifecycle orchestration. Sets up logging context, signal handlers, loads environment, installs force-quit timer, optionally starts pprof, initializes the load balancer (memory or Redis based on `PROXY_LOAD_BALANCER_TYPE`), then starts all six servers sequentially (RTMP, WebRTC, HTTP API, SRT, System API, HTTP Stream) and blocks until context is cancelled. Deferred `Close()` on each server ensures graceful shutdown.
`internal/proxy` — Proxy server implementations. Each server accepts client connections, parses just enough of the protocol to extract the stream URL, picks a backend via the load balancer, and proxies traffic bidirectionally. Contains five proxy servers: (1) **RTMP proxy** (`rtmp.go`) — TCP listener, simple handshake, parses connect/publish/play to get stream URL, bidirectional RTMP message copying, stateless. (2) **HTTP stream proxy** (`http.go`) — serves static files, proxies HTTP-FLV/TS via reverse-proxy, proxies HLS m3u8 with `spbhid` rewriting so TS segment requests route to the same backend. (3) **WebRTC proxy** (`rtc.go`) — two-phase: WHIP/WHEP signaling (SDP rewrite to replace backend UDP port with proxy's) + UDP media transport (identifies connections by STUN ufrag, supports address migration), stateful. (4) **SRT proxy** (`srt.go`) — intercepts SRT 4-step handshake locally, parses stream ID on handshake 2, replays full handshake with backend, then proxies UDP bidirectionally, stateful per-connection. (5) **HTTP API + System API** (`api.go`) — HTTP API delegates WHIP/WHEP to WebRTC server; System API provides `/api/v1/srs/register` where backend SRS C++ servers register themselves so the load balancer knows about them.
`internal/rtmp` — RTMP protocol implementation (parsing, not proxying). Full RTMP chunk stream and message protocol: simple handshake (C0/C1/C2), chunk stream reader/writer with all four format types, extended timestamp, message reassembly from chunks. Defines all RTMP message types, chunk stream IDs, and command names. Packet types include ConnectApp, CreateStream, Publish, Play, Call, SetChunkSize, WindowAcknowledgementSize, SetPeerBandwidth, UserControl. Uses Go generics (`ExpectPacket[T]`) to read until a specific packet type arrives. Also includes full AMF0 encoder/decoder supporting Number, Boolean, String, Object, Null, Undefined, EcmaArray, StrictArray, Date, LongString — with ordered key-value maps, auto-type-discovery, and safe type converters.
`internal/lb` — Load balancer abstraction and two implementations. Defines `OriginLoadBalancer` interface and core types in `lb.go` (Initialize, Update, Pick, HLS/WebRTC state management) and `OriginServer` struct representing a backend origin (IP, listen endpoints for RTMP/HTTP/API/SRT/RTC, heartbeat tracking). **Memory LB** (`mem.go`) — in-memory using `sync.Map`, sticky random pick per stream URL, single-proxy deployment. **Redis LB** (`redis.go`) — Redis-backed shared state with TTL-based expiration, enables multi-proxy horizontal scaling behind a network load balancer. Also includes a debug helper (`debug.go`) that creates a fake backend from env vars when `PROXY_DEFAULT_BACKEND_ENABLED=on` for development without real SRS registration.
`internal/redisclient` — Thin Redis client abstraction. Defines a minimal `RedisClient` interface (`Ping`/`Get`/`Set`/`String`) satisfied by `*redis.Client` from `github.com/go-redis/redis/v8`, plus a `New(addr, password, db)` constructor. Used by `internal/lb/redis.go`.
`internal/logger` — Structured logging with context IDs. Four log levels: Debug/Info (stdout), Warn/Error (stderr). Emits JSON via `log/slog` with `pid` and `cid` attributes. Each connection/request gets a unique 7-char hex context ID for log correlation, stored in `context.Context`.
`internal/env` — Environment-based configuration. All settings via env vars (or `.env` file parsed by an in-tree custom parser — no third-party dep; supports comments, `export` prefix, quoted values, escape sequences, and inline comments). Exposes a `ProxyEnvironment` interface (with a counterfeiter-generated fake in `envfakes/` for downstream tests) with methods for each config value. Default ports: RTMP=11935, HTTP API=11985, HTTP Stream=18080, WebRTC=18000, SRT=20080, System API=12025. Timeouts: grace=20s, force=30s. Supports Redis config and default backend config for debugging.
`internal/version` — Version constants. Signature `SRSX`, version tracks the SRS project version (currently 8.0.x). Used in HTTP API responses and startup logging.
`internal/errors` — Error handling with stack traces, thin wrapper over stdlib `errors`. Provides `New`, `Errorf`, `Wrap`, `Wrapf`, `WithMessage`, `WithStack`, `Cause`, and re-exports `Is`/`As`/`Unwrap`/`Join`. Every error captures a stack trace at creation; `%+v` prints the full trace. `Cause()` walks the error chain to find the root error.
`internal/sync` — Generic sync primitives. `Map[K, V]`: type-safe generic interface over `sync.Map`, constructed via `NewMap[K, V]()`. Used throughout the codebase to avoid raw type assertions.
`internal/signal` — OS signal handling. Listens for SIGINT/SIGTERM, cancels the root context. Installs a force-quit timer (default 30s) as a safety net if graceful shutdown hangs.
`internal/debug` — Profiling. Starts a `net/http/pprof` server if `GO_PPROF` env var is set. Optional, for runtime profiling and debugging.
`internal/utils` — Shared utility functions. HTTP helpers (JSON response, error response, CORS, body parsing). URL helpers (normalize to `vhost/app/stream` format, extract app/stream from HTTP requests). Protocol helpers (classify UDP payload as STUN/RTP/SRT, parse ICE ufrag/pwd from SDP, parse SRT stream ID). Network helpers (detect peer-closed/connection-closed errors, parse listen endpoints).
## Knowledge Base Structure
The knowledge base (`memory/srs-*.md`) captures William's knowledge about SRS — architecture, design decisions, protocols, and how things work. This is the AI's first stop for understanding *why* things are the way they are.
- `memory/srs-overview.md` — What SRS is, protocols, ecosystem tools, and features list
- `memory/srs-coroutines.md` — State Threads coroutine library, why SRS uses coroutines, how context switching works, platform matrix, multi-CPU strategy
- `memory/srs-codebase-map.md` — This file: codebase structure, file navigation, module boundaries
## Documentation Structure
### Tracking Docs
**Tracking** — Project changelog and version history:
- `trunk/doc/CHANGELOG.md` — Full changelog of all SRS versions, one entry per merged PR with version bump
### C++ Media Server Docs
**C++ Media Server Docs** (`trunk/3rdparty/srs-docs/doc/`) — User-facing documentation:
- `introduction.md` — SRS overview: what it is, supported protocols (RTMP/WebRTC/HLS/SRT/etc.), features list, ST coroutine architecture, and learning path
- `getting-started.md` — Quick start with Docker: live streaming (RTMP publish, HTTP-FLV/HLS play), WebRTC publish/play, RTMP-to-WebRTC conversion, HTTPS for WebRTC on remote servers, SRT publishing, and multiple streams with flexible URL patterns
- `getting-started-ai.md` — AI tools for SRS: SRS Robot (Telegram/Discord), local agents (Claude Code, Codex, Kiro, OpenClaw) with pre-configured knowledge base, skills system for task-specific workflows, and the knowledge base philosophy (implicit knowledge made explicit)
- `getting-started-build.md` — Build SRS from source: configure/make, live streaming and WebRTC setup, cross-build for ARM/MIPS
- `getting-started-cdk.md` — Deploy SRS on AWS using srs-cdk (stub page, links to GitHub repo)
- `getting-started-oryx.md` — Oryx (SRS Stack): out-of-the-box cloud solution with recording, forwarding, AI subtitles, HTTPS, Docker/HELM/aaPanel deployment
- `rtmp.md` — RTMP protocol: usage, Enhanced RTMP (HEVC/AV1), config, RTMPS, comparison with SRT/WebRTC, codec support history
- `hls.md` — HLS streaming: cross-platform compatibility, latency tradeoffs, config (segment duration, cleanup), HTTPS, audio transcoding from WebRTC
- `webrtc.md` — WebRTC: WHIP/WHEP signaling, SFU architecture, RTMP-to-RTC conversion, TURN/ICE config, audio transcoding (AAC↔Opus), multi-platform usage
- `flv.md` — HTTP-FLV live streaming: chunked HTTP delivery, ~3-5s latency, config, comparison with HLS and RTMP, browser compatibility (MSE)
- `srt.md` — SRT protocol: UDP-based low-latency (300-500ms), TS encapsulation, HEVC support, config, streamid format, weak network advantages over RTMP
- `rtsp.md` — RTSP playback server (v7.0.47+): TCP transport only, publish via RTMP then play via RTSP, config, compile with --rtsp=on
- `http-server.md` — Embedded HTTP server: serves HLS/static files, API endpoint, config for port/root, works with NGINX/Caddy reverse proxy
- `hevc.md` — H.265/HEVC support: Enhanced RTMP, protocol compatibility matrix (TS/SRT/HLS/RTMP/WebRTC), encoder setup, bandwidth savings vs H.264
- `dvr.md` — DVR recording: save RTMP streams to FLV/MP4 files, config (plan/path), HTTP callbacks for dynamic DVR, Oryx for advanced features (S3, filters)
- `ingest.md` — Ingest: pull external streams (files, RTSP cameras, HTTP) via FFmpeg and republish as RTMP to SRS, virtual live streaming use case
- `forward.md` — Forward streams to other RTMP servers for fault backup, master/slave roles, config per vhost/app, comparison with edge mode
- `security.md` — IP-based security: allow/deny rules for publish/play per vhost using IP addresses or CIDR ranges
- `snapshot.md` — Stream thumbnails: capture snapshots via HTTP callbacks (on_publish/on_unpublish triggering FFmpeg) or transcoder
- `http-api.md` — HTTP API (/api/v1/...): JSON endpoints for server/stream/client stats, srs-console integration, CORS support
- `http-callback.md` — HTTP callbacks: SRS notifies your business server on events (on_connect, on_publish, on_play, on_dvr, etc.) for auth and custom logic
- `exporter.md` — Prometheus exporter: metrics endpoint for Grafana integration, config for labels/tags, cloud-native observability
- `origin-cluster.md` — Origin cluster: proxy-based load balancing across multiple origin servers, Go proxy architecture, replaces old RTMP-based origin cluster
- `edge.md` — Edge server: caches streams from origin for massive playback scale, pull-on-play and push-on-publish, multi-level edge topology for CDN
- `nginx-for-hls.md` — HLS/DASH distribution via NGINX reverse proxy with caching, edge cluster for file-based streaming (not RTMP edge)
- `resource.md` — Ports reference: RTMP(1935), HTTP API(1985), HTTP streaming(8080), WebRTC(8000/udp), SRT(10080/udp), HTTPS, and optional converters
- `low-latency.md` — Low-latency live streaming: RTMP tuning (0.8-3s), GOP/queue config, merge-write optimization, protocol comparison
- `performance.md` — Performance tools: RTC UDP buffer tuning, perf/gprof/valgrind profiling, memory leak detection, ASAN, benchmarking methodology
- `ffmpeg.md` — FFmpeg transcoding: SRS forks FFmpeg for 1-in-N-out transcoding, multi-bitrate output, stream filters (logo), config per vhost/app/stream
**C++ Media Server Pages** (`trunk/3rdparty/srs-docs/pages/`) — Website pages (how SRS presents itself publicly):
- `faq-oryx-en.md` — Oryx FAQ: getting started, upgrade, domain/HTTPS setup, push auth, recording (S3/filters/merge), re-streaming, FFmpeg replacement
- `faq-server-en.md` — SRS server FAQ: CDN/VoD questions, common errors, protocol issues, links to Stack Overflow/GitHub Issues/Discord for support
- `license-en.md` — License details: SRS is MIT, State Threads is MPL/GPL dual-license, plus licenses for all third-party libraries (OpenSSL, libsrt, ffmpeg, etc.)
- `product-en.md` — Release history: milestones from v1.0 (2013) to v7.0 (2025+), codenames, key achievements per release, AI contributor era (2025+)
- `security-advisories-en.md` — CVE reports: CVE-2024-29882 (JSONP XSS), CVE-2023-34105 (command injection in demo api-server), with patch versions and links
### Next-Generation Server Docs
**Next-Generation Server Docs** (`docs/proxy/`) — Documentation for the Go server:
- `proxy-design.md` — Architecture: stateless proxy with built-in load balancing, single-proxy vs multi-proxy (Redis) deployment modes, horizontal scaling behind NLB
- `proxy-protocol.md` — Backend registration protocol: default backend for debugging, automatic registration via SRS system API, heartbeat mechanism, env vars
- `proxy-usage.md` — Step-by-step guide: build proxy, start SRS origin, verify registration, publish with FFmpeg, verify playback with ffprobe
- `proxy-load-balancer.md` — Load balancer design: memory vs Redis implementations, stream-to-server mapping, server health via heartbeats, protocol-specific state
- `proxy-origin-cluster.md` — Origin cluster tutorial: build proxy + SRS, configure multi-origin with proxy, stream publishing and playback verification
**Next-Generation Server API Examples** — Executable API documentation:
- `internal/rtmp/example_test.go` — RTMP API examples: AMF0, handshake, and protocol workflow
## Testing and Verification Structure
How to verify SRS works correctly.
`trunk/src/utest/` — Unit tests (white-box, testing internal logic):
- **What it tests:** Internal logic — functions, classes, parsing, codec handling, config parsing — all without starting SRS. Links directly against SRS source code, uses mock objects (e.g., `MockSrsConfig`). No network, no server process. ~2,351 tests.
- **Binary:** `./objs/srs_utest` (build with `cd trunk && ./configure --utest && make utest`)
- 3 categories:
- `srs_utest_ai01``ai24` — AI-written tests
- `srs_utest_manual_*` — Manually written tests
- `srs_utest_workflow_*` — Workflow/integration tests
`trunk/3rdparty/srs-bench/blackbox/` — Black-box tests (testing SRS as a running server from outside):
- **What it tests:** SRS as a running process, from the outside. Each test starts its own SRS server via `NewSRSServer()`, then uses FFmpeg/FFprobe to publish/play streams and verify output. The test manages the full SRS lifecycle. ~30 tests.
- **Binary:** `./objs/srs_blackbox_test` (build with `make` in `trunk/3rdparty/srs-bench/`)
- `rtmp_test.go` — RTMP black-box tests
- `hls_test.go` — HLS black-box tests
- `srt_test.go` — SRT black-box tests
- `rtsp_test.go` — RTSP black-box tests
- `hevc_test.go` — HEVC black-box tests
- `dvr_test.go` — DVR black-box tests
- `http_api_test.go` — HTTP API black-box tests
- `mp3_test.go` — MP3 black-box tests
`trunk/3rdparty/srs-bench/srs/` — E2E tests (end-to-end protocol testing):
- **What it tests:** End-to-end protocol correctness against a pre-running SRS server (you start SRS yourself). Uses real protocol clients — Pion WebRTC library for RTC (WHIP/WHEP), RTMP client, HTTP API — to publish, play, and verify stream behavior. Heavy focus on WebRTC protocol correctness. ~45 tests.
- **Binary:** `./objs/srs_test` (build with `make` in `trunk/3rdparty/srs-bench/`)
- `rtc_test.go` — WebRTC E2E tests
- `rtmp_test.go` — RTMP E2E tests
- `srs_test.go` — General SRS E2E tests
`trunk/3rdparty/srs-bench/` — Load test benchmark:
- **What it tests:** Performance and load capacity — not correctness. A CLI tool that simulates many concurrent WHIP publishers, WHEP players, RTMP clients, etc. against a running SRS. Not a test suite — no pass/fail assertions, it's a benchmarking/stress tool.
- **Binary:** `./objs/srs_bench` (entry: `main.go`, build with `make` in `trunk/3rdparty/srs-bench/`)
- Publisher for WHIP
- Player for WHEP
- Multiple WHIP or WHEP for RTC
- DVR for RTC Benchmark
- RTC Plaintext
- Reconnecting Load Test
- Janus
`.openclaw/skills/srs-develop/scripts/` — Go proxy verification and setup scripts:
- `proxy-utest.sh` — Runs Go proxy unit tests with optional coverage.
- `proxy-e2e-test.sh` — Single-origin RTMP proxy E2E test.
- `proxy-e2e-cluster-test.sh` — Multi-origin memory load-balancer E2E test.
- `proxy-e2e-redis-test.sh` — Multi-proxy Redis load-balancer E2E test.
- `proxy-e2e-transmux-test.sh` — RTMP publish through proxy, then verify RTMP, HTTP-FLV, HLS, and WebRTC playback.
- `proxy-e2e-srt-test.sh` — SRT publish through proxy, then verify SRT, RTMP, HTTP-FLV, and HLS playback (WebRTC WHEP is a placeholder).
- `proxy-e2e-whip-test.sh` — WHIP (WebRTC) publish through proxy, then verify RTMP, HTTP-FLV, and HLS playback via the origin's `rtc_to_rtmp` bridge (WebRTC WHEP is a placeholder).
- `setup-ffmpeg-with-whip.sh` — macOS-only: build ffmpeg from source into `~/.local/` with WHIP (openssl DTLS) and SRT support; auto-invoked by `proxy-e2e-srt-test.sh` and `proxy-e2e-whip-test.sh` when no suitable ffmpeg is found.
**Summary: The Key Differences**
| | Unit Tests | Black-box | E2E | Benchmark |
|---|---|---|---|---|
| **SRS running?** | No | Yes (self-managed) | Yes (external) | Yes (external) |
| **Tests what?** | Internal logic | Whole server behavior | Protocol correctness | Performance/load |
| **Language** | C++ | Go | Go | Go |
| **Network?** | No | Yes (real protocols) | Yes (real protocols) | Yes (real protocols) |
| **Pass/fail?** | Yes | Yes | Yes | No (metrics only) |
| **Count** | ~2,351 | ~30 | ~45 | N/A |
Progression: unit (isolated logic) → black-box (server as a whole, self-contained) → E2E (protocol-level against live server) → benchmark (stress/capacity). Each layer catches different classes of bugs.