开源流媒体服务器选型与实战：SRS、ZLMediaKit、MediaMTX对比

做流媒体开发这几年，我几乎把市面上的开源方案摸了个遍。如果你正打算给项目加直播、监控上云、在线课堂或者低延迟互动能力，又不想一上来就买商业CDN产品，那开源流媒体这条路线绝对值得认真看。今天不聊虚的，结合我自己实际部署过、踩过坑、现在还跑在生产环境的方案，围绕 SRS、ZLMediaKit、MediaMTX 这几个主流开源项目，把整个链路从选型到落地完整梳理一遍，顺便把 RTSP、RTMP、HLS、HTTP-FLV、WebRTC 这些协议在什么场景该用哪个讲清楚。

1. 开源流媒体生态全景：为什么值得把精力押在这里

1.1 从闭源黑盒到开源可选：流媒体不再是巨头的专利

早些年提到流媒体服务器，大家第一反应是商业方案或者大厂自研。中小企业想搞直播，要么买云厂商的标准化产品，要么直接走高额定制路线，成本高，灵活性还差。但最近几年开源流媒体服务器的成熟度已经高到可以挑大梁了，尤其在国内社区里，SRS 和 ZLMediaKit 这两个项目几乎成了自建流媒体的事实标准。它们不是玩具，是真的能支撑几万路并发、稳定跑几个月的生产级系统。

为什么开源流媒体能这么快追上商业产品？核心在于两点：一是音视频协议栈本身已经标准化，RTMP、HLS、HTTP-FLV、WebRTC 这些协议都有公开规范，给了开源项目明确的实现目标；二是社区贡献者足够多，FFmpeg、OBS Studio、VLC 这些老牌开源项目已经把推流端、播放端的用户习惯培养起来了，服务器端顺势补位，自然就水到渠成。

1.2 开源流媒体到底能做什么：直播、监控、课堂、连麦全覆盖

我在实际项目中用开源流媒体解决过的场景大概有四类。

第一类是传统直播业务。游戏直播、活动直播、企业内部培训直播，用 SRS 做直播源站，推流端用 OBS Studio，播放端走 HLS 或者 HTTP-FLV，加上一个简单的 Web 管理后台，一套完整直播系统就起来了。这套方案在数千人同时在线的规模下，单台服务器完全扛得住。

第二类是安防监控上云。摄像头普遍走 RTSP 协议，但 RTSP 不适合直接在网页里播放，所以需要把 RTSP 拉流转成 HLS 或者 HTTP-FLV。这个场景 ZLMediaKit 特别擅长，它原生支持做 RTSP 拉流代理，配合 FFmpeg 转码，能把海康、大华这类摄像头的画面直接变成浏览器可播的流。

第三类是在线课堂和低延迟互动。这类场景对延迟要求很高，传统 HLS 五六秒的延迟根本不行。用 SRS 或 OvenMediaEngine 的 WebRTC 出入口，可以把延迟压到 1 秒以内，互动问答、双向连麦都能做。

第四类是内部系统的音视频处理能力。比如做 AI 识别、录制存档、多平台分发，先用开源流媒体统一接入，再挂 FFmpeg 做转码和抽帧，整个管线都在自己手里，可控性很强。

1.3 一个典型的开源流媒体链路长什么样

把上面的场景抽象出来，一条典型的开源流媒体链路大概是这样的：推流端（OBS、FFmpeg、摄像头）通过 RTMP 或 RTSP 把流推到流媒体服务器；服务器负责协议转换、转码、录制、分发；播放端通过 HTTP-FLV、HLS 或 WebRTC 拉流播放。

因为整条链路的核心部件都是开源的，所以任何一个环节都能替换。推流端不想用 OBS 可以用 FFmpeg，服务器不想用 SRS 可以用 ZLMediaKit，播放器不想用 VLC 可以用网页上的 flv.js 或 hls.js。这种"拼装感"正是开源生态最大的价值：你不必忠于某个厂商，只需要忠于标准协议。

2. 核心组件选型：SRS、ZLMediaKit、MediaMTX怎么选

2.1 SRS：直播场景的常青树

SRS 全称 Simple Realtime Server，作者 winlinvip，是 GitHub 上非常活跃的国产开源流媒体项目。它的定位非常精准：直播服务器。RTMP 推流、HTTP-FLV 分发、HLS 切片、WebRTC 播放，这些核心功能开箱即用，配置文件的风格也清晰，学习成本不高。

我最早接触 SRS 是 v2 时代，当时用它做 RTMP 直播，稳定跑了一年多没重启过，后来升级到 v4，接触了 WebRTC 入口，又解决了低延迟互动的需求。现在 SRS 主推 v5 和 v6，底层架构调整较大，性能也更强。如果你需要一个功能全面、社区活跃、文档完善的直播服务器，SRS 是第一选择。

SRS 的部署方式很多样，最简单的是 Docker 一条命令拉起来，想深入研究源码也可以用编译方式安装。它支持通过 HTTP API 做流状态查询和控制，这对集成到现有业务系统特别友好。比如你可以定时调用 API 拉取在线流列表，自动检测断流后重启推流。

2.2 ZLMediaKit：安防与协议兜底利器

如果说 SRS 是直播小能手，那 ZLMediaKit 就是协议缝合怪加安防大管家。这个项目基于 C++11 开发，设计目标就是"一个入口，多协议输出"。它原生支持 RTSP、RTMP、HLS、HTTP-FLV、WebSocket-FLV 的输入输出，还内置了 GB28181 国标接入能力，这让它在安防监控领域占据了很强的话语权。

我记得有一次接一个智慧园区的项目，园区有十几个摄像头，协议既有 RTSP 也有 GB28181，平台要求所有视频在 Web 端实时预览，还要能回放录像。当时就是用 ZLMediaKit 做统一接入，GB28181 国标设备直接注册进服务器，RTSP 摄像头用拉流代理接入，播放端统一走 HTTP-FLV，一套服务器全部搞定。

ZLMediaKit 的使用门槛比 SRS 稍高一点，因为它是一个 C++ 工程，源码编译需要依赖很多库，不过官方提供了预编译包和 Docker 镜像，非硬核场景下直接跑镜像就行。它的 Web API 设计得很贴心，像鉴权、录像查询、按需拉流这些能力都有现成接口。

2.3 MediaMTX：轻量级场景的"瑞士军刀"

MediaMTX 原名 rtsp-simple-server，项目作者很激进地把名字改成了现在这样，它也延续了"极简"的基因。这个项目的最大特点是单二进制文件即下即用，没有复杂的配置，非常适合做原型验证、边缘设备接入、局域网内小规模推流。

我经常用 MediaMTX 做临时中转。比如在调试一个 RTSP 摄像头时，直接在本机跑一个 MediaMTX，把摄像头的流拉进来，再用 VLC 去验证画面，比开一套完整服务器体感轻太多。它支持把 RTSP 流转成 HLS 或 WebRTC，给一些低并发的内部工具用完全够。

不过要实话实说，MediaMTX 在复杂业务场景下不如 SRS 和 ZLMediaKit 那么"厚"，高并发、录像管理、集群扩展这些能力都比较弱。它就是一把轻快的瑞士军刀，适合轻量场景，不适合当主力作战部队。

2.4 选型建议与对比表格

选型建议就一句话：常规直播业务优先选 SRS，安防或复杂协议接入选 ZLMediaKit，临时测试和轻量场景选 MediaMTX。当然也有人把 SRS 和 ZLMediaKit 组合使用，让各自发挥长处，这个后面在实操部分我会提一下。

3. 实操：基于SRS搭一套直播服务（附参数解释与避坑）

3.1 环境准备：Docker 路线和编译路线

SRS 的搭建路径有几条，我建议绝大多数场景直接走 Docker，省时省力，特别适合刚开始接触的人。我自己在开发环境用 Docker，生产环境反而倾向编译安装，因为更容易定制内核参数和做性能调优。

Docker 方式一条命令就行：

bash复制docker run -d --name srs \
  -p 1935:1935 \
  -p 1985:1985 \
  -p 8080:8080 \
  -p 8000:8000/udp \
  registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5.0

端口说明：1935 是 RTMP 协议默认端口，1985 是 SRS HTTP API 端口，8080 是 HTTP 服务端口（用于 HLS/HTTP-FLV 分发），8000/udp 是 WebRTC 媒体端口。如果不想用 Docker，可以走源码编译：

bash复制git clone -b v5.0 https://gitee.com/ossrs/srs.git
cd srs/trunk
./configure --full
make
./objs/srs -c conf/srs.conf

编译时间取决于机器，一般十分钟左右能完成。建议直接 clone v5 分支或者官方 release tag，不要用主干最新代码跑生产，因为主干可能包含未稳定的新特性。

3.2 推流：FFmpeg 和 OBS 两种方式

SRS 默认配置跑起来之后，首先要验证推流链路通不通。FFmpeg 推流是最直接的验证方式，把一个视频文件循环推到服务器：

bash复制ffmpeg -re -i /path/to/test.mp4 \
  -c copy -f flv rtmp://localhost:1935/live/livestream

这里有个关键的参数 -re，它的作用是让 FFmpeg 按照视频原始帧率匀速读取文件，而不是用最快速度一口气推完。我第一次调试的时候忘了加 -re，结果服务器收到的流数据明显异常，播放器缓冲全是乱的，后来查到原因，从此养成习惯：凡是文件推流，必加 -re。

OBS Studio 推流就更简单了，在设置里选"自定义流媒体服务器"，URL 填 rtmp://服务器IP:1935/live，串流密钥填 livestream，点开始推流就能在服务器上看到流状态。如果需要多路流，可以定义不同的 app 或 stream 名称。

推流成功后，SRS 提供了 HTTP API 可以查询流状态：

bash复制curl http://localhost:1985/api/v1/streams/

返回的 JSON 里能看到流名称、在线状态、推流时间等信息。这个 API 在自动化运维中非常好用，我写过一个定时脚本，检测到某个摄像头断流超过一分钟就自动告警，就是基于它做的。

3.3 拉流播放：多协议验证与跨域问题

SRS 的流推上来了，紧接着就是拉流播放。同一路流可以同时用好几种协议来播放，这是 SRS 很舒服的一点。

• RTMP 播放：rtmp://localhost:1935/live/livestream，可以用 VLC 打开验证。
• HTTP-FLV 播放：http://localhost:8080/live/livestream.flv，网页端用 flv.js 播放器就可以拉。
• HLS 播放：http://localhost:8080/live/livestream.m3u8，需要确认配置文件里 hls 选项已经开启，生成的 m3u8 文件会出现在 SRS 的 HTTP 服务目录下。
• WebRTC 播放：默认 WebRTC 播放走 HTTPS/WSS 协议，如果直接 HTTP 访问浏览器会报错，需要加一层 HTTPS 反向代理，具体我在后面单独说。

第一次用浏览器播放 HTTP-FLV 时，很常见的问题是跨域。因为播放页面可能部署在 80 端口，而流服务跑在 8080 端口，浏览器的同源策略会拦截接口请求。SRS 在 HTTP 服务里默认会输出 CORS 头，但如果你用了 Nginx 反向代理，需要自己在 Nginx 里补上对应的头信息。我建议从一开始就把播放域名和流媒体服务放在同一个层级的反向代理后面，统一管理 CORS 和 HTTPS，省得后面一个个坑去踩。

3.4 关键配置与延迟调优：gop、缓冲和自适应码率

对直播来说，延迟和卡顿是一对矛盾。想要延迟低，播放器就得少缓冲，但网络一旦抖动就容易卡；想要流畅，就得让播放器多缓冲，但延迟就上去了。SRS 在服务端能做的主要是控制切片大小和 GOP（画面组长度）。

在 SRS 的 conf/srs.conf 中，和延迟直接相关的配置有：

nginx复制vhost __defaultVhost__ {
    play {
        gop_cache         on;
        queue_length      10;
        mw_latency        100;
        tcp_nodelay       on;
    }
    hls {
        enabled           on;
        hls_fragment      2;
        hls_window        20;
    }
}

gop_cache 控制是否开启 GOP 缓存。开启后，新进播放器可以快速拉到关键帧开始播放，画面秒开，但代价是对应的缓存会占用内存。hls_fragment 是 HLS 切片长度，默认是 10 秒，为了降低延迟可以调小到 2 秒，但切片越小，HTTP 请求越频繁，服务器压力也相应变大，一般生产环境 2 到 4 秒是比较合理的区间。

还有一个很容易被忽略的参数是推流端的 gop_size，用 FFmpeg 推流时可以强制设置关键帧间隔：

bash复制ffmpeg -re -i input.mp4 -c:v libx264 -g 60 -x264-params keyint=60:min-keyint=60 -c:a aac -f flv rtmp://localhost:1935/live/livestream

关键帧间隔设为 60 帧，意味着在 30fps 的视频中每 2 秒出现一个关键帧。这样播放器最多等一个 GOP 就能开始播放，否则把关键帧间隔拉得很大，即使服务端把播放延迟调得很低，播放器也没法快速起播。

如果你做的业务是几百上千路同时观看的转播场景，建议直接做自适应码率，也就是把同一路流转出多档不同码率的子流，播放端根据网速自动切换档位。SRS 本身不支持转码，需要配合 FFmpeg 转码或者用专业转码服务，但 SRS 对多码率分发的支持是很好的，可以直播流通过 HLS 主播放列表做自适应切换。这个方案在具体实现时稍微复杂一些，不过一旦跑起来，体验会明显比单码率裸播好很多。

3.5 常见的坑：防火墙、API 密钥、鉴权与会话保持

我部署 SRS 过程中踩过的几个坑，值得单独拿出来说。

第一是云服务器安全组。很多时候服务器本机 curl 资源没问题，但外网怎么都访问不了，十有八九是安全组策略没放行端口。SRS 需要放行的端口不止 1935 一个，1985、8080、以及 WebRTC 的 UDP 8000 端口都得检查。如果你要用 HTTPS 反代 WebRTC，还需要为 WSS 单独配置证书。

第二是 SRS 的鉴权机制。SRS 支持通过 HTTP 回调做推流和播放鉴权，也就是在推流或播放事件触发时，向你的业务服务器发一个带鉴权参数的 HTTP 请求，由业务服务器决定是允许还是拒绝。这个机制很灵活，但也容易踩坑：如果你没有配置回调指向的地址，SRS 会默认认为鉴权通过，日志里会有 WARNING；如果你配了回调但回调服务没启动，可能导致所有推流都被拒绝。所以用鉴权前，一定要先确认回调服务可用，否则生产环境一出问题就停摆。

第三是断流重推。摄像头这类设备网络不稳定，RTSP 流经常会断，但摄像头不会自动恢复到同一路径。我的习惯是在接入端配置定时检测，用脚本来判断如果流不存在就重新用 FFmpeg 拉流推流，相当于做了一个简单的看门狗，流媒体服务器只管收流，稳定性和自愈能力全在接入脚本里体现。

4. 协议梳理：RTSP、RTMP、HLS、HTTP-FLV、WebRTC选哪个

4.1 各协议特点与延迟对比

刚接触流媒体的人，容易被一堆协议绕晕。我在这里做一个最直白的解释。

RTSP 是安防设备的"母语"，摄像头基本都支持 RTSP 协议输出，但它在公网传输和浏览器播放方向都不是很友好，通常只做接入协议使用，不对播放端直接暴露。

RTMP 是直播推流的经典协议，基于 TCP，延迟在 2 到 5 秒之间，Adobe 的标准，后来在国内直播生态里存活得非常久，现在很多推流端仍然默认用 RTMP 推流，服务器接收后可以再转成其他协议分发。

HLS 是苹果主导的 HTTP 流协议，把视频切片成一个个小文件，播放器通过 m3u8 索引文件依次拉取。它的优势是兼容性极好，几乎所有现代浏览器和移动端都能直接播，但标准 HLS 的延迟通常很高，5 到 30 秒都很常见。后来出了 LL-HLS（低延迟 HLS），可以把延迟压到 2 秒左右，但对服务器和播放器的要求也更高。

HTTP-FLV 用 HTTP 承载 FLV 封装格式，延迟和 RTMP 差不多，在 2 到 5 秒之间，但它的最大好处是能在浏览器里通过 flv.js 播放，配合上你只需要一个静态 HTTP 服务，不需要浏览器插件，所以它在国内直播 Web 播放端占了一席之地。

WebRTC 是低延迟实时通信的标准，延迟可以做到 1 秒以内，适合视频会议、连麦、互动直播。但它对网络质量敏感，需要协商端口，部署复杂度比前几个协议高不少。

4.2 安防摄像头RTSP接入的典型方案

如果你手里有一台只支持 RTSP 的摄像头，又希望在网页上实时预览，最常见的技术路径是这样：摄像头 RTSP 拉流 -> FFmpeg 转码推 RTMP -> 流媒体服务器接收并切片 -> 播放端走 HTTP-FLV 或 HLS。

这里面的关键步骤是 RTSP 拉流。用 FFmpeg 拉 RTSP 时一定要指定 -rtsp_transport tcp，否则默认可能会尝试 UDP，而很多摄像头在 NAT 场景下 UDP 传输不稳定，画面容易花屏或者断流。

bash复制ffmpeg -rtsp_transport tcp \
  -i "rtsp://username:password@192.168.1.100:554/stream1" \
  -c copy -f flv rtmp://localhost:1935/live/camera1

如果摄像头不止一路，或者你不希望在每一路摄像头上都跑一个 FFmpeg 进程（太浪费资源），推荐直接用 ZLMediaKit 的拉流代理功能。ZLMediaKit 内置了 RTSP 拉流代理，配置一个流代理条目，它就会自动从摄像头拉取 RTSP 流，然后统一转成多种输出协议。这种方案在路数多的时候优势特别明显，我之前做过一个 8 台摄像头的轻量监控项目，就靠 ZLMediaKit 单进程全部接入，CPU 占用极低。

4.3 不同业务场景下的协议选择建议

做直播产品，协议选择基本决定了你的延迟上限和客户端兼容性，我一般按下面这个思路来选。

网页端直播优先考虑 HTTP-FLV。原因很简单：延迟可以控制在几秒内，flv.js 发展多年已经相当稳定，而且不需要 HTTPS 之外的特殊配置。移动端 App 内直播我倾向于用 HLS 做兼容，因为 iOS 原生播放器对 HLS 的支持最完美，Android 端也有成熟的 ExoPlayer 配合。低延迟互动场景、视频连麦、在线答题这种需要实时感的业务，就把 WebRTC 当作主力。

如果你想一套方案全包，也有思路：服务器同时输出多种协议不冲突，我经常这样配置，推流端只推一路到服务器，服务器往不同协议端口各分发一版，播放端根据自己平台自动选择。这种方式虽然增加了服务器复杂度，但对用户来说体验是最好的。

5. 常见问题与排查技巧实录

5.1 推流失败，服务器日志看不出明显错误

我遇到过不少次这种问题：FFmpeg 推流命令报错，但 SRS 日志里没有任何异常。排查的时候先确认 1935 端口通不通：

bash复制telnet 服务器IP 1935

如果端口不通，大概率是防火墙或者安全组没放行。如果端口通，再检查 FFmpeg 推流地址是否完整，注意 rtmp://IP:1935/live/流名 这个格式，少一个斜杠都无法识别。还有一种情况是推流地址用了 rtmp://IP:1935/live/livestream，但 SRS 配置文件里没有定义对应 app 为 virtual host，默认 __defaultVhost__ 通常能处理，但自定义配置时容易漏掉。

5.2 播放画面卡顿或花屏

卡顿问题的排查顺序是：先看服务器 CPU 和网络带宽是否打满，再看播放端缓存是否设置得过大。服务器 CPU 打满通常是因为推流端编码效率低，或者转码任务太多；网络带宽打满则需要检查码率设置和并发观看人数。

花屏问题多半是推流端编码参数问题和传输丢包共同造成的。RTMP 基于 TCP 传输，一般不会丢包，但如果中间经过了网络设备做代理转换，仍然可能出现丢包。我的建议是优先检查推流端是否用了 -re，以及关键帧间隔是否设置得过大。还有一个容易忽略的细节是播放器长宽比和封装格式不一致，导致解码后画面撕裂，这种问题在 VLC 里打开调试信息就能看出来。

5.3 高并发直播时的优化思路

高并发直播并不只是单纯提高服务器配置那么简单。我的生产环境经验是，先做边缘和源站分离，用 Nginx 或者 CDN 做边缘缓存，真正的流媒体源站只需要接收推流，播放请求全部命中边缘缓存，这样源站的负载会小很多。

如果不具备 CDN 条件，可以在服务器内核层面做一些优化，比如调整 TCP 连接队列大小、调大文件描述符限制，再配合 SRS 的配置文件把 max_connections 提高到预期值，同时要注意每个连接的内存开销。实测下来，4 核 8G 的单机跑 SRS，承担几千路 HTTP-FLV 播放流压力不大，但如果你同时开太多 HLS 切片，磁盘 I/O 会成为一个新瓶颈。

5.4 常见问题速查表

6. 开源许可证与项目合规：抄作业前先看协议

6.1 MIT / Apache / GPL / LGPL 到底选什么

很多人拉下一个开源项目就开始用，完全不看许可证，这是一个隐患。选择开源项目做二次开发前，先看许可证已经是我的固定动作。

MIT 和 Apache 2.0 是特别宽松的许可证，你可以自由使用、修改、分发、商用，甚至不需要开源你自己的修改代码，日常做项目可以优先选这类。SRS、ZLMediaKit、MediaMTX 都是 MIT 协议，商用非常友好。

LGPL 比 GPL 友好一些，它允许你通过动态链接等方式在闭源项目中使用该库，但如果你修改了 LGPL 代码本身，修改部分需要开源。FFmpeg 默认编译是 LGPL，不过如果你启用了某些 GPL 模块，整体就变成 GPL 了。

GPL 的传染性最强，只要你使用了 GPL 代码，你的整个项目在分发时都必须以 GPL 方式开源。OBS Studio 就是 GPL，如果你基于 OBS 修改并对外分发，你的修改版本也必须开源。需要注意，GPL 的规定针对的是"分发"行为，如果你只是内部使用不对外分发，通常不触发开源义务，但这里面的边界比较微妙。

6.2 用开源项目做商业产品时的注意事项

用 MIT 协议的 SRS 做商业产品，大体上不用担心钱和授权问题，但依然有几个细节值得注意。一是保留版权声明，MIT 协议要求你在分发时保留原作者的版权声明和许可文本，这些声明通常写在项目的 LICENSE 文件里，不要随手删掉。二是留意项目的商标和品牌规范，协议允许你用代码，但不代表你可以在产品名字里随意使用别人的项目名，最好自己起一个独立的品牌名。三是如果项目涉及专利，要自己确认项目的专利声明，这一点 Apache 2.0 协议里专门有专利授权条款，比 MIT 更周全。

6.3 如何聪明地"拆"一个开源项目做二次开发

开源项目通常很庞大，直接改源码维护成本很高。我的思路是先确认核心功能和扩展点，以 SRS 为例，它允许通过插件、回调、配置文件的方式做扩展，很多需求根本不需要改 C++ 或 Go 源码，用 HTTP 回调加外部业务系统就能实现。举个例子，你想给直播做防盗链，完全可以在自己的 Nginx 层实现 token 校验，而不需要碰 SRS 本体。这样升级 SRS 版本时，你的代码不会被冲突逼着重写。

如果确实需要改源码，我的建议是尽可能地提交合并到上游，这能保证项目升级时你的功能继续被保留。如果上游不接收你的分支，也可以在 fork 基础上做二次开发，但一定要定期把上游的更新合并回你的 fork，避免越改越偏，最后连官方 security 修复都打不上。

7. 延伸思考：开源流媒体和开源的更多可能性

7.1 开源模型如何给流媒体加buff

近两年开源模型发展非常快，我在流媒体项目里开始尝试引入一些开源模型做 AI 辅助。比如用开源语音识别模型给直播流实时生成字幕，用开源视觉模型对视频流做内容审核，通过 FFmpeg 抽帧后交给模型分析，再把识别结果推送给业务系统。这些能力以前基本靠商业 API 或者定制开发，现在开源模型把门槛拉低了很多，和开源的流媒体服务配合起来很舒服。

不过我要提醒一点，开源模型通常对算力有一定要求，跑实时识别的成本和延迟不可忽视，建议先离线跑通再逐步上生产。另外，流媒体是强实时系统，AI 模型的推理结果最好异步处理，别让 AI 逻辑阻塞视频链路。

7.2 个人推荐的学习路线

如果你想系统地掌握开源流媒体，我给一个循序渐进的学习路线。第一步，用 Docker 把 SRS 拉起来，跑通推流和拉流，建立整体认知。第二步，学 FFmpeg 的常用命令，理解音视频的基本处理和转封装流程。第三步，阅读 SRS 的官方文档，把 HLS、HTTP-FLV、WebRTC 的配置逐个试验一遍。第四步，用 ZLMediaKit 做一次摄像头 RTSP 接入，体会协议转换和代理拉流。第五步，尝试写一个简单的播放器页面接入 flv.js 和 hls.js，打通 Web 端完整链路。

学习过程中最大的捷径，是遇到问题先去翻项目源码和 issue，而不是立刻找 AI 聊天工具要答案。开源项目的问题排查通常都在 issue 和 commit 记录里，这个习惯一旦建立，以后看一些冷门项目也能很快上手。

最后分享一个小技巧。我所有流媒体项目的部署脚本里，都会先把服务器核心参数和端口清单用 Markdown 表格写进 README，包括每个端口是做什么的、协议是什么、哪个业务在用。开发的时候觉得多此一举，但过两个月回头看配置，这个文档能救命的程度，谁用谁知道。开源技术本身不需要你有多聪明，但它要求你细心、有耐心，愿意一层层往下钻。这也是我一直觉得，做流媒体的人应该有的基本功。