先说结论 做国标视频平台，流媒体服务器我最终选了ZLMediaKit，放弃了SRS。

不是因为SRS不好。SRS在互联网直播领域非常优秀，RTMP推流、HTTP-FLV/HLS拉流做得扎实，社区活跃，文档完善。

但国标场景不一样。

为什么一开始选SRS？ 去年开始做国标平台的时候，我第一反应是用SRS。

理由很简单：SRS名气大，用户多，出了问题好搜答案。而且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; } 启动，配置设备往9000端口发RTP流。

注册成功，点播黑屏。

排查过程：三天踩坑记录 第一天：以为是配置问题。

反复检查stream caster配置，确认listen端口和rtpport范围没冲突。检查设备端的SIP服务器配置，每一项都对着文档核对。没问题。

第二天：以为是设备问题。

换了一台海康的设备，能出图。换回大华，黑屏。再换一台大华，还是黑屏。

抓包看RTP流，设备确实往9000端口发了流。但SRS没有转发出来。

第三天：确认是兼容性问题。

翻了SRS的GitHub Issues，发现有人提过类似问题：大华设备的PS封装和SRS的解析逻辑不兼容。SRS的GB28181模块对海康支持还行，对大华、宇视的兼容性不稳定。

这不是SRS的错。 SRS的核心场景是互联网直播，GB28181只是扩展功能。它的资源投入和测试覆盖，不可能覆盖所有国标设备。

换ZLMediaKit之后 同样的设备，同样的网络，同样的配置逻辑。

注册稳定，点播正常。大华、海康、宇视都跑通了。

ZLMediaKit的定位不一样。它从一开始就兼顾了安防场景，对GB28181、RTSP、WebRTC的支持更均衡。RTP接流、转封装、Hook回调这些功能开箱即用。

对比总结 对比项 SRS ZLMediaKit 核心场景 互联网直播 安防+直播+低延迟 GB28181支持 5.0+，兼容性一般 原生适配，兼容性好 大华设备 不稳定 正常 海康设备 正常 正常 宇视设备 未验证 正常 配置复杂度 低 中 文档完善度 好 中上 但这不是说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？踩过什么坑？评论区聊聊。