GB28181选SRS还是ZLMediaKit？我踩了三天坑

选型背景
做国标视频平台，流媒体服务器是绕不开的环节。

主流选择有两个：SRS和ZLMediaKit。

SRS 定位是互联网直播，RTMP推流、HTTP-FLV/HLS拉流做得非常扎实，社区活跃，文档完善-29。

ZLMediaKit 更均衡，RTSP、RTMP、HLS、HTTP-FLV、WebRTC全都支持，尤其对GB28181和安防场景适配更好-29。

两个我都部署过，踩了不少坑，今天把对比和选型建议整理出来。

踩坑经历：SRS的GB28181模块
SRS 5.0开始支持GB28181，通过stream_caster配置启用。

我按照文档配置：

stream_caster {
enabled on;
caster gb28181;
output rtmp://127.0.0.1:1935/live/[stream];
listen 9000;
rtp_port_min 58200;
rtp_port_max 58300;
}
启动SRS，配置设备往9000端口发RTP流。

结果：注册成功，点播黑屏。

排查了很久，最后发现是SRS的GB28181模块对设备兼容性不够。大华设备接入非常不稳定，注册等待时间长；海康正常，但占用内存相对较大-。

换ZLMediaKit。

同样的设备，同样的网络，注册稳定，点播正常。

ZLMediaKit的坑
ZLMediaKit用起来也不是一帆风顺。

第一个坑：端口占用。 ZLMediaKit默认占用554（RTSP）、1935（RTMP）、80（HTTP）。如果服务器上已经有其他服务在用这些端口，会启动失败。

解决方案：用host网络模式启动Docker，或者改配置文件。

第二个坑：Hook配置。 ZLMediaKit通过Hook和信令层对接。hook.enable_flow_report、api.secret这些配置项，和信令层的配置必须严格对齐，否则流注册不上-57。

第三个坑：RTP端口范围。 点播时，ZLMediaKit会分配RTP端口接收设备发来的流。端口范围配置太小，并发点播时端口不够用。

对比总结
对比项 SRS ZLMediaKit
核心场景 互联网直播 安防+直播+低延迟
GB28181支持 5.0+，兼容性一般 原生适配，兼容性好
RTSP支持 偏弱 很强
WebRTC支持 支持 支持
配置复杂度 低 中
文档完善度 好 中上
大华设备兼容 有问题 正常
海康设备兼容 正常 正常
内存占用 较低 中等
我的建议
纯做直播，快速上线，选SRS。 配置简单，文档好，社区活跃。

项目里有摄像头RTSP拉流、又要做网页播放、未来还想上WebRTC，直接选ZLMediaKit。 省得后面再引入第二套服务-29。

但如果你的项目主要对接GB28181设备，ZLMediaKit的兼容性明显更好。 尤其是大华设备，SRS的兼容性确实有问题。

为什么PyGBSentry选ZLMediaKit？
因为项目定位是国标视频平台，设备兼容性是第一优先级。ZLMediaKit对GB28181场景的适配更成熟，RTP接流、转封装、Hook回调这些功能开箱即用。

但这不意味着SRS不好。 如果你的项目已经有SRS环境，信令层可以用PyGBSentry，流媒体层继续用SRS，两边通过Hook对接。社区里有人问过“为何同时使用了SRS和ZLMediaKit”，答案很简单：信令层和流媒体层解耦，各选各的-。

项目现状
PyGBSentry已经开源，AGPL v3.0协议，支持GB/T 28181-2022，向下兼容2016版。Docker部署自带ZLMediaKit集成，也支持通过Hook对接已有SRS环境。

部署三条命令：

git clone https://gitee.com/suoten/PyGBSentry.git

cd PyGBSentry/editions/open-source

python tools/generate_env.py --docker && docker compose up -d

Gitee： suoten/PyGBSentry
GitHub： suoten/PyGBSentry

你流媒体用的SRS还是ZLMediaKit？踩过什么坑？评论区聊聊。