企业官网建设流程全解析

做直播、做监控、做视频点播，说到底绕不开“视频流服务器”这个中间层。我这些年帮团队和客户搭过不少流媒体环境，结论很直接：商业产品能干的活儿，目前主流、免费且开源的视频流服务器几乎都能干，定制空间反而更大，出了问题还能直接看源码定位，不用干等厂商售后。这篇文章把我实际部署过的 SRS、Nginx-RTMP、MediaMTX、ZLMediaKit 这四个项目掰开讲清楚，覆盖协议选型、部署过程、延迟优化和常见故障排查。

适合刚接触流媒体、想给内部系统加直播能力，或者想把监控摄像头画面接到 Web 端和手机端的开发者；也适合已经跑通一套服务、但被延迟和兼容性问题反复折磨的老手。读完你至少能回答三个问题：不同场景该选哪个开源项目；RTMP、HLS、WebRTC 这些协议到底怎么取舍；服务部署上去之后出了问题该从哪里下手查。我尽量不堆名词，每个概念都用实际场景说明白。

1. 主流开源方案的横向对比与选型思路

1.1 先搞清楚“视频流服务器”到底解决什么问题

很多人第一次接触流媒体，容易被一堆协议名字绕晕，其实核心链路非常简单：一端把视频数据推上来，服务端做接收、存储、转码（也可以不转码）和分发，另一端的播放器从服务端拉流播放。视频流服务器就是中间那个承上启下的角色。

它要解决的痛点有三个。第一个是兼容性：推流端可能是 OBS、摄像头、手机 App，播放端可能是浏览器、VLC、小程序，服务端必须把不同来源、不同协议的视频统一管理起来，再按播放端能接受的方式发出去。第二个是延迟和卡顿控制：直播场景要求低延迟，点播场景要求流畅拖动，同一个服务往往要同时满足。第三个是并发稳定性：人数一多，带宽、内存、文件句柄都会成为瓶颈，能不能扛住，直接决定项目口碑。

带着这三个痛点去看开源项目，就不会被“功能越多越好”带偏。实际选型时先问自己三个问题：视频源是什么（摄像头还是软件推流）？播放端主要是什么（浏览器、App 还是电视）？对延迟的容忍度是多高（几秒还是几百毫秒）？答案不同，选型结果完全不同。这也是我下面反复强调的主线。

1.2 四个主流开源项目的定位差异

我实际部署过的开源视频流服务器主要有四个，各有各的脾气。先看一张对比表，后面再逐个展开。

SRS 可以说是目前开源直播服务器里综合能力最均衡的一个，文档齐全、社区活跃，单机就能支撑几千路并发，适合做产品级服务。Nginx-RTMP 严格说不是一个独立服务器，而是 Nginx 的一个模块，胜在轻量，适合快速验证和小规模使用，但它已经很久没有大版本更新了，别指望它帮你处理太复杂的业务。MediaMTX 前身叫 rtsp-simple-server，名字起得特别实在，它把 HTTP、RTSP、WebRTC、HLS 这些协议之间的转换做得非常顺手，我用它接过大量海康、大华摄像头的 RTSP 流，再以 WebRTC 方式推到浏览器里，延迟低到几乎无感。ZLMediaKit 则是偏底层的重型选手，安防领域大量项目用它对接 GB28181 国标设备，如果你要自己写流媒体中间件，它是很好的底座，但二次开发成本也确实高。

选型没有标准答案，只有“合不合适”。小团队内部直播，Nginx-RTMP 就够；做产品面向客户，优先 SRS；监控类项目，绕不开 ZLMediaKit 和 MediaMTX。

2. 核心协议拆解：选错协议等于埋雷

2.1 RTMP、HLS、HTTP-FLV、WebRTC、SRT 各自的定位

很多新手把“视频流服务器”和“RTMP”划等号，这是最常见的误解。协议只是服务端对外提供的接口，项目支持哪些协议、你选哪种接入方式，直接决定播放延迟、兼容范围和部署复杂度。

RTMP 是 Adobe 当年为 Flash 直播设计的 TCP 协议，现在 Flash 已经没了，但 RTMP 作为“推流入口”依然活得好好的。OBS、FFmpeg、大部分编码器都原生支持 RTMP 推流，延迟在 2 到 5 秒之间。它的优点是非常成熟、穿透性好，缺点是播放端没法直接播放，必须由服务端转成其他格式再分发。

HLS 是苹果推的 HTTP 分片方案。服务端把视频切成一个个几秒钟的小文件，再用 m3u8 索引文件告诉播放器按顺序拉取。它的兼容性天下无敌，浏览器、iOS、Android、各种播放器全都认识 m3u8，但代价是延迟高，通常 5 到 15 秒，切得越细延迟越低，文件数也越多。

HTTP-FLV 算是国内直播圈的特产。它把 FLV 封装的数据包通过 HTTP 流式下发，浏览器端用 flv.js 就能播放。延迟和 RTMP 差不多，大概 2 到 5 秒，但兼容性不如 HLS。它的最大好处是方便做 CDN 分发，因为走的是普通 HTTP。

WebRTC 是低延迟场景的终极大招。它基于 UDP，建立了音视频传输的完整链路，端到端延迟能压到 500 毫秒以内，适合连麦、教育、远程操控这类互动场景。缺点是技术栈偏前端，服务端配置稍复杂，对网络质量要求也更高。

SRT 则是为弱网环境设计的可靠传输协议，在丢包严重的公网上依然能保持画面不花屏，适合跨地域推流、卫星传输这类场景。我自己用 SRT 从外地稳定推流回中心机房的经历里，同等网络条件下确实比 RTMP 稳得多。

2.2 实际项目中协议怎么排布

实操里我不会只依赖一种协议，而是按“推流端、服务端、播放端”三段来做协议编排。推流端优先用 RTMP 或 SRT，服务端统一接收后，由流媒体服务器自动转出 HLS 和 HTTP-FLV 给普通播放端；如果业务对延迟有硬性要求，再单独开一路 WebRTC 出口。

这里有个概念需要澄清：服务端做的是“协议转换”，不是“转码”。协议转换只改封装格式，不重新编码画面，CPU 压力很小；转码则是把 H.264 转成 H.265 或调整分辨率，非常吃 CPU。很多小项目一上来就开转码，机器瞬间被打满，其实大部分场景下协议转换就够了。

如果播放端要覆盖微信小程序，那基本只能靠 HLS，因为小程序的 video 组件对 HTTP-FLV 和 RTMP 支持都很差。如果播放端是自己的 App，那可以优先考虑 HTTP-FLV，因为它实现简单、延迟适中。如果是 Web 端的实时监控画面，直接走 WebRTC，用户体验完全不在一个档次。

3. 从零部署三个开源视频流服务器

3.1 SRS：直播场景的一站式方案

SRS 安装非常省心，官方提供了 Docker 镜像，一条命令就能把包含 RTMP、HLS、HTTP-FLV、WebRTC 的完整服务跑起来：

docker run -d --name srs \ -p 1935:1935 \ -p 8080:8080 \ -p 1985:1985 \ -p 8000:8000/udp \ ossrs/srs:5

端口含义要记牢：1935 是 RTMP 和 SRT 的入口，8080 是 HTTP 服务端口，提供 HLS 和 HTTP-FLV 播放，1985 是 HTTP API 端口，8000 是 WebRTC 的 UDP 端口。忘了开 8000 的 UDP，WebRTC 就绝对连不上，这个坑我踩过不止一次。

推流命令用 FFmpeg 就能测：

ffmpeg -re -i input.mp4 \ -c:v libx264 -preset veryfast -tune zerolatency \ -c:a aac -f flv rtmp://192.168.1.100:1935/live/stream1

播放验证也很简单。HLS 地址是http://192.168.1.100:8080/live/stream1.m3u8，HTTP-FLV 地址是http://192.168.1.100:8080/live/stream1.flv，浏览器装个 flv.js 或直接用 VLC 打开即可。SRS 还自带了一个默认的播放器页面，访问http://192.168.1.100:8080/players/就能看到，这对我做项目演示帮助很大。

如果需要自定义，SRS 的配置文件是/usr/local/srs/conf/srs.conf（容器内路径）。我常用的几个关键配置项如下：

listen 1935; max_connections 1000; srs_log_tank console; vhost __defaultVhost__ { hls { enabled on; hls_path /data/hls; hls_fragment 2; hls_window 10; } http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } rtc { enabled on; rtc_port 8000; } }

hls_fragment 2表示每个 TS 切片 2 秒，hls_window 10表示播放列表里保留最近 10 秒的切片。这两个值直接影响 HLS 延迟和回看长度，想要更低延迟就把 fragment 调到 1，但文件数会翻倍，要注意磁盘压力。SRS 的优势之一就是这些参数都有中文注释，对国内开发者极其友好。

3.2 Nginx-RTMP：轻量改造派的首选

如果你的服务器上已经跑着 Nginx，那加一个 RTMP 模块可能是成本最低的方案。以 Debian/Ubuntu 为例，直接装模块即可：

apt install nginx libnginx-mod-rtmp

然后在/etc/nginx/nginx.conf末尾追加一段配置：

rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; hls on; hls_path /var/www/hls; hls_fragment 2s; hls_playlist_length 6s; } } } http { server { listen 8080; location /hls { types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; } alias /var/www/hls; add_header Cache-Control no-cache; } } }

这段配置有两个关键点。第一，application live是推流路径中的应用名，推流地址里的“live”必须和它一致，否则会被拒绝。第二，HLS 切片默认写到/var/www/hls，必须确保目录存在且有写权限，否则服务起来之后切片生成失败，播放端永远拉不到 m3u8。

配置完执行nginx -t检查语法，再systemctl reload nginx重载。然后同样用 FFmpeg 推流，HLS 地址就是http://服务器IP:8080/hls/stream1.m3u8。整个部署过程十分钟内能搞定，特别适合先验证业务可行性。

不过要提醒一句：Nginx-RTMP 项目维护节奏偏慢，对 HTTP-FLV 和 WebRTC 的支持很弱，如果业务刚起步可以拿它速成，做正式产品还是建议换 SRS 这类持续迭代的项目。

3.3 MediaMTX：把 RTSP 摄像头接入 WebRTC 的桥

安防场景最常见的需求是：拉取摄像头的 RTSP 流，然后让用户在网页或手机 App 上实时观看。方案很多，但 MediaMTX 是我用过配置最轻、最不折腾的。

到 GitHub Releases 页下载对应平台的二进制，解压后目录里只有一个可执行文件和一份mediamtx.yml。默认配置就能跑，默认 RTSP 端口是 8554，WebRTC 和 HLS 也都现成可用。启动命令就一句：

./mediamtx

默认情况下访问rtsp://服务器IP:8554/摄像头名会提示找不到流，因为 MediaMTX 需要主动从上游拉流。在配置文件中加一段：

paths: cam1: source: rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101

这里的source指向摄像头自身的 RTSP 地址，cam1是对外暴露的流名称。改完重启，就会得到三个可用的播放地址。HLS 是http://服务器IP:8888/cam1/index.m3u8，WebRTC 播放地址是http://服务器IP:8888/cam1/webrtc，RTSP 回源地址是rtsp://服务器IP:8554/cam1。

我最常用的是 WebRTC 方式。在浏览器里用官方提供的 webrtc 播放器样例，打开http://服务器IP:8888/cam1/webrtc这个地址对应的播放页面，延迟基本在 0.5 秒以内，画面拖动感很轻微。这在看门禁、看车间、看工地场景里体验非常关键，比 HLS 那种至少 5 秒的延迟强太多。

MediaMTX 还支持把整路流转封装后交给其他服务器，比如用runOnDemand配合 FFmpeg 转推给 SRS，组合起来可以搭出一套“摄像头 → MediaMTX → SRS → 全网分发”的完整链路。这种模块化组合是开源方案最大的优势，每个环节选最擅长的组件。

4. 常见坑位与排查实录

4.1 延迟高的问题三板斧

延迟高是流媒体项目里被问得最多的问题。排查顺序我建议固定下来：先看播放端协议，再看服务端切片参数，最后看推流端的编码参数。

第一板斧是确认播放端用的协议。如果播放端走的是 HLS，3 到 6 秒延迟是正常现象，觉得受不了就换成 HTTP-FLV 或 WebRTC。经常有人一边用 HLS 一边抱怨延迟两秒，这属于拿着锤子找钉子，问题不在服务端。

第二板斧是检查服务端的切片时长。HLS 延迟大致等于“切片时长 × 2”再加上播放器的缓冲。把hls_fragment从 5 秒改成 2 秒，延迟立刻能降下来好几秒。SRS 和 Nginx-RTMP 都支持运行时修改，改完重载即可生效，不用重启。

第三板斧是推流端的 GOP 设置。GOP 是 H.264 编码里的关键帧间隔，它同时影响延迟和兼容性。常见播放器在关键帧到达之前都不会出画面，所以编码器参数里要加-g 60（每 2 秒一个关键帧）和-tune zerolatency（零延迟编码预设）。这两个参数在 FFmpeg 推流命令行里加上，效果立竿见影。

4.2 播放白屏、无法启动、鉴权失败的处理

白屏和无法启动是最让新手崩溃的两类问题，其实多数时候原因很简单。播放白屏先打开浏览器开发者工具看 Network 面板，HLS 播放时如果 m3u8 请求被 CORS 拦截，报错信息会非常明显。解决办法是给服务端加上Access-Control-Allow-Origin: *响应头，Nginx 里加一行add_header即可。

服务起不来的情况，八成是端口被占用或配置语法错误。Nginx 用nginx -t检查配置，SRS 启动日志里会明确打印监听失败的原因。我遇到过最隐蔽的问题是把两个项目都配置成监听 1935 端口，服务轮番崩溃，排查半天才发现是部署脚本里把 SRS 和 Nginx-RTMP 同时启了。

鉴权失败则要从两个层面看。流媒体服务器自身的鉴权，比如 SRS 的http_hooks回调，配置不对会直接拒绝推流；业务层的鉴权，比如播放地址带 token 参数，一般是签名过期或时间戳不一致。我建议调试阶段先关掉鉴权，确认链路通了再加回，否则叠加在一起很难定位。

4.3 上线前必须做好的几件事

项目能跑通和能上线是两码事，我吃过亏，所以列几条经验。第一，所有对外服务必须走 HTTPS。浏览器里调用 getUserMedia 和 WebRTC 都要求安全上下文，HTTP 环境下功能会被浏览器直接禁用，这条不满足，Web 端实时播放就是空谈。用 Nginx 做反向代理加证书是最常见的做法。

第二，WebRTC 涉及 UDP 端口，很多云服务器的安全组默认不放行 UDP。部署后一定要在安全组和系统防火墙两层都确认 UDP 8000 端口可用。我见过防火墙文档写的是“放行 TCP”，结果 UDP 被拦，WebRTC 怎么都连不上。

第三，视频内容是 7×24 小时写入，磁盘会持续增长，HLS 切片目录必须配置定期清理策略。SRS 的hls_window会自动删除过期切片，但如果自己拿 Nginx-RTMP 做 HLS，就需要写一个 crontab 清理脚本，否则半年后磁盘满了才被发现，整个服务直接写不进去。

第四，日志和监控要提前接入。SRS 提供 HTTP API 可以查询在线连接数，MediaMTX 也有日志输出，把这些接入已有的监控系统，比事后翻日志高效得多。

5. 我的选型经验与后续扩展建议

5.1 按团队能力和项目周期选技术栈

选型这件事，我现在的判断依据非常简单：团队里有几个人能看懂源码、项目周期有多长、客户会不会要求二次开发。如果只是给公司内部做一个直播工具，人数不超过百人，Nginx-RTMP 或者 MediaMTX 足够，别为了“专业”上一个自己驾驭不了的平台。如果你在做一个对外交付的产品，直接选 SRS，它的生态和社区让后续招人、查文档、抄配置都有保障。安防类项目没有商量余地，ZLMediaKit 加相关的 GB28181 网关是绕不开的路线，选它就要做好啃 C++ 源码和协议规范的心理准备。

这套判断标准帮我在不少项目里避免了“过度选型”。有个客户原本坚持要上“某商业流媒体平台”，我核算完并发和延迟需求后，直接用一个 SRS 实例解决，半年省下十几万授权费，客户自己后来还在内部推广了这套方案。开源项目真正的价值不只是免费，而是你手里始终握着掌控权。

5.2 预留扩展口子，别把架构做成死胡同

最后一个建议给所有准备动手的人：先想清楚半年后可能增加什么需求，再决定今天的部署方式。常见扩展方向有这么几个：一是鉴权系统，SRS 和 MediaMTX 都支持对接外部 HTTP API 做推拉流鉴权，建议一开始就把回调地址约定好，别等上线了再补。二是多服务器分发，单机扛不住的时候，要么加 CDN，要么用 SRS Origin + Edge 集群模式，这个架构最好在第一次部署时就留出域名和端口规划。三是录制回放，推流的同时录制 FLV 或 MP4，对直播内容留存几乎是刚需。

我自己踩过最深的坑就是一开始只图快，把所有流都推到一台裸 Nginx-RTMP 上，后来业务量上来，想加录制、想加鉴权、想加集群，全都得推倒重来。后来换了 SRS，这些能力本来就是内置的，只是改配置的问题。如果你面前只有一条路走到黑的可能，那不如先花半天时间把 SRS 这类功能完整的项目跑起来，而不是从一路轻量方案里慢慢拆东墙补西墙。

视频流服务器这个领域，开源项目的成熟度已经远超很多人的预期。从几百人的内部直播到上万路的安防监控，都有对应的免费方案能抗住。希望这篇基于实际部署经验的梳理，能让你在面对一堆协议、框架和端口号的时候，少走几段弯路。