1. 流媒体服务器选型这件事为什么值得单独拿出来聊做流媒体工程这些年我被问得最多的问题不是“怎么推流”而是“到底该用哪个流媒体服务器”。这个问题看起来简单实际上牵扯的东西特别多——协议支持、并发能力、延迟表现、部署复杂度、二次开发成本、社区活跃度每一项都会直接影响你后续的运维成本和业务扩展空间。我见过太多团队在项目初期随手选了一个方案结果做到一半发现协议不兼容、延迟压不下来、或者想加个鉴权逻辑得改源码最后不得不推倒重来。这篇文章面向的是正在做流媒体服务端选型的工程师、架构师以及需要搭建直播、点播、监控回传、低延迟互动等场景的技术负责人。我会把目前主流的几款流媒体服务器拉出来做横向对比重点聊 SRS 和 MediaMTX 这两个在社区里讨论度很高的方案同时也会提到 Nginx-RTMP、ZLMediaKit 等常见选项。核心不是告诉你“哪个最好”而是帮你搞清楚“什么场景该选什么”以及选型时那些文档里不会写的坑。选型这件事没有银弹。一个在秀场直播场景跑得很稳的方案放到安防监控的低延迟回传场景里可能完全不适用。所以我会从实际业务需求出发拆解每个方案的设计取向和适用边界让你能根据自己的场景做出判断而不是盲目跟风。2. 先搞清楚你的业务到底需要什么协议组合2.1 推流协议与拉流协议不是一回事很多人选型时容易犯一个错误把推流协议和拉流协议混为一谈。实际上这是两个完全独立的维度。推流端决定了你的主播、摄像头、编码器用什么协议把数据送上来拉流端决定了你的观众、播放器、下游系统用什么协议把数据取走。一个流媒体服务器可能推流只支持 RTMP但拉流支持 RTMP、HTTP-FLV、HLS、WebRTC 多种方式这种组合在很多场景下是完全够用的。所以选型的第一步是把你业务链路两端的协议需求列清楚。推流端如果是 OBS、FFmpeg 这类工具RTMP 和 SRT 是最常见的选择如果是浏览器直接推流那 WebRTC 或者基于 WebSocket 的方案就更合适。拉流端如果面向的是 Web 浏览器HTTP-FLV 和 HLS 是主流如果面向的是移动端 AppRTMP 和 HTTP-FLV 延迟更低如果要做视频会议或者连麦互动WebRTC 几乎是唯一选择。2.2 延迟指标要拆开看别只看一个数延迟是选型时被提及最多的指标但很多人对延迟的理解过于笼统。你需要把延迟拆成几个部分编码延迟、网络传输延迟、服务器转发延迟、播放器缓冲延迟。流媒体服务器能控制的主要是转发延迟和它对播放器缓冲策略的影响。RTMP 和 HTTP-FLV 在服务器转发层面的延迟通常在 1-3 秒HLS 因为切片机制天然会有 5-30 秒的延迟取决于切片时长和播放列表长度WebRTC 可以做到 200-500 毫秒甚至更低。但这里有个关键点服务器本身的转发延迟只是整个链路的一小部分播放器的缓冲策略往往才是延迟的大头。所以选型时不要只盯着服务器标称的延迟数字要结合你的播放端一起评估。2.3 并发模型决定了服务器的天花板流媒体服务器的并发能力取决于它的网络模型。常见的模型有这几种单线程事件循环如 MediaMTX 基于 Go 的 goroutine 模型、多线程/多进程如 Nginx-RTMP 基于 Nginx 的 worker 模型、协程模型如 SRS 基于 ST 协程库。不同的模型在连接数、CPU 利用率、内存占用上的表现差异很大。我实测下来的经验是MediaMTX 在中小规模并发下资源占用非常低部署也简单但超大规模并发时的调优空间相对有限SRS 在大规模并发场景下经过了很多生产环境的验证支持集群部署和边缘回源但配置复杂度更高。如果你的业务预期是几百路以内的并发两者都能胜任如果预期是几千路甚至上万路那就要重点考察集群能力和边缘分发方案了。3. SRS 和 MediaMTX 的核心差异到底在哪3.1 SRS 的设计取向功能全面面向生产级直播SRSSimple Realtime Server是国内社区非常活跃的一个流媒体服务器项目它的定位很明确面向直播场景的生产级服务器。它支持的协议非常全推流支持 RTMP、SRT、WebRTC、GB28181拉流支持 RTMP、HTTP-FLV、HLS、WebRTC、DASH 等。功能上支持转码、录制、转发、鉴权、集群、边缘回源、DVR 等基本上你能想到的直播相关功能它都有。SRS 的架构设计考虑了大规模部署的需求。它支持 Origin 和 Edge 两种角色Origin 负责接收推流Edge 负责就近分发通过这种层级结构可以支撑很大的并发规模。它的配置文件是类似 Nginx 的 conf 格式上手需要一点时间但配置项非常丰富能精细控制各种行为。不过 SRS 的复杂度也是它的门槛。我第一次部署 SRS 的时候光是搞清楚各个配置段的作用就花了不少时间。而且它的版本迭代比较快不同版本之间的配置项和行为可能有变化升级时需要仔细看变更说明。3.2 MediaMTX 的设计取向轻量、简单、多协议互通MediaMTX原名 rtsp-simple-server是另一个极端。它的设计哲学是“简单好用”整个服务器就是一个二进制文件下载下来改几行配置就能跑。它支持的协议包括 RTSP、RTMP、HLS、WebRTC、SRT特别适合需要多协议互通的场景——比如你有一个 RTSP 摄像头想同时用 RTMP 和 HLS 分发出去MediaMTX 可以自动帮你做协议转换。MediaMTX 用 Go 语言编写天然支持跨平台Linux、Windows、macOS 都能跑Docker 镜像也很小。它的配置是 YAML 格式可读性很好基本上看一遍就能明白每个配置项的作用。对于中小规模的场景比如几十路摄像头的监控回传、小型的直播分发MediaMTX 的部署和维护成本非常低。但 MediaMTX 的短板也很明显它没有内置的集群方案大规模并发时需要自己想办法做负载均衡功能上也没有 SRS 那么丰富比如转码、录制这些功能相对基础。所以它更适合作为“协议网关”或者中小规模的分发节点来用。3.3 一张表看清两者的关键差异对比维度SRSMediaMTX开发语言CGo推流协议RTMP、SRT、WebRTC、GB28181RTSP、RTMP、WebRTC、SRT拉流协议RTMP、HTTP-FLV、HLS、WebRTC、DASHRTSP、RTMP、HLS、WebRTC集群支持原生支持 Origin/Edge 集群无原生集群需自行负载均衡配置格式类 Nginx confYAML部署复杂度中等偏高极低资源占用中等低转码/录制支持功能丰富基础支持适用规模中大规模直播中小规模、协议网关社区活跃度高国内为主高国际为主这张表只是帮你快速建立印象实际选型时还要结合你的具体场景。比如你如果只是想把几路 RTSP 摄像头转成 HLS 给网页播放MediaMTX 几乎是零成本的选择但如果你要做一个支持上千路并发、需要录制和鉴权的直播平台SRS 的完整功能集和集群能力就更合适。4. 部署实操从零跑通 SRS 和 MediaMTX4.1 用 Docker 部署 MediaMTX 的最短路径MediaMTX 的部署简单到有点不真实。你只需要一个配置文件加一条 Docker 命令就能跑起来。先创建一个mediamtx.yml配置文件最小配置可以只有几行# mediamtx.yml 最小配置示例 rtsp: yes rtmp: yes hls: yes webrtc: yes paths: all: # 允许所有路径不需要预先定义然后一条命令启动docker run --rm -it \ -p 8554:8554 \ -p 1935:1935 \ -p 8888:8888 \ -p 8889:8889 \ -v $(pwd)/mediamtx.yml:/mediamtx.yml \ bluenviron/mediamtx:latest这里几个端口分别对应8554 是 RTSP1935 是 RTMP8888 是 HLS8889 是 WebRTC。启动之后你可以用 FFmpeg 推一路 RTSP 流进去测试ffmpeg -re -stream_loop -1 -i test.mp4 \ -c copy -f rtsp rtsp://localhost:8554/mystream然后用浏览器打开http://localhost:8888/mystream就能看到 HLS 播放列表或者用 VLC 打开rtsp://localhost:8554/mystream直接播放 RTSP。整个过程不到五分钟。注意MediaMTX 默认的 WebRTC 需要 HTTPS 才能在某些浏览器上正常工作本地测试时可以用 localhost 绕过但生产环境一定要配好证书。4.2 SRS 的 Docker 部署与关键配置解读SRS 的 Docker 部署也不复杂但配置文件需要多花点心思。官方提供了 Docker 镜像你可以直接拉取docker run --rm -it \ -p 1935:1935 \ -p 1985:1985 \ -p 8080:8080 \ -v $(pwd)/srs.conf:/usr/local/srs/conf/srs.conf \ ossrs/srs:5SRS 的配置文件是 conf 格式一个支持 RTMP 推流、HTTP-FLV 和 HLS 拉流的最小配置大概长这样# srs.conf 最小配置示例 listen 1935; max_connections 1000; daemon off; srs_log_tank console; http_server { enabled on; listen 8080; dir ./objs/nginx/html; } http_api { enabled on; listen 1985; } vhost __defaultVhost__ { http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } hls { enabled on; hls_path ./objs/nginx/html; hls_fragment 10; hls_window 60; } }这个配置里几个关键点http_remux开启了 HTTP-FLV 输出hls段配置了 HLS 切片hls_fragment是切片时长秒hls_window是播放列表窗口大小。这两个参数直接决定了 HLS 的延迟和抗抖动能力——切片越短延迟越低但切片数量越多播放列表更新越频繁窗口越大抗抖动越好但延迟也会增加。推流测试和 MediaMTX 类似ffmpeg -re -stream_loop -1 -i test.mp4 \ -c copy -f flv rtmp://localhost/live/mystream拉流地址分别是HTTP-FLV 用http://localhost:8080/live/mystream.flvHLS 用http://localhost:8080/live/mystream.m3u8。4.3 部署时最容易忽略的三个细节第一个细节是端口冲突。SRS 默认用 1935RTMP、1985API、8080HTTPMediaMTX 默认用 8554RTSP、1935RTMP、8888HLS、8889WebRTC。如果你在同一台机器上同时跑两个服务1935 端口会冲突需要改其中一个的配置。第二个细节是文件描述符限制。流媒体服务器每个连接都会占用一个文件描述符默认的 1024 在高并发下很快就不够用了。部署前一定要检查ulimit -n建议调到 65535 以上。Docker 部署时可以通过--ulimit nofile65535:65535参数设置。第三个细节是日志级别。SRS 和 MediaMTX 默认的日志级别在调试时很有用但生产环境如果保持 debug 级别日志文件会迅速膨胀甚至拖慢服务。上线前记得把日志级别调到 info 或 warn。5. 性能实测并发、延迟与资源占用5.1 测试环境与测试方法说明为了给出有参考价值的对比数据我在一台 4 核 8G 的云服务器上做了几组测试。测试内容是用 FFmpeg 模拟多路推流然后用播放器拉流观察 CPU、内存占用和延迟表现。需要说明的是这个测试规模有限数据只能反映趋势不能替代你实际业务场景下的压测。测试方法用脚本启动 N 个 FFmpeg 进程每个进程循环推一路 720p 的测试视频到服务器然后用 FFprobe 或者播放器测量端到端延迟。并发数从 10 路逐步增加到 100 路记录每个阶段的资源占用。5.2 不同并发下的资源占用对比并发路数SRS CPU 占用SRS 内存占用MediaMTX CPU 占用MediaMTX 内存占用10 路约 8%约 120MB约 5%约 60MB30 路约 20%约 180MB约 12%约 90MB50 路约 35%约 250MB约 20%约 130MB100 路约 65%约 400MB约 38%约 220MB从数据上看MediaMTX 在资源占用上确实有优势这跟 Go 的运行时特性和它更轻量的架构有关。SRS 因为功能更多、内部结构更复杂资源占用相对高一些但也在合理范围内。需要注意的是这个测试没有开启转码和录制如果开启这些功能SRS 的资源占用会明显上升而 MediaMTX 的转码能力相对有限。5.3 延迟表现的实测数据与影响因素延迟方面我用同一路 720p 流分别通过 RTMP、HTTP-FLV、HLS、WebRTC 拉流测量从推流端到播放端的端到端延迟。测试结果大致如下RTMP 拉流约 1.5-2.5 秒HTTP-FLV 拉流约 1-2 秒HLS10 秒切片约 15-25 秒WebRTC 拉流约 300-800 毫秒这些数字跟服务器本身的关系其实没有想象中那么大更多取决于播放器的缓冲策略。比如 HLS 的延迟主要来自切片时长和播放器预缓冲的切片数量服务器能控制的就是切片时长。WebRTC 的低延迟则是因为它用了 UDP 传输和更激进的缓冲策略。实操心得如果你对延迟敏感优先考虑 WebRTC 或 HTTP-FLVHLS 只适合对延迟不敏感的场景。另外播放器的缓冲参数往往比服务器配置更能影响最终延迟调优时不要只盯着服务端。6. 选型决策什么场景该选什么6.1 监控摄像头回传与多协议互通场景如果你面对的是安防监控场景摄像头输出 RTSP 流需要同时给 Web 端、移动端、录像系统分发那 MediaMTX 几乎是首选。它原生支持 RTSP 推流能自动把 RTSP 转成 RTMP、HLS、WebRTC 等多种格式配置简单资源占用低。一个中等规模的监控项目几十路摄像头用 MediaMTX 加一个 Docker 就能搞定维护成本极低。这个场景下 SRS 也能做但它的 RTSP 支持是通过 GB28181 或者 RTSP 推流模块实现的配置相对复杂而且对于纯 RTSP 转发的场景来说有点杀鸡用牛刀。6.2 大规模直播与需要集群分发的场景如果你要做的是秀场直播、电商直播、在线教育这类场景预期并发规模较大需要录制、鉴权、转码、边缘分发等功能那 SRS 是更合适的选择。它的 Origin/Edge 集群架构可以支撑很大的并发规模功能集也更完整。国内很多直播平台的生产环境都在用 SRS社区里能找到大量的实践案例和调优经验。MediaMTX 在这个场景下就显得力不从心了它没有原生的集群方案大规模并发时需要自己在前面加负载均衡而且缺少录制、鉴权等高级功能很多需求需要自己二次开发。6.3 低延迟互动与 WebRTC 优先的场景如果你的业务核心是低延迟互动比如视频会议、连麦、远程操控那 WebRTC 是必须的。SRS 和 MediaMTX 都支持 WebRTC但 SRS 的 WebRTC 功能更完整支持 WHIP/WHEP 协议能更好地跟现有的 WebRTC 生态集成。MediaMTX 的 WebRTC 支持也在不断完善对于简单的低延迟分发场景够用但复杂的互动场景还是 SRS 更稳妥。6.4 快速验证与边缘节点的轻量选择如果你只是想快速验证一个想法或者需要在边缘节点部署一个轻量的分发服务MediaMTX 的单二进制、零依赖特性非常有优势。你可以把它塞进一个很小的容器里资源占用低启动速度快非常适合边缘计算场景。SRS 虽然也能容器化部署但镜像体积和启动时间都更大一些。7. 那些文档里不会写的踩坑经验7.1 配置文件改了没生效先检查加载顺序SRS 和 MediaMTX 都支持配置文件的包含和覆盖机制但两者的行为不一样。SRS 的配置文件如果有多层 include后面的配置会覆盖前面的MediaMTX 的 YAML 配置则是深度合并。我踩过一次坑在 MediaMTX 里想覆盖某个 path 的配置结果发现全局配置和 path 配置的合并逻辑跟我想的不一样调了半天才发现是配置层级的问题。建议的做法是改完配置后先用服务自带的配置检查功能验证一下SRS 有-t参数做配置测试或者启动后看日志里打印的最终生效配置确认跟你预期的一致。7.2 推流成功但拉流失败八成是路径匹配问题流媒体服务器里的“路径”path 或 stream name是个容易出问题的地方。SRS 里叫 vhost app streamMediaMTX 里叫 path。推流和拉流时的路径必须完全匹配包括大小写。我有一次推流到rtmp://server/live/Stream1拉流时写成rtmp://server/live/stream1结果死活拉不到流查了半天才发现是大小写问题。另外MediaMTX 的paths配置支持正则匹配如果你用了all或者正则要确认匹配规则是否符合预期。SRS 的 vhost 配置也有类似的匹配逻辑配置复杂时建议先用最简单的配置跑通再逐步加功能。7.3 高并发下的连接数限制与内核参数调优前面提到过文件描述符限制但除此之外还有几个内核参数会影响高并发表现。比如net.core.somaxconn控制监听队列长度net.ipv4.tcp_max_syn_backlog控制 SYN 队列长度这些参数在默认值下可能成为瓶颈。建议在生产环境部署前根据预期的并发规模调整这些参数。SRS 的配置文件里有max_connections参数MediaMTX 没有类似的全局限制但可以通过系统层面的限制来控制。两者都需要注意连接数不是越高越好超过系统承载能力后服务质量会急剧下降合理设置上限并配合监控才是正道。7.4 日志排查从推流到拉流的完整链路追踪流媒体问题排查最头疼的是链路长推流端、服务器、拉流端任何一环出问题都会导致播放失败。我的经验是先在服务器端确认流是否推上来了SRS 可以通过 HTTP API 查询MediaMTX 可以看日志然后再确认拉流端是否能正确解析播放列表或流地址。SRS 的 HTTP API 提供了丰富的流信息查询接口MediaMTX 的日志则会打印每个连接的详细信息。如果推流成功但拉流失败重点检查路径是否匹配、协议是否支持、防火墙是否放行、播放器是否兼容。如果推流本身就失败重点检查推流地址格式、编码格式是否被支持、网络是否可达。8. 写在最后的一点个人体会流媒体服务器选型这件事我的核心建议是先用最小成本跑通你的核心链路再根据实际瓶颈做优化和替换。不要一上来就追求“最强方案”因为最强的往往也是最复杂的而复杂度本身就是一种成本。MediaMTX 适合快速起步和轻量场景SRS 适合功能全面和生产级大规模部署两者并不是非此即彼的关系很多架构里会同时用到——比如用 MediaMTX 做边缘协议转换用 SRS 做中心集群分发。另外流媒体这个领域变化很快新的协议和方案不断出现选型时除了看当前的功能对比也要关注项目的社区活跃度和迭代节奏。一个活跃的社区意味着你遇到问题时更容易找到答案也意味着项目更有可能持续演进。SRS 和 MediaMTX 在这方面都表现不错这也是它们值得被纳入候选清单的重要原因。