尧图网站建设 
GBHub 国标视频平台一款 Rust 实现的高性能 GB/T 28181 视频接入与分发平台前言最近在做一个视频监控相关的项目需要将不同品牌、不同型号的摄像头统一接入和管理。调研了一圈发现市面上的国标视频平台要么是商业闭源的价格不菲要么是基于 Java 或 Go 实现的开源方案性能和资源占用上总觉得差点意思。于是自己动手用 Rust 写了一个——GBHub 国标视频平台。经过一段时间的开发和实际部署目前已经稳定运行在生产环境中接入了几百路摄像头。在这里把项目的设计和实现思路分享出来希望对有类似需求的朋友有所帮助。项目官网https://gb.automate.org.cn为什么选择 Rust在开始之前先聊聊为什么用 Rust。视频监控平台是一个典型的长时间运行、高并发、对稳定性要求极高的服务端程序。设备注册、心跳保活、信令处理、媒体流转发……任何一环出问题都可能导致整个系统不可用。Rust 的优势恰好匹配这个场景内存安全没有 GC 停顿不会因为垃圾回收导致请求延迟抖动 零成本抽象高性能的同时保持代码的可维护性 强大的异步生态Tokio 提供了高效的异步运行时单机轻松支撑数万并发实际测试下来GBHub 的空闲内存占用不到 50MB单机可以稳定承载 5 万 设备并发注册。系统架构GBHub 采用微服务架构由三个核心服务和一套共享库组成服务 功能 端口gbhub-mgr 管理服务器提供 HTTP API 3002gbhub-sip SIP 信令服务器 6060 (SIP) / 3003 (API)gbhub-scheduler 定时任务调度器 无外部端口管理服务gbhub-mgr统一对外提供 HTTP API同时将未匹配的请求自动代理到 SIP 服务对调用方来说就像是一个完整的服务。定时任务调度器是独立运行的每 30 秒扫描一次 Redis 中的任务配置按 Cron 表达式触发截图、录制、清理等任务不需要额外部署 cron。核心功能设备接入与管理完整支持 GB/T 28181-2016 和 2022 标准设备通过 SIP 协议注册接入。实际测试中海康、大华、宇视等主流厂商的 IPC 和 NVR 都可以正常接入。传输协议自动适配 UDP/TCP注册认证支持 Digest 摘要认证MD5 和 SHA-256 都支持。设备注册成功后平台会自动查询 Catalog 获取通道列表不需要手动配置。2. 实时直播与回放直播支持多种输出协议协议 延迟 适用场景WS-TS 1s 通用浏览器播放WebRTC 500ms 低延迟场景HTTP-FLV / HLS 1-3s 移动端、兼容性优先回放支持精确到秒的检索播放过程中可以暂停、跳转进度。3. 录像与转录两个比较实用的功能自动录制通过定时任务配置按计划自动录制指定通道 录像转录将设备的历史录像片段异步转录为 MP4 文件支持去重和并发控制转录功能在实际项目中帮了大忙——有些设备的录像格式不兼容转录后统一为 MP4方便归档和分享。4. 级联与目录管理支持作为下级平台向上级 SIP 域注册也支持作为上级平台接收下级注册。目录管理支持三种推送方式扁平列表仅推送通道列表 行政目录按省/市/区组织通道 业务目录按业务分组215/216组织通道通道可以绑定自定义名称上级平台看到的目录树会更直观。5. 定时任务内置了 Cron 调度器支持以下任务类型定时截图snapshot 定时录制record 清理残留会话cleanup_sessions 同步设备在线状态sync_device_status 清理过期录像cleanup_media 清理过期截图cleanup_snapshot清理任务在实际运维中非常实用——录像文件占满磁盘是视频平台最常见的问题之一配置一个每天凌晨执行的清理任务就能自动解决。几个值得说的技术点Redis 性能优化早期版本使用 KEYS 命令和 SCAN 遍历 dev_info:* 来获取设备列表设备数量超过 5000 后接口响应明显变慢。后来改成了 Redis Set 维护全局索引all_devices存储所有设备 ID查询 O(1) cascade_ids存储级联服务器 ID启动恢复不再需要 KEYS cascade:*优化后设备列表查询延迟从几百毫秒降到了 1 毫秒以内。连接池方面用了 deadpool-redis解决了之前单连接断连需要重启服务的问题。级联信令与媒体解耦早期版本中级联实例创建时强制依赖 ZLM 在线如果 ZLM 重启级联实例就丢了。后来做了改造SipState 的 zlm 字段改为 Option级联实例创建和恢复时不依赖 ZLM。INVITE 处理时再动态获取 ZLM 客户端。这样 ZLM 重启不会影响级联注册状态系统可靠性提升了不少。反向索引通道绑定用了两个 Hashchannel_bindingsapp:stream → 通道 ID正向 channel_bindings_rev通道 ID → app:stream反向反向索引让级联场景下的流查找变成了 O(1) 常数时间不用遍历查找。部署体验部署流程比较简单配置好 Redis、PostgreSQL/GreptimeDB、ZLMediaKit 创建 .env 文件配置数据库连接、SIP 参数等 启动三个服务项目提供了 systemd 服务配置模板可以用 systemctl 管理服务生命周期。授权方式采用的是 Ed25519 数字签名 硬件指纹绑定授权文件 license.lic 放在服务目录下即可。一些踩过的坑设备注册失败最常见的原因是 SIP 端口没开放默认 6060或者密码配置不一致。查看 logs/sip.log 可以快速定位。流播放黑屏一般有两种情况——ZLM 节点离线或者设备端码率过高。前者检查 zlm_nodes:online 集合后者在设备端降低码率试试。录像转录超时如果设备不支持回放或者时间范围内没有录像转录任务会超时。建议先通过设备录像查询确认时间范围内有数据。后续计划Docker 镜像支持进一步降低部署门槛 更多流媒体协议的支持 智能分析能力接入总结GBHub 是我在 Rust 国标视频平台方向的一次尝试目前已经能够稳定支撑实际项目使用。如果你也在做视频监控相关的项目或者对 Rust 在安防领域的应用感兴趣欢迎交流。项目官网https://gb.automate.org.cn在线演示https://mgr.automate.org.cn用户名 admin / 密码 admin123 GBHub 国标视频平台
GBHub 国标视频平台一款 Rust 实现的高性能 GB/T 28181 视频接入与分发平台前言最近在做一个视频监控相关的项目需要将不同品牌、不同型号的摄像头统一接入和管理。调研了一圈发现市面上的国标视频平台要么是商业闭源的价格不菲要么是基于 Java 或 Go 实现的开源方案性能和资源占用上总觉得差点意思。于是自己动手用 Rust 写了一个——GBHub 国标视频平台。经过一段时间的开发和实际部署目前已经稳定运行在生产环境中接入了几百路摄像头。在这里把项目的设计和实现思路分享出来希望对有类似需求的朋友有所帮助。项目官网https://gb.automate.org.cn为什么选择 Rust在开始之前先聊聊为什么用 Rust。视频监控平台是一个典型的长时间运行、高并发、对稳定性要求极高的服务端程序。设备注册、心跳保活、信令处理、媒体流转发……任何一环出问题都可能导致整个系统不可用。Rust 的优势恰好匹配这个场景内存安全没有 GC 停顿不会因为垃圾回收导致请求延迟抖动 零成本抽象高性能的同时保持代码的可维护性 强大的异步生态Tokio 提供了高效的异步运行时单机轻松支撑数万并发实际测试下来GBHub 的空闲内存占用不到 50MB单机可以稳定承载 5 万 设备并发注册。系统架构GBHub 采用微服务架构由三个核心服务和一套共享库组成服务 功能 端口gbhub-mgr 管理服务器提供 HTTP API 3002gbhub-sip SIP 信令服务器 6060 (SIP) / 3003 (API)gbhub-scheduler 定时任务调度器 无外部端口管理服务gbhub-mgr统一对外提供 HTTP API同时将未匹配的请求自动代理到 SIP 服务对调用方来说就像是一个完整的服务。定时任务调度器是独立运行的每 30 秒扫描一次 Redis 中的任务配置按 Cron 表达式触发截图、录制、清理等任务不需要额外部署 cron。核心功能设备接入与管理完整支持 GB/T 28181-2016 和 2022 标准设备通过 SIP 协议注册接入。实际测试中海康、大华、宇视等主流厂商的 IPC 和 NVR 都可以正常接入。传输协议自动适配 UDP/TCP注册认证支持 Digest 摘要认证MD5 和 SHA-256 都支持。设备注册成功后平台会自动查询 Catalog 获取通道列表不需要手动配置。2. 实时直播与回放直播支持多种输出协议协议 延迟 适用场景WS-TS 1s 通用浏览器播放WebRTC 500ms 低延迟场景HTTP-FLV / HLS 1-3s 移动端、兼容性优先回放支持精确到秒的检索播放过程中可以暂停、跳转进度。3. 录像与转录两个比较实用的功能自动录制通过定时任务配置按计划自动录制指定通道 录像转录将设备的历史录像片段异步转录为 MP4 文件支持去重和并发控制转录功能在实际项目中帮了大忙——有些设备的录像格式不兼容转录后统一为 MP4方便归档和分享。4. 级联与目录管理支持作为下级平台向上级 SIP 域注册也支持作为上级平台接收下级注册。目录管理支持三种推送方式扁平列表仅推送通道列表 行政目录按省/市/区组织通道 业务目录按业务分组215/216组织通道通道可以绑定自定义名称上级平台看到的目录树会更直观。5. 定时任务内置了 Cron 调度器支持以下任务类型定时截图snapshot 定时录制record 清理残留会话cleanup_sessions 同步设备在线状态sync_device_status 清理过期录像cleanup_media 清理过期截图cleanup_snapshot清理任务在实际运维中非常实用——录像文件占满磁盘是视频平台最常见的问题之一配置一个每天凌晨执行的清理任务就能自动解决。几个值得说的技术点Redis 性能优化早期版本使用 KEYS 命令和 SCAN 遍历 dev_info:* 来获取设备列表设备数量超过 5000 后接口响应明显变慢。后来改成了 Redis Set 维护全局索引all_devices存储所有设备 ID查询 O(1) cascade_ids存储级联服务器 ID启动恢复不再需要 KEYS cascade:*优化后设备列表查询延迟从几百毫秒降到了 1 毫秒以内。连接池方面用了 deadpool-redis解决了之前单连接断连需要重启服务的问题。级联信令与媒体解耦早期版本中级联实例创建时强制依赖 ZLM 在线如果 ZLM 重启级联实例就丢了。后来做了改造SipState 的 zlm 字段改为 Option级联实例创建和恢复时不依赖 ZLM。INVITE 处理时再动态获取 ZLM 客户端。这样 ZLM 重启不会影响级联注册状态系统可靠性提升了不少。反向索引通道绑定用了两个 Hashchannel_bindingsapp:stream → 通道 ID正向 channel_bindings_rev通道 ID → app:stream反向反向索引让级联场景下的流查找变成了 O(1) 常数时间不用遍历查找。部署体验部署流程比较简单配置好 Redis、PostgreSQL/GreptimeDB、ZLMediaKit 创建 .env 文件配置数据库连接、SIP 参数等 启动三个服务项目提供了 systemd 服务配置模板可以用 systemctl 管理服务生命周期。授权方式采用的是 Ed25519 数字签名 硬件指纹绑定授权文件 license.lic 放在服务目录下即可。一些踩过的坑设备注册失败最常见的原因是 SIP 端口没开放默认 6060或者密码配置不一致。查看 logs/sip.log 可以快速定位。流播放黑屏一般有两种情况——ZLM 节点离线或者设备端码率过高。前者检查 zlm_nodes:online 集合后者在设备端降低码率试试。录像转录超时如果设备不支持回放或者时间范围内没有录像转录任务会超时。建议先通过设备录像查询确认时间范围内有数据。后续计划Docker 镜像支持进一步降低部署门槛 更多流媒体协议的支持 智能分析能力接入总结GBHub 是我在 Rust 国标视频平台方向的一次尝试目前已经能够稳定支撑实际项目使用。如果你也在做视频监控相关的项目或者对 Rust 在安防领域的应用感兴趣欢迎交流。项目官网https://gb.automate.org.cn在线演示https://mgr.automate.org.cn用户名 admin / 密码 admin123