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

主流选择有两个：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; rtpport min 58200; rtpport_max 58300; } 启动SRS，配置设备往9000端口发RTP流。

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

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

换ZLMediaKit。

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

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

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

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

第二个坑：Hook配置。 ZLMediaKit通过Hook和信令层对接。hook.enable flowreport、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？踩过什么坑？评论区聊聊。