企业官网建设流程全解析

ZLMediaKit流媒体服务器：4条命令跑通编译、推流与低延迟播放的部署指南

【免费下载链接】ZLMediaKitWebRTC/RTSP/RTMP/HTTP/HLS/HTTP-FLV/WebSocket-FLV/HTTP-TS/HTTP-fMP4/WebSocket-TS/WebSocket-fMP4/GB28181/SRT/STUN/TURN server and client framework based on C++11项目地址: https://gitcode.com/GitHub_Trending/zl/ZLMediaKit

把一路RTMP推流接进来，同时让网页端以低延迟播放，还要能转成HLS和GB28181给其他系统消费——这类需求通常需要部署一台流媒体服务器来完成。ZLMediaKit就是一个基于C++11的流媒体服务器框架，内置RTSP、RTMP、HLS、HTTP-FLV、WebRTC、SRT、GB28181等协议的服务器与客户端实现，还支持协议间互相转换。这篇文章带你从零把它的MediaServer编译出来，跑通推流、拉流、国标接入，并给出常见问题的排查思路。

支持哪些协议和功能：一张清单看懂能力边界

先看清楚它能干什么，再决定要不要用它：

编解码方面，H264/H265/AAC/Opus/G711/MP3/VP8/VP9/AV1全协议可用，JPEG等部分格式可转发但不参与转协议。

从环境准备到启动服务器：一条线走下来的编译流程

整个过程就是"装工具链、拿代码、cmake、make"四步，中间不需要手动配置第三方库，CMake会自动处理。

git clone https://gitcode.com/GitHub_Trending/zl/ZLMediaKit cd ZLMediaKit mkdir build && cd build cmake .. make -j$(nproc)

注意cmake会默认开启部分第三方库的依赖检测，如果缺少ffmpeg、mysql、jemalloc等，构建时会有提示，按提示补装即可，不补装也能编译出核心功能。

编译产物在release/linux/Debug/（或Release）目录下，可执行文件叫MediaServer，同目录会有一份拷贝生成的config.ini。启动时默认加载同目录的配置文件：

./release/linux/Debug/MediaServer

如果你改的是仓库里的配置文件范例，它不会被直接加载，除非用-c参数显式指定：

./release/linux/Debug/MediaServer -c /path/to/config.ini

启动后控制台会打印监听端口和API信息，看到HTTP、RTMP、RTSP、RTP代理的端口全部就绪，就说明服务起来了。

场景一：RTMP推流 + HTTP-FLV网页低延迟播放

要做什么：设备或编码器推一路RTMP流，网页播放器用HTTP-FLV地址观看，延迟目标是秒开、低延迟。

怎么配置：默认端口已经够用，RTMP监听1935（见[rtmp]段port=1935），HTTP监听80（见[http]段port=80）。80/443/1935如果被占用，去[http]和[rtmp]段改掉对应端口即可。推流命令：

ffmpeg -re -i input.mp4 -c copy -f flv rtmp://127.0.0.1:1935/live/stream1

得到什么结果：浏览器访问http://服务器IP/live/stream1.flv即可播放（配合flv.js等播放器）；同一路流还自动转出http://服务器IP/index/api/getSnap?app=live&stream=stream1可取的实时截图。推流断开后continue_push_ms默认给15秒重连窗口，这个参数允许推流端短暂掉线后重连，期间播放器不会立刻断开。

场景二：HLS分发与按需转协议

要做什么：让iOS原生播放器或CDN侧能拉走HLS切片，同时按需才生成切片文件，避免没人看也在写盘。

怎么配置：在配置文件的[protocol]段，enable_hls=1控制是否开启HLS(mpegts)转换，enable_hls_fmp4=1则额外开启fmp4封装的HLS（体积更小、延迟略低）；auto_close=1表示流无人观看时直接关闭，不再等WebHook回调决定。切片相关参数集中在[hls]段，hls_save_path是切片输出目录，按需修改。

得到什么结果：有播放请求进来后，按流的app/stream生成m3u8和ts文件，http://服务器IP/live/stream1/hls.m3u8即可被标准HLS播放器拉取。转协议是"有消费才转"的模型，省磁盘IO，也省CPU。

场景三：GB28181安防设备接入

要做什么：把符合GB28181的摄像头或NVR的视频流接进来，转成RTSP/HTTP-FLV给其他业务用。

怎么配置：关键在[rtp_proxy]段：port=10000是接收设备RTP流的UDP/TCP代理端口（支持TS或PS负载），port_range=30000-35000是随机端口池，注释里提醒这个范围要至少保留36个端口，同时它也会限制RTSP服务器的UDP端口；设备侧把媒体地址指向本机的对应端口即可。接入后通过API下发取流指令，ZLMediaKit会处理注册、心跳与RTP收包。

得到什么结果：设备推上来的PS/TS流被解析成媒体流，之后就能用RTSP、HTTP-FLV、WebRTC任意方式拉取，相当于把安防协议栈和直播协议栈打通了。

调优与排障：按现象定位，按顺序排查

几个高频问题，按"现象→排查顺序→处理办法"处理：

现象：推流握手失败，连接秒断。排查顺序：先确认1935端口在监听（netstat -tlnp | grep 1935）；再看防火墙/安全组是否放行；最后看[rtmp]段handshakeSecond=15，这是握手超时时间，跨公网大延迟时15秒可能不够。处理办法：放行端口；必要时调大handshakeSecond和keepAliveSecond（后者是链路保活超时，长时间无数据也会断连）。

现象：画面延迟高、卡顿不平滑。排查顺序：先用HTTP-FLV拉流替代HLS对比（HLS天然有切片延迟）；再看源流码率是否稳定。处理办法：[rtp]段lowLatency=0是RTP打包的低延迟开关，注意H264一帧多slice时开启可能花屏；[protocol]段paced_sender_ms开启后对转发做平滑发送，代价是CPU和内存，适合源流抖动明显的场景；[rtp_proxy]段merge_frame=1提高兼容性但可能增加延迟，排障时可对照调整。

现象：内存占用持续上涨。排查顺序：先看并发流数量和播放器数（调API/index/api/getMediaList查流列表、/index/api/getStatistic看整体统计）；再看是否开启了不必要的转协议。处理办法：[protocol]段关掉没人用的转换项（如enable_hls_fmp4、enable_mp4）；[rtp_proxy]段gop_cache默认缓存1个GOP用于级联秒开，不用startSendRtp/startRecord的话置0可省内存；编译时用jemalloc也能改善碎片。

管理侧建议把[api]段apiDebug=1留着用于调试，正式环境记得改强secret，敏感API不带secret从非本机访问会被拒绝。

接下来可以做什么

1. 把API测试用例里的C语言示例跑一遍，server.c和pusher.c能帮你快速熟悉MediaServer的API调用形态；
2. 用[hook]段的WebHook配置把on_publish、on_play事件接到自己的业务系统，实现鉴权、录像、计费之类的逻辑；
3. 参考server目录下main.cpp与WebApi.cpp的结构，如果要在ZLMediaKit之上做二次开发，这里是最直接的阅读入口。

【免费下载链接】ZLMediaKitWebRTC/RTSP/RTMP/HTTP/HLS/HTTP-FLV/WebSocket-FLV/HTTP-TS/HTTP-fMP4/WebSocket-TS/WebSocket-fMP4/GB28181/SRT/STUN/TURN server and client framework based on C++11项目地址: https://gitcode.com/GitHub_Trending/zl/ZLMediaKit