引言多品牌设备的“战国时代”在复杂的工业现场与智慧城市项目中架构师面临的最大挑战往往是存量设备的整合。客户现场可能同时存在海康的 IPC、大华的 NVR、宇视的平台服务器甚至还有老旧的 Onvif 设备。传统的视频管理平台VMS往往需要针对每种协议写一套驱动开发周期长维护成本极高。如果能有一种架构能够像“万能翻译”一样将 GB28181、RTSP、RTMP 等协议统一纳管实现从“设备接入”到“AI 分析”的全流程解耦将能为企业节省巨大的研发成本。今天我们将深入解析YiheCode Server的接入层架构看它如何通过标准化的流媒体设计兑现“减少 95% 开发成本”的承诺。一、 接入层架构协议无关的流媒体设计YiheCode Server 的核心设计理念在于**“信令与媒体分离”。系统并不直接与物理摄像头硬编码交互而是构建了一层流媒体代理网关Media Gateway**。其工作流如下信令层负责与设备握手GB28181 注册、RTSP Describe、Onvif Probe。拉流层根据信令获取的地址统一拉取 RTSP/RTMP 流。转封装层将拉取到的 H.264/H.265 流统一转封装为平台内部标准的 FLV 或 RTC 格式。分发层将标准流分发给播放器、录像模块或 AI 推理模块。这种设计使得上层业务如算法分析、录像存储完全不需要感知底层设备的品牌和协议差异。二、 核心解密多协议统一接入与边缘推流2.1 GB28181 国标设备的智能化纳管对于符合 GB/T 28181-2016 标准的设备系统通过独立的国标信令服务进行管理。系统支持跨网域的级联能够自动发现下级平台的摄像头资源。自动分配策略根据 Gitee 仓库文档中的架构图当新增国标流时系统会自动按照“负载最小”原则将流分配给 ZLMediaKit 节点。被动/主动拉流机制对于手动新增的摄像头录像控制程序会主动拉流并录制。对于国标流系统默认不主动拉流避免信令风暴仅在算法启动时由边缘节点主动发起拉流请求。GB28181 设备接入配置逻辑{device_type:GB28181,sip_server:{host:192.168.1.100,port:5060,id:34020000001320000001,password:123456},media_proxy:{node_id:zlm_node_01,// 指定代理节点auto_pull_stream:false// 算法触发时再拉流}}2.2 RTSP/RTMP 的边缘推流与智能调度对于非国标设备如 RTSP 流地址、RTMP 推流系统提供了极其灵活的边缘推流模式。这在处理大量分散的前端设备时尤为关键。边缘推流的工作机制边缘盒子Edge Box部署在前端的 ARM 设备负责从老旧 IPC 拉取 RTSP 流。协议转换边缘盒子将拉取到的 RTSP 流重新推送到中心的 ZLMediaKit 服务器RTMP 或 RTC 协议。中心统一调度中心平台只认 ZLMediaKit 的流地址不再关心原始设备的网络位置。ZLMediaKit 节点分配算法伪代码defallocate_zlm_node(camera_list): 根据最小负载原则分配 ZLM 节点 zlm_nodesget_online_zlm_cluster()# 获取在线集群forcameraincamera_list:# 策略按当前节点的流数量排序best_nodemin(zlm_nodes,keylambdanode:node.stream_count)ifcamera.protocolGB28181:# 国标流仅注册不主动拉流register_to_sip_server(camera,best_node)else:# 非国标流RTSP/RTMP直接下发拉流指令best_node.start_pull(camera.source_url)camera.assigned_nodebest_node.idlog.info(f摄像头{camera.name}已分配至节点{best_node.ip})三、 部署实战基于 ZLMediaKit 的流媒体集群根据开源文档中的《新系统架构》图示YiheCode Server 采用了 ZLMediaKit 作为核心流媒体服务。为了应对高并发场景我们需要构建一个高可用的流媒体集群。3.1 流媒体集群拓扑[ 中心管理平台 ] | | (HTTP/MQTT 控制信令) v [ ZLMediaKit 集群 ] |-- Node 1 (负责 1-100 路摄像头) - 录像存储 MinIO |-- Node 2 (负责 101-200 路摄像头) - 录像存储 MinIO |-- Node 3 (边缘节点负责拉取外网 RTSP) - 推流至中心 | | (RTSP/RTMP 拉流) v [ 物理设备层 ] |-- 海康威视 IPC (RTSP) |-- 大华 NVR (GB28181) |-- 手机直播 (RTMP) |-- 无人机 (RTSP)3.2 关键配置参数 (application.yml)zlm:# 流媒体节点配置media_server:-id:node_01ip:192.168.10.101http_port:80rtmp_port:1935secret:035c73f7-b6ed-4792-99be-4c0a3c5e8e5e# 鉴权密钥-id:node_02ip:192.168.10.102http_port:80rtmp_port:1935secret:035c73f7-b6ed-4792-99be-4c0a3c5e8e5e# 摄像头分配策略配置camera_strategy:# 固定分配模式手动指定assign_mode:FIXED# 或者 最小负载模式auto# assign_mode: MIN_LOAD# 录像控制策略record:check_interval:300# 5分钟检查一次录像状态enable:true# 对于国标流收到算法告警后才上传文件到对象存储upload_on_alarm:true四、 总结YiheCode Server在协议兼容性上的设计非常具有工程智慧。它通过**“国标信令服务 ZLMediaKit 流媒体代理”**的组合完美解决了安防行业最头疼的“多品牌设备接入”难题。无论是标准的 GB28181还是私有的 RTSP亦或是复杂的跨网域环境都能通过这套架构实现统一的视频流处理。对于集成商而言这意味着你不再需要为每一种新品牌的摄像头去研究 SDK只需要确保它能输出标准视频流系统就能自动完成接入、转码和分发。这种**“协议无关”**的架构正是它能大幅降低开发成本、加速项目交付的关键所在。 演示环境与部署资源如果您正在寻找一套能够真正落地、支持多种硬件环境的 AI 视频管理方案请参考以下信息开源地址Gitee - YiheCode Server架构师建议在处理海量摄像头接入时请务必部署 ZLMediaKit 集群。利用文档中提到的“最小负载分配策略”可以有效避免单台流媒体服务器过载确保视频流的稳定性。对于纯内网环境建议在内网部署边缘 ZLM 节点仅将关键视频流回传至中心。
协议融合与边缘协同：基于 GB28181/RTSP 的企业级 AI 视频中台架构解析
引言多品牌设备的“战国时代”在复杂的工业现场与智慧城市项目中架构师面临的最大挑战往往是存量设备的整合。客户现场可能同时存在海康的 IPC、大华的 NVR、宇视的平台服务器甚至还有老旧的 Onvif 设备。传统的视频管理平台VMS往往需要针对每种协议写一套驱动开发周期长维护成本极高。如果能有一种架构能够像“万能翻译”一样将 GB28181、RTSP、RTMP 等协议统一纳管实现从“设备接入”到“AI 分析”的全流程解耦将能为企业节省巨大的研发成本。今天我们将深入解析YiheCode Server的接入层架构看它如何通过标准化的流媒体设计兑现“减少 95% 开发成本”的承诺。一、 接入层架构协议无关的流媒体设计YiheCode Server 的核心设计理念在于**“信令与媒体分离”。系统并不直接与物理摄像头硬编码交互而是构建了一层流媒体代理网关Media Gateway**。其工作流如下信令层负责与设备握手GB28181 注册、RTSP Describe、Onvif Probe。拉流层根据信令获取的地址统一拉取 RTSP/RTMP 流。转封装层将拉取到的 H.264/H.265 流统一转封装为平台内部标准的 FLV 或 RTC 格式。分发层将标准流分发给播放器、录像模块或 AI 推理模块。这种设计使得上层业务如算法分析、录像存储完全不需要感知底层设备的品牌和协议差异。二、 核心解密多协议统一接入与边缘推流2.1 GB28181 国标设备的智能化纳管对于符合 GB/T 28181-2016 标准的设备系统通过独立的国标信令服务进行管理。系统支持跨网域的级联能够自动发现下级平台的摄像头资源。自动分配策略根据 Gitee 仓库文档中的架构图当新增国标流时系统会自动按照“负载最小”原则将流分配给 ZLMediaKit 节点。被动/主动拉流机制对于手动新增的摄像头录像控制程序会主动拉流并录制。对于国标流系统默认不主动拉流避免信令风暴仅在算法启动时由边缘节点主动发起拉流请求。GB28181 设备接入配置逻辑{device_type:GB28181,sip_server:{host:192.168.1.100,port:5060,id:34020000001320000001,password:123456},media_proxy:{node_id:zlm_node_01,// 指定代理节点auto_pull_stream:false// 算法触发时再拉流}}2.2 RTSP/RTMP 的边缘推流与智能调度对于非国标设备如 RTSP 流地址、RTMP 推流系统提供了极其灵活的边缘推流模式。这在处理大量分散的前端设备时尤为关键。边缘推流的工作机制边缘盒子Edge Box部署在前端的 ARM 设备负责从老旧 IPC 拉取 RTSP 流。协议转换边缘盒子将拉取到的 RTSP 流重新推送到中心的 ZLMediaKit 服务器RTMP 或 RTC 协议。中心统一调度中心平台只认 ZLMediaKit 的流地址不再关心原始设备的网络位置。ZLMediaKit 节点分配算法伪代码defallocate_zlm_node(camera_list): 根据最小负载原则分配 ZLM 节点 zlm_nodesget_online_zlm_cluster()# 获取在线集群forcameraincamera_list:# 策略按当前节点的流数量排序best_nodemin(zlm_nodes,keylambdanode:node.stream_count)ifcamera.protocolGB28181:# 国标流仅注册不主动拉流register_to_sip_server(camera,best_node)else:# 非国标流RTSP/RTMP直接下发拉流指令best_node.start_pull(camera.source_url)camera.assigned_nodebest_node.idlog.info(f摄像头{camera.name}已分配至节点{best_node.ip})三、 部署实战基于 ZLMediaKit 的流媒体集群根据开源文档中的《新系统架构》图示YiheCode Server 采用了 ZLMediaKit 作为核心流媒体服务。为了应对高并发场景我们需要构建一个高可用的流媒体集群。3.1 流媒体集群拓扑[ 中心管理平台 ] | | (HTTP/MQTT 控制信令) v [ ZLMediaKit 集群 ] |-- Node 1 (负责 1-100 路摄像头) - 录像存储 MinIO |-- Node 2 (负责 101-200 路摄像头) - 录像存储 MinIO |-- Node 3 (边缘节点负责拉取外网 RTSP) - 推流至中心 | | (RTSP/RTMP 拉流) v [ 物理设备层 ] |-- 海康威视 IPC (RTSP) |-- 大华 NVR (GB28181) |-- 手机直播 (RTMP) |-- 无人机 (RTSP)3.2 关键配置参数 (application.yml)zlm:# 流媒体节点配置media_server:-id:node_01ip:192.168.10.101http_port:80rtmp_port:1935secret:035c73f7-b6ed-4792-99be-4c0a3c5e8e5e# 鉴权密钥-id:node_02ip:192.168.10.102http_port:80rtmp_port:1935secret:035c73f7-b6ed-4792-99be-4c0a3c5e8e5e# 摄像头分配策略配置camera_strategy:# 固定分配模式手动指定assign_mode:FIXED# 或者 最小负载模式auto# assign_mode: MIN_LOAD# 录像控制策略record:check_interval:300# 5分钟检查一次录像状态enable:true# 对于国标流收到算法告警后才上传文件到对象存储upload_on_alarm:true四、 总结YiheCode Server在协议兼容性上的设计非常具有工程智慧。它通过**“国标信令服务 ZLMediaKit 流媒体代理”**的组合完美解决了安防行业最头疼的“多品牌设备接入”难题。无论是标准的 GB28181还是私有的 RTSP亦或是复杂的跨网域环境都能通过这套架构实现统一的视频流处理。对于集成商而言这意味着你不再需要为每一种新品牌的摄像头去研究 SDK只需要确保它能输出标准视频流系统就能自动完成接入、转码和分发。这种**“协议无关”**的架构正是它能大幅降低开发成本、加速项目交付的关键所在。 演示环境与部署资源如果您正在寻找一套能够真正落地、支持多种硬件环境的 AI 视频管理方案请参考以下信息开源地址Gitee - YiheCode Server架构师建议在处理海量摄像头接入时请务必部署 ZLMediaKit 集群。利用文档中提到的“最小负载分配策略”可以有效避免单台流媒体服务器过载确保视频流的稳定性。对于纯内网环境建议在内网部署边缘 ZLM 节点仅将关键视频流回传至中心。
