雪亮工程整体解决方案：从三级组网到GB/T 28181接入与验收

简介：雪亮工程整体解决方案PPT面向公安、综治、政府机关、金融与厂矿企业等领域的项目规划与方案设计人员，聚焦公共安全视频监控建设联网应用的“四全”目标，适用于农村平安乡村、城区技防、行业视频整合等场景。内容从政策背景与典型建设模式切入，系统梳理省市县三级共享平台、视频存储转发、视频浓缩、人员与车辆识别、视频共享/解析/大数据分析资源池等总体架构，并覆盖一键报警、限时处置、定时轮巡、视频互动指挥、网格员GPS定位等实用功能。整包以1个PPT文件呈现，压缩包约10.05MB，结构完整、图文并茂，可直接用于雪亮工程需求梳理、方案汇报与内部培训。目前已有170人学习，适合需要快速掌握雪亮工程整体框架的售前、产品、实施及公安信息化相关从业者。

1. 雪亮工程整体解决方案不是一份材料，是一张跨三级的视频网

第一次看到“雪亮工程整体解决方案.ppt”这个文件时，多数人会下意识把它当成一份汇报材料。真正推进项目之后才会发现，标题里值钱的是“整体”两个字：前端摄像机、传输链路、GB/T 28181国标接入、存储和AI算力、综治平台业务流、边界安全，任何一层单独做好都不难，难的是它们互相咬合。村级点位布了、县里平台也上线了，结果带宽不够、录像拷不出来、综治中心调不到村里画面的情况，几乎每个项目都要经历一遍。

集成商的技术负责人、售前和交付工程师，可以拿这套思路从组网推演到验收，直接套到自己的项目上。下面按建造顺序讲：先立网络骨架，再撑存储和算力，然后接综治业务，最后过安全边界和验收。

2. 雪亮工程组网架构：从村口摄像头到综治中心，GB/T 28181怎么把链路串起来

2.1 雪亮工程视频专网的三级架构与带宽测算

雪亮工程整体解决方案在网络上最典型的形态是“县—乡—村”三级组网。村级点位一般只有几十路摄像机，通过光纤收发器或ONU设备接入乡镇综治中心；乡镇负责本辖区流媒体的汇聚和转发，同时往上联到县级综治中心；县级平台是整个方案的骨干核心，存放全部录像、运行AI分析算法、对外提供综治业务的视频调用服务。这个结构决定了每一级的上行带宽不是简单相加，而要按“主码流用于存储、子码流用于预览”分开算。

做带宽测算时，我一般先把点位按类型拆开：普通监控点一路1080P主码流按4Mbps规划，子码流按1Mbps规划；卡口和人脸抓拍机因为要保留细节，主码流按6～8Mbps预留。村级到乡镇的汇聚带宽按“所有点位主码流加同时预览的子码流”估算，县级骨干则要再加一个冗余系数，因为综治中心的大屏轮巡和应急指挥会瞬间拉几十路子码流，峰值与均值差别很大。

这个表的一个关键点是“AI复制流”要单独算。现在普遍做法是交换机做端口镜像或GB/T 28181双路取流，AI分析消耗的带宽是在存储带宽之外再复制一份，不预留的话，平台一开人脸识别，交换机会先报警。

2.2 GB/T 28181国标接入的核心信令流程

雪亮工程整体解决方案的联网层面，GB/T 28181是绕不开的协议。它基于SIP做信令控制，用SDP协商媒体流，所有前端设备、下级平台都要先注册到上一级SIP服务器，再通过INVITE请求建立实时音视频会话。很多项目把“国标接入”理解为在设备里填一个IP，一旦填完还是看不到画面，就开始怀疑设备，实际上大部分问题都出在注册和INVITE两个环节上。

下面是一次典型的GB/T 28181实时点播信令，设备端向上级平台发起INVITE请求（这里简化为去掉认证头后的抓包字段）：

INVITE sip:34020000001320000001@3402000000 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.1:5060;rport;branch=z9hG4bK7d3c91 From: <sip:34020000001110000001@3402000000>;tag=9f2a11 To: <sip:34020000001320000001@3402000000> Call-ID: c4d1e8a2-5f3b-4d60-8ef7-2a9c01b33d6e CSeq: 1 INVITE Contact: <sip:34020000001110000001@10.10.10.1:5060> Max-Forwards: 70 Content-Type: application/sdp Content-Length: 238 v=0 o=34020000001110000001 0 0 IN IP4 10.10.10.1 s=Play c=IN IP4 10.10.10.1 t=0 0 m=video 6000 RTP/AVP 96 a=sendonly a=rtpmap:96 PS/90000

这段消息里最关键的是三处：Call-ID和From/To中的20位编码必须与平台里登记的SIP编码一致；SDP里的c=行是媒体流的接收地址；m=video 6000后面的端口是设备开放的RTP端口。平台回复200 OK并携带自己的SDP后，RTP流就开始往对应IP和端口推。如果抓包看到INVITE发出但收不到200 OK，先检查20位编码是否与该平台区域编码一致；如果收到200 OK却没有画面，基本是媒体端口不通或协商的封装格式不匹配。

2.3 前端国标接入的参数设置与常见坑

前端摄像机接入平台时，常用参数就那么几个，但每个都埋过坑：SIP服务器IP和端口默认5060，但有些平台会改成5061或15060；注册周期一般设3600秒，心跳周期设60秒；设备ID按“中心编码加类型码加序号”拼20位数字，类型码里131是摄像机、132是网络录像机，填错会出现“设备在线但目录不出图”。

提示：排障时先用tcpdump -i eth0 port 5060 -s 0 -w sip.pcap抓包，看SIP注册是否真正到达平台。很多“看不到画面”其实是设备离线，而设备离线的原因是注册请求被防火墙挡了或NAT地址没做映射。

村级点位大量使用4G回传时，运营商NAT会打断长连接，国标心跳周期就要从60秒缩短到30秒，并在平台侧开启TCP优先。如果设备支持GB/T 28181的TCP被动模式，优先用TCP，UDP在跨网段、丢包场景下会吃亏。

3. 存储与算力规划：雪亮工程里最容易算错的两笔账

3.1 存储容量估算：码流、天数、冗余系数一个都不能少

雪亮工程整体解决方案的存储规划，第一笔账就是录像容量。常见错误是拿“码流乘路数乘天数”直接除8，得出一个纯裸容量，然后发现采购的磁盘阵列装完RAID以后总空间少了一截，再回头加设备，项目周期就被拖住了。完整公式应该是：单路每日容量（GB）= 码流（Mbps）÷ 8 × 3600 × 24 ÷ 1024，再乘以路数和天数，最后除以存储系统的可用率。RAID5一般按0.85可用率估算，RAID6按0.8，还要扣除系统热备盘。

下面这个Python脚本可以直接套用到项目初算阶段，按主码流加子码流分别计算：

def capacity_per_camera(main_mbps, sub_mbps, days): # 单路每日录像容量(GB)，主码流与子码流叠加后乘天数 daily_main = main_mbps / 8 * 3600 * 24 / 1024 daily_sub = sub_mbps / 8 * 3600 * 24 / 1024 return (daily_main + daily_sub) * days # 1000路1080P，主码流4Mbps，子码流1Mbps，连续存储30天 raw_tb = capacity_per_camera(4, 1, 30) * 1000 / 1024 print(f"裸容量: {raw_tb:.2f} TB") # RAID6可用率80%，额外预留热备盘空间 usable_tb = raw_tb / 0.8 print(f"采购容量: {usable_tb:.2f} TB")

这段代码里，capacity_per_camera(4, 1, 30)返回的是单路30天的主子码流总容量约1582GB，乘1000路再除以1024得到裸容量约1545TB，除以0.8后采购容量约1931TB，差了差不多25%，很多项目就是栽在这个系数上。另一个容易被忽略的变量是“动检录像平均码流”：如果平台支持按移动侦测减帧存储，实际平均码流可能只有峰值的一半，这时可以把4Mbps换成2.4～3Mbps重新估算；但摄像头全部设置为7×24连续录像时，不能用这个折扣，必须按峰值算满。

3.2 AI分析负载怎么映射到GPU或算力盒子

存储之外的第二笔账是AI算力。雪亮工程整体方案中，AI主要跑三类任务：人脸抓拍比对、车辆结构化（车牌加颜色加车型）、行为分析（人员聚集、区域入侵、越界）。这三类任务的算力消耗差异很大，不能拿“多少路配一台服务器”这种粗口径，要按具体干的活来看。

按这个表，一台8卡GPU服务器如果全部跑人脸抓拍，大约能覆盖128路；如果其中有20路要跑行为分析，就得单独留出卡。常见做法是把“人脸加车辆”这类结构化任务放在前端的智能摄像机里做，平台只接收结构化数据，后台再部署少量GPU跑行为分析模型。

注意：选用算力盒子时别只看芯片标称TOPS，要看实际跑模型的帧率。标称16 TOPS的芯片跑一个50层的检测模型，可能只有10路实时；跑轻量级MobileNet类模型，路数能到30路以上。选型一定要用目标模型的实测帧率来反推。

3.3 典型场景的存储与算力参数对照

把存储和算力放在一起看，不同点位规模的取值差异很大。一个300路左右的镇级项目，平均码流可以按3.5Mbps规划，存储30天约70TB，AI部分一台8卡服务器就能覆盖人脸与车辆；到了1000路县级项目，平均码流按4Mbps，存储上面算过约1.9PB，AI服务器就要按结构化任务细分成人脸比对池和视频分析池。具体落地时还要留出平台软件、流媒体转发和数据库的磁盘空间，这部分不占录像盘，但要在方案的总采购清单里单列。

4. 雪亮工程综治平台：视频、网格、事件三张表的联动

4.1 综治信息平台的模块组成与数据关系

雪亮工程整体解决方案不只有视频这一条线。综治信息平台是面向县乡村三级综治中心用户的业务入口，通常包含视频监控、网格管理、事件处置、统计分析、设备运维五个模块。视频监控模块负责调看实时和历史录像，网格管理模块管理网格员和网格单元，事件处置模块接收网格员上报的事件并派单流转，统计分析模块生成日报周报，设备运维模块监控前端点位在线率。

五块建完不难，难在它们之间的数据关系。视频监控里的摄像机要能关联到具体网格，事件处置里的工单要能拉起关联点位的录像回放，统计报表要能按网格聚合事件数量和在线率。很多项目把这五块做成五个孤立页面，演示时看起来都有，实际用起来综治中心的值班员要在几个系统间来回切换，这就失去了“整体”的意义。

4.2 网格事件闭环的数据流设计

事件从发现到办结，常见状态流转是：待受理、处理中、待核查、已办结、已归档。网格员手机端上报一起“井盖缺失”事件，系统根据网格编码自动关联附件和点位视频，综治中心审核后派单给责任部门，责任人处理完上传照片，网格员再次核查确认，事件关闭。整个闭环里，网格编码是核心主键，视频点位、复核照片、工单都要挂在它下面。

下面的SQL表达了一个典型查询：找出某个网格里当前仍然开启的事件，并把事件前后10分钟的录像记录关联出来，用于回看现场：

SELECT e.event_id, e.grid_code, e.event_type, e.level, v.channel_id, v.record_start, v.record_end FROM grid_events e LEFT JOIN grid_video_rel r ON e.grid_code = r.grid_code LEFT JOIN video_recordings v ON v.channel_id = r.channel_id AND v.record_start <= e.report_time + INTERVAL 10 MINUTE AND v.record_end >= e.report_time - INTERVAL 10 MINUTE WHERE e.status = 'OPEN' AND e.report_time >= NOW() - INTERVAL 24 HOUR;

这里grid_events和video_recordings之间多了一张grid_video_rel关联表，解决“一个网格对应多路相机、一路相机覆盖多个网格”的多对多问题。如果直接把channel_id写在事件表里，网格边界一调整就要改业务数据；用关联表之后，网格重新划分只动关系表，不用动历史事件。

4.3 视频联动与GIS地图的集成点

综治中心大屏一般基于GIS地图做调度入口，常见联动是点击地图上的点位图标，调起周边摄像机的实时画面；发生事件时，地图上对应网格闪烁弹窗，值班员点弹窗直接看现场视频、调取最近30分钟的录像。这个联动对视频平台的要求是能按空间坐标做查询，GB/T 28181平台普遍有“按区域编码查目录”的能力，但区域编码是行政区划逻辑，网格不是行政区划，所以项目里经常要在综治平台里单独维护点位与网格的关系。

实现上我一般建议地图平台走GeoJSON图层：网格边界画一个面，点位画成点，用GIS引擎做空间查询，查出该网格内的点位列表后再调视频平台接口。这样地图数据和视频数据解耦，网格重划时不用动视频平台，只更新图层文件即可。

5. 雪亮工程网络边界与设备准入：专网隔离不是关机断网

5.1 视频专网与管理网怎么边界互通

雪亮工程整体解决方案的网络安全里，最容易走极端的是“一刀切断网”：视频专网物理隔离、管理网单独拉线。实际项目里综治中心需要在大屏上看视频，网格员要手机上报事件，手机数据要落到平台，完全物理隔离根本没法干活。常见做法是把网络划分为视频专网、综治业务网、互联网接入区三块，网间通过安全交换设备做协议剥离和内容过滤。

视频专网只承载GB/T 28181流媒体和控制信令；综治业务网承载综治平台的管理页面、工单、GIS；互联网接入区放网格员手机端App的接入服务。视频专网与综治业务网之间的数据交换，一般用视频安全接入设备把RTP流重新封装成平台可管理的内容，而不是直接在防火墙上放通5060和TCP端口。这样即使摄像头被攻击，横向扩散范围也被限制在视频专网内。

5.2 前端设备准入：IP、MAC、GB编码、认证四道关卡

前端点位大多部署在村口、路边、杆件上，物理安全和网络安全都要防。第一道防线是接入交换机的端口级准入，第二道防线是平台侧的注册校验。GB/T 28181平台本身可以按SIP ID做白名单，但SIP ID是明文的，光靠它不够，常见做法是再加两层：交换机的端口安全绑定IP加MAC，平台侧校验设备的注册密码和证书。

注意“设备在线但无法注册”这个特征：交换机端口安全只拦了MAC变动，没拦SIP信令；而平台侧认证失败多半显示401。排障时要按这张表一层层查，先看端口状态，再看抓包里的SIP响应码。

5.3 边界安全设备的一次配置清单

在做雪亮工程整体解决方案交付时，边界设备的配置可以按下面清单逐项核对，这个清单也是验收时安全检查的常见核对点：

• 视频专网与综治业务网之间的安全交换设备开启白名单模式，只放行主动注册的信令和指定端口的媒体流；
• 互联网接入区DMZ主机只开放443和必要的WebService端口，数据库连接只允许内网IP；
• 所有平台主机开启主机防火墙，默认拒绝入站，仅放行平台自身服务端口；
• 前端接入交换机开启DHCP Snooping，防止私接设备自动获取地址后接入网络；
• 用iptables把平台服务器的非业务端口全部关闭，示例规则如下：

iptables -A INPUT -i eth0 -p tcp --dport 5060 -s 10.10.0.0/16 -j ACCEPT iptables -A INPUT -i eth0 -p udp --dport 6000:7000 -s 10.10.0.0/16 -j ACCEPT iptables -A INPUT -i eth0 -j DROP

第一行放行视频专网网段的SIP信令流量；第二行放行媒体端口段，注意媒体端口范围要和GB/T 28181平台实际配置一致，很多平台默认媒体端口不是连续段，会造成UDP丢包；第三行兜底拒绝其他入站。这三条规则写成脚本放进开机自启，比在防火墙Web界面点半天要容易交付，也方便后面逐条审计。

6. 雪亮工程整体解决方案验收：把演示PPT变成可量化的指标

6.1 演示环境与生产环境之间差在哪

PPT演示环境一般只有几十路点位、几台服务器、一张千兆交换机就够了，问题出在并发上。生产环境1000路点位时，综治中心一半的屏都在轮巡、值班员同时调阅历史录像，平台上的并发会话数和媒体转发压力完全不是同一量级。验收时如果不提前准备，很容易在看实时视频时卡顿、回放时起流慢，甚至SIP服务器无响应。

我一般建议在验收前两周就按“点位在线率不低于95%、录像完整率不低于95%、并发预览不低于全点位数的10%”三个指标做上下行压测，提前把瓶颈暴露出来。这三个指标也正好是验收演示当天最容易出问题、最常被提问的地方。

6.2 验收前必做的三类压力测试

实时预览压测用脚本批量拉流转发，先看平台是否存在丢包：

for i in $(seq 1 100); do ffmpeg -loglevel error -i rtp://10.0.0.1:6000 -t 10 -f null - 2>&1 | \ grep -E "error|Invalid" || echo "channel $i ok" done

这里循环100路RTP流，每路看10秒，只要出现丢包或格式错误就输出异常。脚本跑完后再用iperf3 -c 10.0.0.2 -u -b 500M -t 60打一路UDP流，看丢包率是否低于0.1%。历史录像回放压测则要关注起流时间，一般要求点击回放到画面上墙不超过2秒，如果超过，优先检查存储服务器所在网段的带宽。压测期间的指标记录要保存成表格，作为验收比对基线。

6.3 一个容易被忽略的指标：录像完整性校验

录像完整率很难靠肉眼验收，1000路乘30天的录像逐段看根本不现实。推荐做法是抽样：随机取每个点位某一小时的录像，用ffprobe读取录像文件头和时间戳，核对录像时间轴是否连续。更简单的操作是让平台导出该点位的录像时间轴，与原始码流的时间戳做比对，凡是时间跳变超过5分钟的段位，都视为一次录像中断并统计占比。

提示：验收前把一台录像完整性校验服务器放在存储网内，用脚本定时扫描所有点位的录像时间轴，如果发现录像文件已存在、但时间戳跳变率高于5%，基本可以断定存储或平台调度有问题，别等验收当天再查。

本文还有配套的精品资源，点击获取