SRS 实时媒体服务器全景指南：协议、转封装、编解码与部署实践-酒店常州论坛

SRS 实时媒体服务器全景指南：协议、转封装、编解码与部署实践

【免费下载链接】srsSRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711.项目地址: https://gitcode.com/GitHub_Trending/sr/srs

SRS（Simple Realtime Server）是一个简单、高性能、AI 驱动的实时媒体服务器：一端接收来自各类推流端的媒体流，另一端将它们以最适合的协议交付给播放端。它原生支持 RTMP、WebRTC、HLS、HTTP-FLV、HTTP-TS、SRT、MPEG-DASH 与 GB28181 等协议，并以"转封装（Transmux）"为核心设计理念，在不重编码视频的前提下实现协议间的高效互转。读完本文，你将全面掌握 SRS 的协议矩阵与延迟画像、推流/播放工具链的选型、各协议转换开关的配置方法，并能基于仓库内真实配置文件与源码完成一次完整的"推流—播放"实战。

什么是 SRS

SRS 是一个simple, high-efficiency, real-time media server（简单、高效、实时媒体服务器）。它接收发布者（Publisher）推上来的流，再把流交付给播放者（Player）。整个项目的定位可以概括为一句线性的数据流：

Publishers（推流端） --> SRS --> Players（播放端）

在 srs-overview.md 中，这一架构用如下 Mermaid 图表示：

从仓库结构看，SRS 的 C++ 核心位于 trunk/src，其中 trunk/src/app 存放应用层实现（如srs_app_rtmp_conn.cpp、srs_app_rtc_conn.cpp、srs_app_srt_conn.cpp、srs_app_http_stream.cpp等），trunk/src/protocol 存放各协议栈实现（RTMP、RTSP、SRT、SDP、RTP/RTCP、HTTP 栈等），服务进程入口在 trunk/src/main/srs_main_server.cpp。可以推断：SRS 的每个协议连接都对应 app 层的一个连接类，协议解析则由 protocol 层完成，两者通过统一的消息/包结构衔接，这也是它能轻松实现协议互转的架构基础。

推流端与播放端：工具生态一览

推流端（Publishers）

SRS 兼容几乎所有主流推流工具，覆盖桌面、移动端与硬件设备：

FFmpeg—— 命令行编码/转码工具。可推 RTMP、SRT、WHIP（WebRTC）等协议。
OBS（Open Broadcaster Software）—— 流行的开源直播软件。可推 RTMP、SRT、WHIP（WebRTC）。
Larix Broadcaster—— 移动端推流 App（iOS/Android）。可推 RTMP、SRT、WHIP（WebRTC）。
vMix—— Windows 直播制作软件。可推 RTMP、SRT。
硬件编码器—— 如 Teradek、Haivision、Blackmagic 等设备，推 RTMP、SRT。
浏览器（含移动端）—— 通过 WHIP（WebRTC）推流。无需安装任何 App，用户在 iPhone/Android 的 Safari/Chrome 上直接打开 SRS 演示页即可推流，这是移动端零安装推流的最简方案。
自定义 App—— 使用 RTMP/SRT/WebRTC SDK 开发的应用程序。

播放端（Players）

VLC—— 跨平台播放器，可播 RTMP、SRT、HLS、HTTP-FLV、RTSP。但 VLC 常常叠加大量播放端缓冲，不适合作为评估低延迟播放效果的参考（这一点在评估延迟时非常重要，详见下文）。
FFmpeg—— 命令行工具，可播 RTMP、SRT、HLS、HTTP-FLV（除 WHEP 外全部支持）。
ffplay—— FFmpeg 自带播放器，协议支持与 FFmpeg 相同（除 WHEP 外）。
ExoPlayer—— Android 播放器库，播 HLS、DASH。
IJKPlayer—— 基于 FFmpeg 的跨平台播放器（B 站开源），播 RTMP、HLS、HTTP-FLV。
mpegts.js（原 flv.js）—— 浏览器 JavaScript 播放器，通过 MSE 播 HTTP-FLV、HTTP-TS、HLS。
浏览器—— 通过 MSE 播 HTTP-FLV、HLS、HTTP-TS，通过 WHEP（WebRTC）播放。
硬件解码端—— 机顶盒、智能电视等，播 HLS、RTMP。
自定义 App—— 使用播放器 SDK 开发的应用程序。

协议矩阵：每个协议都同时支持输入与输出

SRS 的核心协议（RTMP、SRT、WebRTC）都同时支持推流（输入）和播放（输出），这是它区别于纯转码服务器或纯播放网关的关键。各协议的实际延迟画像如下：

协议	典型推流端	典型播放端	定位	实测典型延迟
RTMP	OBS、FFmpeg、Larix	VLC、ffplay	传统直播	低延迟类（约 1~3 秒）
SRT	OBS、vMix、硬件	ffplay、VLC、硬件	远距离专业广播	低延迟/实时类（约 500ms~1s）
WebRTC	浏览器、App	浏览器、App	实时通信、会议	SRS 中延迟最低（约 50ms~400ms）
HLS/HTTP-FLV	——（仅输出）	ExoPlayer、mpegts.js、浏览器	广泛兼容播放	HTTP-FLV 低延迟（约 1~3 秒）；HLS 典型约 10~30 秒
RTSP	——（仅输出）	VLC、FFmpeg、ffplay	监控、IP 摄像头	——

几个关键结论值得强调：

HLS 是分发的事实标准，但延迟最高。正常部署下 HLS 典型延迟约 10~30 秒；即便激进调优 playlist/分片参数和播放器缓冲，通常也只能降到约 5~10 秒，本质上仍不是真正的低延迟协议。
WebRTC 是 SRS 中延迟最低的协议，典型约 50ms~400ms，适合会议等实时互动场景。
SRT 处于低延迟/实时档位，典型约 500ms~1s，适合远距离、弱网下的专业广播。
评估延迟时不要用 VLC 作参考播放器，因为其客户端缓冲会主导观测到的延迟，无法反映 SRS 与协议本身的真实表现。

协议转封装（Transmux）：不重编码的协议互转

SRS 的核心理念是Transmux（转封装）——在不同协议之间直接转换，而不改变编码格式。例如：以 H.264 推 RTMP，可以 H.264 原样交付为 HTTP-FLV、HLS、MPEG-DASH 或 WebRTC。转封装只是把媒体流重新打包进不同的协议格式，并非重新编码（重新编码需要外部 FFmpeg）。

SRS 支持的转封装路径及对应配置开关如下：

WebRTC → RTMP—— vhost 配置rtc_to_rtmp on。音频从 Opus 转码为 AAC。
RTMP → WebRTC—— vhost 配置rtmp_to_rtc on。音频从 AAC 转码为 Opus。
SRT → RTMP—— vhost 配置srt_to_rtmp on。SRT 承载 MPEG-TS，解封装后转为 RTMP。
SRT → WebRTC—— 直接转换，音频从 AAC 转码为 Opus。
GB28181 → RTMP—— 用于监控摄像头推 PS 流，SIP 信令依赖外部 srs-sip 组件。
RTMP → HLS—— 切片为.m3u8+.ts文件。正常部署延迟约 10~30 秒；激进调优分片时长、播放列表窗口和播放器缓冲后有时可降至约 5~10 秒。
RTMP → HTTP-FLV—— 经 HTTP 转封装为 FLV，约 1 秒延迟。
RTMP → HTTP-TS—— 经 HTTP 转封装为 MPEG-TS。
RTMP → RTSP—— vhost 配置rtmp_to_rtsp on，仅支持 TCP 传输。
RTMP → MPEG-DASH—— 切片为 DASH manifest + 分片。

这些配置开关在源码中有明确的解析逻辑。以 trunk/src/app/srs_app_config.cpp 为例，rtmp_to_rtc、rtc_to_rtmp、srt_to_rtmp、rtmp_to_rtsp均有对应的get_系列读取函数，并支持环境变量覆盖（如SRS_VHOST_RTC_RTMP_TO_RTC、SRS_VHOST_SRT_SRT_TO_RTMP、SRS_VHOST_RTSP_RTMP_TO_RTSP）。默认情况下，源之间的转封装是关闭的，需要在配置中显式开启。

延迟评估的总体结论：端到端延迟不仅取决于 SRS 与协议，还取决于播放器。直播场景下，HLS 是分发的事实标准但延迟最高（典型 10~30 秒，激进调优可到 5~10 秒）；HTTP-FLV 与 RTMP 是低延迟协议（典型 1~3 秒）；SRT 与 WebRTC 同样属于低延迟/实时协议，其中 WebRTC 通常延迟最低（约 50ms~400ms），SRT 约 500ms~1s。评估延迟时务必避开 VLC 这类带大缓冲的播放器。

编解码器支持与内置音频转码

视频编解码器

H.264/AVC—— 核心视频编码，自 v0.2（2013 年）起支持，覆盖全部协议：RTMP、HLS、HTTP-FLV、HTTP-TS、SRT、WebRTC、MPEG-DASH、GB28181、DVR。
H.265/HEVC—— 自 v6.0 起通过 Enhanced RTMP 支持，覆盖 RTMP、HTTP-FLV、HTTP-TS、HLS（v7.0 含 fMP4/LLHLS）、MPEG-DASH、SRT、GB28181、DVR（MP4/FLV）。WebRTC 的 HEVC 在 v7.0 支持（RTMP↔WebRTC 转换及 Safari 播放）。
AV1—— [实验性] 仅 WebRTC，v4.0.207+。
VP9—— 仅 WebRTC 端到端推流，v7.0.123+。

音频编解码器

AAC—— 核心音频编码，自 v1.0 起支持，覆盖 RTMP、HLS、HTTP-FLV、HTTP-TS、SRT、MPEG-DASH、GB28181、DVR；输出 WebRTC 时转码为 Opus。
MP3—— 支持 HLS（H.264+MP3）、HTTP-FLV/TS、DVR，v1.0+；输出 WebRTC 时转码为 Opus。
Opus—— WebRTC 原生音频编码，v4.0+；输出 RTMP 时转码为 AAC。SRS 内置 AAC↔Opus 转码。
G.711（PCMU/PCMA）—— WebRTC 音频编码，v7.0.124+。

注意：v7.0.102+ 仅支持 AAC、MP3、Opus 三种音频编码，其他音频编码会被拒绝。

内置音频转码（无需外部进程）

AAC → Opus—— 转换 RTMP/SRT 到 WebRTC 时自动进行（rtmp_to_rtc on）。
Opus → AAC—— 转换 WebRTC 到 RTMP 时自动进行（rtc_to_rtmp on）。
MP3 → Opus—— 转换 RTMP(MP3) 到 WebRTC 时自动进行，v5.0.118+。

关键实现细节：音频转码使用 FFmpeg 的 libavcodec API（以库形式链接），而不是启动外部 FFmpeg 进程；SRS 没有内置视频转码，视频在转封装时不做重编码，如需视频转码应使用外部 FFmpeg。

RTSP 输出的编解码限制

SRS 的 RTSP 输出（rtmp_to_rtsp on）仅支持 H.264 + AAC，即使 RTSP 协议本身支持更多编解码。这是 SRS 实现的限制，而非协议限制。

传输层：TCP 与 UDP 的取舍

SRS 各协议使用的底层传输如下：

协议	传输层
RTMP	TCP
SRT	UDP（内置可靠性与加密）
WebRTC	UDP（v5.0.60+ 也支持 TCP）
HLS	TCP（基于 HTTP）
HTTP-FLV	TCP（基于 HTTP）
HTTP-TS	TCP（基于 HTTP）
MPEG-DASH	TCP（基于 HTTP）
RTSP	TCP（SRS 仅支持 TCP 传输，无 UDP/RTP 交错）
GB28181	TCP（PS 流经 TCP）

此外，媒体行业中有几个重要但SRS 与 Oryx 均不支持的传输协议，需要明确区分：

RIST—— 基于 UDP。Reliable Internet Stream Transport，与 SRT 类似：UDP 上的可靠、低延迟媒体传输，支持重传与加密选项。
MoQ—— 基于 UDP/QUIC。Media over QUIC，IETF 推动的基于 QUIC 的低延迟媒体接入与分发方案，通常走 UDP，可选经 WebTransport。
WebTransport—— 基于 UDP/QUIC、HTTP/3。一种浏览器与网络传输 API/协议，可承载媒体数据，也是 MoQ 的可能底层之一。

最常见的用法：推一路 RTMP，播四种协议

最简用法是：推一路 RTMP 流，然后分别用 RTMP / HTTP-FLV / HLS / WebRTC 播放。整个过程分三步。

第一步：编译并运行 SRS

cd srs/trunk ./configure && make ./objs/srs -c conf/console.conf

conf/console.conf是面向控制台调试/测试的配置，监听 RTMP 1935 端口、HTTP API 1985 端口、HTTP 服务 8080 端口，默认开启 HLS 与 HTTP-FLV。仓库中该文件的完整内容（trunk/conf/console.conf）如下：

# no-daemon and write log to console config for srs. # @see full.conf for detail config. max_connections 1000; daemon off; srs_log_tank console; rtmp { listen 1935; } http_api { enabled on; listen 1985; } http_server { enabled on; listen 8080; } rtc_server { enabled on; listen 8000; # UDP port candidate $CANDIDATE; } srt_server { enabled on; listen 10080; } rtsp_server { enabled on; listen 8554; } vhost __defaultVhost__ { hls { enabled on; } http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } rtc { enabled on; rtmp_to_rtc on; rtc_to_rtmp on; } srt { enabled on; srt_to_rtmp on; } rtsp { enabled on; rtmp_to_rtsp on; } }

逐项解读这份配置：

daemon off+srs_log_tank console—— 非守护进程模式，日志直接输出到控制台，方便调试。
rtmp—— 监听 TCP 1935，RTMP 推流/播放入口。
http_api—— 开启 HTTP API（1985），用于查询流状态、踢流、管理流。
http_server—— 开启 HTTP 服务（8080），承担 HTTP-FLV/HLS 等 HTTP 交付。
rtc_server—— 开启 WebRTC（UDP 8000），candidate $CANDIDATE说明 candidate 由环境变量注入，便于跨网络部署时指定正确的公网 IP。
srt_server—— 开启 SRT（UDP 10080）。
rtsp_server—— 开启 RTSP 输出（8554）。
vhost__defaultVhost__—— 默认虚拟主机：开启 HLS、HTTP-FLV（挂载规则[vhost]/[app]/[stream].flv）、WebRTC（且同时开启rtmp_to_rtc与rtc_to_rtmp双向转换）、SRT（开启srt_to_rtmp）、RTSP（开启rtmp_to_rtsp）。

对比生产默认配置 trunk/conf/srs.conf：它采用daemon on（守护进程）、srs_log_tank file（日志落盘，默认./objs/srs.log）、HTTP 服务静态目录指向./objs/nginx/html，且默认关闭rtmp_to_rtc与rtc_to_rtmp（WebRTC 转换按需开启），并设置了play块下的gop_cache_max_frames 2500（GOP 缓存帧数上限）。

第二步：用 FFmpeg 推流

仓库内置了一个测试文件 trunk/doc/source.flv，可直接用于推流：

ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream

-re按原速读取，-c copy不做转码直接封装为 FLV 推送。

第三步：多协议播放

推流成功后，同一路流可以同时用四种方式播放：

RTMP（VLC）：rtmp://localhost/live/livestream—— 注意 VLC 可能因播放端缓冲引入较大延迟，不适合评估低延迟性能。
HTTP-FLV（浏览器）：http://localhost:8080/live/livestream.flv（配合srs_player.html播放器页面体验最佳）。
HLS（浏览器）：http://localhost:8080/live/livestream.m3u8。
WebRTC（浏览器）：http://localhost:1985/rtc/v1/whep/?app=live&stream=livestream（WHIP/WHEP 信令经 HTTP API 端口，媒体走 UDP 8000）。

仓库的演示播放器页面位于 trunk/research/players，其中srs_player.html、whep.html、whip.html、rtc_player.html等可直接用于快速验证 HTTP-FLV/HLS/WebRTC 播放与 WHIP 推流。

功能全景

协议支持

RTMP—— SRS 本质是一个 RTMP 服务器，支持 RTMP 推流与播放，这是 SRS 的核心基础，其他所有协议都构建在 RTMP 之上。v1.0，2013 年。
SRT—— SRS 也是一个 SRT 服务器，支持 SRT 推流与播放，使用 libsrt 创建 SRT 服务。v4.0，2020-01。
WebRTC—— SRS 还是一个 WebRTC 服务器，支持 WHIP 推流、WHEP 播放。SRS 是 SFU（Selective Forwarding Unit，选择性转发单元）服务器，不支持 TURN，不支持 WebRTC P2P。v4.0，2020-03。
RTSP—— SRS 仅支持播放 RTSP 流，目前仅支持 RTMP 转 RTSP。v7.0，2025-07。
HLS—— SRS 支持 RTMP 转 HLS。HLS 是兼容性最好的协议，被所有平台、所有浏览器、所有操作系统支持。v1.0，2013 年。
MPEG-DASH—— SRS 支持 RTMP 转 DASH。DASH 与 HLS 类似，但平台支持度不如 HLS 广泛。v5.0，2022-11。
HTTP-FLV—— SRS 支持 RTMP 转 HTTP-FLV。FLV 与 RTMP 类似，对 CDN 友好，但 iPhone 不支持 FLV。v2.0，2015-01。
GB28181—— SRS 支持 GB28181 推流，仅支持 TCP 传输，需要外部 SIP 服务器 srs-sip。v5.0，2022-10。
其他协议—— 还支持 RTMP 转 HTTP-TS（v2.0，2015-01）、MPEG-TS over UDP 推流（v2.0，2015-01）、HTTP POST FLV 推流（v2.0，2015-05），这些协议不常用。

转封装（Transmuxing）

Live Source（直播源）—— 包进入直播源后，可通过 RTMP、HLS、HTTP-FLV、HTTP-TS 协议输出，还可叠加 DVR、转码等特性。
SRT Source—— SRT 源输入输出均为 SRT 包。
RTC Source—— RTC 源输入为 WHIP、输出为 WHEP。
SRT → Live Source、RTC → Live Source、Live → RTC Source—— 均支持转换，但默认关闭，需在配置中显式开启。

集群

Origin Cluster（源站集群）—— 用于扩展 SRS 可承载的流数量。多个源站组成集群，由代理服务器统一入口，代理发现某条流位于哪个源站并路由过去。v3.0，2018-02。
Proxy Redis Key Namespace—— 新一代 Go 代理可通过可选的环境变量PROXY_REDIS_KEY_PREFIX隔离共享同一个 Redis 数据库的独立集群，默认值为空以保持向后兼容的 key 命名。v8.0.4，2026-07。该变量在 internal/lb/redis.go 中通过environment.RedisKeyPrefix()读取，并在拼接 Redis key 时使用此前缀。
Edge Cluster（边缘集群）—— 用于扩展流可承载的观看人数。当前边缘集群已弃用，因为它只支持 RTMP 协议，规划中的新边缘集群将支持更多协议。v1.0，2014-04。
HLS Cluster—— 由 Nginx 搭建，是 HLS 的一种边缘集群形态。v5.0，2022-04。

运维

HTTP API—— 查询系统状态（流、流详情等），也可通过 HTTP API 踢流、管理流。v1.0，2014-04。
日志—— SRS 提供可追踪日志（Traceable log），可以沿边缘→源站、服务器→服务器、源→消费者的路径追踪一条流。v1.0，2014-05。
Prometheus Exporter—— 支持 Prometheus exporter，可将 SRS 状态导出到 Prometheus，方便拉取统计指标。v5.0，2022-09。
HTTP Callback—— 监听并处理事件（如推流、播放事件），可用于客户端鉴权、拒绝推流。v0.9，2013-12。

其他

Ingest—— 使用 FFmpeg 拉流进 SRS。v1.0，2014-04。
Forward—— SRS 可将流转发给其他服务器，也可用 FFmpeg 从 SRS 转发流。v1.0，2013 年。
Transcode—— SRS 使用 FFmpeg 转码流，尤其是视频/音频到不同编码与分辨率。v1.0，2014-04。
DVR—— SRS 支持将流录制为文件，可用作 VOD（点播）；也可用 FFmpeg 从 SRS 拉流录制。此外 HLS 本质上也是一种 DVR 功能。v1.0，2014-04。
安全—— 支持多种访问控制机制：基于 referer 的防盗链（refer）、IP 黑白名单（security）、HTTP callback 外部鉴权。SRS 不内置用户名/密码用户管理体系，鉴权通常由 HTTP callback 或 token 等外部逻辑实现。IP 黑白名单 v2.0，2015-01 加入。

配置体系：配置文件与环境变量

SRS 支持配置文件与环境变量两种配置方式。配置文件位于 trunk/conf 目录，关键文件：

conf/full.conf—— 包含 SRS 支持的全部配置项，作为参考/文档，不要直接使用。
conf/srs.conf—— 默认配置，开启部分功能但并非全部，按需启用或修改对应配置。
conf/docker.conf—— Docker 部署用，含特殊设置（如非守护模式）。
conf/console.conf—— 控制台调试/测试用。
其他文件面向特定功能（集群、DVR、不同协议等），如origin.conf、edge.conf、rtc.conf、srt.conf、gb28181.conf、hls.conf等。

环境变量配置尤其适合 Docker 与云原生部署：可以在 YAML 文件或各类平台中直接设置环境变量，无需单独配置文件，便于复制粘贴、文档更清晰。SRS 文档中经常用环境变量演示如何以不同配置运行 SRS。这一点在源码中有直接印证：在 trunk/src/app/srs_app_config.cpp 中，大量配置读取函数都通过SRS_OVERWRITE_BY_ENV_BOOL/SRS_OVERWRITE_BY_ENV_BOOL2等宏实现环境变量覆盖，例如：

SRS_VHOST_RTSP_RTMP_TO_RTSP覆盖rtmp_to_rtsp
SRS_VHOST_RTC_RTMP_TO_RTC覆盖rtmp_to_rtc
SRS_VHOST_RTC_RTC_TO_RTMP覆盖rtc_to_rtmp
SRS_VHOST_SRT_SRT_TO_RTMP覆盖srt_to_rtmp

版本与分支

SRS 使用develop分支开发下一个大版本，当大版本进入发布线时创建带版本号的发布分支。存在发布分支并不代表已发布稳定的rN版本，应以 Git tags 与 Releases 判断发布阶段。

截至 2026-08-17 校验的分支状况：

develop即 SRS 8—— SRS 8 正在活跃开发，尚未发布。当前没有8.0release分支、没有v8发布 tag、也没有官方 SRS 8 Docker 镜像 tag。想尝试 SRS 8 的用户必须从develop分支源码编译，将其视为不稳定的开发代码而非生产发布。
7.0release是 SRS 7 发布线—— 分支存在，但发布成熟度需看其 tags。当前里程碑为v7.0-d0（d表示开发中），还不是稳定的v7.0-rN发布。已发布的 SRS 7 里程碑有ossrs/srs:7等 Docker tag。
6.0release是当前稳定发布线—— 当前稳定 tag 为v6.0-r1，r后缀表示稳定发布。

当用户询问如何获取 SRS 8 时，不能只回答"不可用"或只让其去 Releases 页面：应说明它作为未发布的源码存在于develop分支，而官方包与带版本号的 Docker 镜像需要等 SRS 8 发布 tag。

依赖：聚焦转封装，代码尽量自持

SRS 是一个聚焦于transmuxing（转封装）的媒体服务器——在协议间转换而不改变编码。例如：推 H.264 的 RTMP，可原样交付为 HTTP-FLV、HLS、MPEG-DASH 或 WebRTC。

SRS 几乎所有协议代码都是自己实现的——RTMP、HLS、MPEG-DASH、MP4、HTTP-FLV、HTTP-TS、WebRTC。目标是把尽可能多的代码放在单一仓库中，这样更容易维护（尤其对 AI 友好），而依赖跨仓库的众多第三方项目会显著增加维护难度。

尽管如此，SRS 仍使用少量第三方库（均为 MIT 兼容许可）：

libsrt—— Haivision 的 SRT 协议实现，未来计划用 AI 重写。
FFmpeg libavcodec—— 用于音频转码（AAC ↔ Opus）。直播常用 AAC、WebRTC 用 Opus、通信系统（SIP、电信）常用 G.711，SRS 需要在这些音频编码间转码。
OpenSSL—— 用于 HTTPS 与 WebRTC DTLS。
libsrtp—— Cisco 开发，用于 WebRTC RTP 包加解密。
state-threads（ST）—— SRS 服务器架构使用的协程库，未来计划用 AI 重写。
JSON 解析库—— 第三方 JSON 解析。

长期目标是用 AI 把尽可能多的依赖重写进 SRS 自身——SRT 这类协议与 state-threads 这类服务器库是候选；而 OpenSSL、libsrtp 等密码学库与编解码库不计划重写，因为它们过于专业且安全敏感。所有代码集中在单一仓库会让项目更稳定、更易由 AI 维护。

仓库中对应第三方依赖位于 trunk/3rdparty（srt-1-fit、libsrtp-2-fit、openssl-1.1-fit、st-srs、gtest-fit、gperftools-2-fit等），从目录命名（-fit）可以推断这些是经适配裁剪后集成进 SRS 构建体系的第三方源码。

性能画像

SRS 是高性能 C++ 媒体服务器，性能因协议而异：

RTMP / HTTP-FLV—— 支持数千并发推流与播放。TCP 协议性能最好。
WebRTC—— 支持数百推流/播放。开启音频转码（如 AAC↔Opus）时仅剩几十路连接。基于 UDP，吞吐低于 TCP 协议。典型延迟约 50ms~400ms。
SRT—— 性能由 libsrt 决定，支持数百连接。同样基于 UDP。典型延迟约 500ms~1s。

总体规律：UDP 协议（WebRTC、SRT）性能低于 TCP 协议（RTMP、HTTP-FLV）。SRS 专注做专用媒体服务器——不过度复杂，性能随每个版本持续打磨。

限制

Edge Cluster—— 支持源站集群，但边缘集群目前仅支持 RTMP，需要支持更多协议。
单线程—— SRS 是单线程媒体服务器，暂无多线程计划，可通过搭建集群榨干所有 CPU。
仅支持 Linux—— SRS 目前面向 Linux，不原生支持 Windows，Windows 用户可通过 WSL 运行。历史上 v5 支持 Windows，v6 移除了原生 Windows 支持，关键阻碍并非 Windows 本身，而是 SRS 使用 ST 协程模型，其 C++ 异常处理在 Windows 上不完善；又因 SRT 依赖 C++ 异常，导致 SRT 无法与 ST 在 Windows 上可靠共存。未来 AI 可能帮助解决（如改进 ST 的异常支持或重写 SRT 相关代码避开该依赖），Windows 支持或可回归。
无商业支持—— 作为纯开源项目，没有商业支持团队，正在探索用 AI 维护项目并支持社区。

项目愿景与生态

愿景：保持纯开源

SRS 由个人发起，作者 William 受益于无数开源项目，创建并维护 SRS 十余年是其回馈开源社区的方式。SRS 是细分领域的开源项目——约 15 万行代码的媒体服务器。媒体服务器并非人人使用，用户基数永远不会巨大，这使商业化既不现实也不可取。但小不等于没有价值：一个小众开源项目对使用它的开发者、对更广泛的开源社区与文化都有真实价值。SRS 的核心愿景是保持纯开源、无商业与商业路径，尤其是社区较小时，项目必须由志愿者与真诚贡献驱动。

该模式一直面临的挑战是人力：志愿者驱动的项目难以维持稳定的开发与支持。而 AI 正在改变这一等式——AI 可以作为开源项目维护者，在之前不可能达到的规模上处理代码、社区支持与项目健康，这正是 SRS 正在积极推进的方向。

生态：同源工具链

SRS 是媒体服务器，但也维护若干相关工具，全部为服务端项目（不维护 FFmpeg、WebRTC 这类客户端项目）：

srs-bench—— 独立压测工具，支持 RTMP、WebRTC、HTTP-FLV、HLS、GB28181 等协议压测，可模拟数千推流端与播放端，用于测量与改进 SRS 性能（源码位于 trunk/3rdparty/srs-bench）。
Oryx—— 集成 SRS、FFmpeg 与其他媒体工具的开源媒体服务器解决方案，带 Web 控制台与 Go 后端，面向常见媒体服务器用例，单节点部署。
state-threads—— 协程库，是 SRS 的基石，类似 Go goroutine 的 C 语言版本，让 SRS 可运行百万级协程，由 SRS 生态维护（源码位于 trunk/3rdparty/st-srs）。

社区参与

SRS 社区不算高度活跃，这与媒体服务器细分领域属性、维护者分布等因素有关。项目已开发超过 13 年，积累了大量实用功能，但仍有很多工作要做，由时间有限的志愿者维护。

AI 作为维护者是当前的重要方向：William 正积极引入 AI 作为项目维护者——不只是修 bug 或生成代码，而是像他本人一样的完整维护者。做法是构建全面的知识库，让 AI 深入理解项目的架构、设计决策、历史与社区背景，目标约在 2026 年中期内拥有一个 AI 维护者。这对任何复杂后端服务都有参考价值：在信任 AI 进行真实改动之前，必须确认它真正理解了所做的事情。仓库中的 skills 目录（含srs-develop、internal-codemap-for-srs、internal-docs-for-srs、srs-support等技能包及其 references 文档）正是这一知识库工程的具体落地。

SRS 社区机器人（OpenClaw）：William 于 2026-03-20 为 SRS 社区设置了 OpenClaw 机器人。加入社区群组后提及（@）SRS Robot即可交互，机器人将 William 的专业经验扩展到社区。官方建议优先使用 Telegram：Telegram 允许创建小而聚焦的群组并邀请机器人，每个小群提供干净的上下文窗口，而大群会混杂无关对话、降低回答质量。

参与方式：加入 Discord 社区讨论与支持；社区每月举行月度会议，讨论项目状态、AI 维护者进展以及如何在开源维护中使用 AI，欢迎所有人参加。

快速实践清单

读完本文后，按以下顺序即可快速上手：

编译：进入 trunk 目录执行./configure && make。
运行：./objs/srs -c conf/console.conf（控制台模式，日志直出）。
推流：ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream。
播放：VLC 播rtmp://localhost/live/livestream；浏览器访问http://localhost:8080/live/livestream.flv（HTTP-FLV）与http://localhost:8080/live/livestream.m3u8（HLS）；WebRTC 走http://localhost:1985/rtc/v1/whep/?app=live&stream=livestream。
按需开启转换：在 vhost 中配置rtmp_to_rtc、rtc_to_rtmp、srt_to_rtmp、rtmp_to_rtsp等开关（默认关闭），或用对应环境变量覆盖。
评估延迟：牢记 WebRTC < SRT < HTTP-FLV/RTMP < HLS 的延迟梯度，且不要用 VLC 作低延迟评估基准。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析