简介这份文档是浙江大华技术股份有限公司出品的客流统计分析解决方案面向商场、连锁店等商业场所的运营与技术人员用于解决客流数据采集、统计与决策支持问题。方案从背景分析、视频智能客流统计系统、大华视频智能分析系统讲起逐步展开系统总体架构、设计说明与高精度、实时性、可视化、多维度分析等特点并详细说明规则设置、查询统计、实时显示、设备管理等主要功能最后给出安装点位、网络规划、系统调试等施工方案目录结构完整、层次清晰。资源包为单个doc文档压缩包约5.64MB内容涵盖概述、架构、功能、施工与设备介绍等章节适合安防、零售信息化从业者及方案设计人员参考可帮助读者快速理解视频智能客流统计的落地思路与实施要点。目前已有284人学习下载。1. 大华客流统计分析方案从视频流到经营报表的完整链路商场出入口那台吸顶球机每秒都在吐 RTSP 码流但真正能变成「今天下午三点进店 427 人、出店 389 人、滞留超 30 分钟占比 12%」这种经营数据的中间隔着一整套视频智能分析链路。大华这套客流统计分析解决方案服务器方式就是干这个的——前端摄像机负责采集智能网络视频服务器负责解码和算法分析中心服务器负责汇总和对接 POS/ERP客户端出报表。它解决的不是「装个摄像头数人头」这么简单的事而是把非结构化的视频画面变成结构化的人数、方向、时间戳再落到可导出的 Excel 和折线图上。适合谁看做连锁零售信息化、弱电集成、商业地产运营的从业者尤其是手里已经有大华 IPC 或 DVR 存量设备、想加一层客流分析能力的人。这套方案的核心价值在于不用换前端加一台 DH-IVS-PC 就能把现有视频通道变成客流传感器。2. 系统架构拆解四层链路怎么走通2.1 前端到中心服务器的数据流这套方案采用分层架构、分布式部署整个链路分四段前端视频编码设备、智能网络视频服务器、中心服务器、管理软件。前端可以是模拟摄像机DVR、模拟摄像机NVS、或者直接上 IPC新建点位推荐 IPC编码后直接出网络流省掉一层转换。智能网络视频服务器是核心分析节点DH-IVS-PC 这台设备最大支持 8 路视频通道兼容 CIF/D1/720P/1080P 多种码流前端码流通过网络传过来它在本地做解码和智能分析把统计结果上报给中心服务器。中心服务器做统一设备管理、用户权限、数据汇总还能跟第三方 ERP、POS 对接。管理软件是 C/S 架构分店人员只能看自己分店的数据总部管理员能看所有分店。这里有个关键设计点智能网络视频服务器通过普通功能接入协议跟前端设备连接自身作为带智能分析功能的设备通过带智能化功能的接入协议跟中心平台互联。这意味着前端不需要支持智能分析只要出标准码流就行分析能力全部集中在服务器侧。对于已经有大量普通 IPC 的商场来说这个架构的改造量最小——不用换摄像机加服务器就行。2.2 智能分析算法的规则配置逻辑大华这套客流统计算法的工作方式是在视频画面上画检测区域然后对区域内的人体目标进行检测和跟踪。具体来说它通过分析活体的形状特征——主要是人头和双肩构成的封闭区域——来判断人头数量。这个思路在俯视角度下比较靠谱因为从上往下看人头和肩膀的轮廓相对稳定不像正面检测那样受衣着、姿态影响大。规则配置有几个维度需要搞清楚。第一是检测区域支持不规则多边形你可以沿着出入口的实际形状画框不用局限于矩形。第二是进出方向需要手动定义哪边是进、哪边是出这个方向判断直接影响统计算法的逻辑。第三是目标大小过滤可以设置最小和最大目标像素尺寸把行李箱、购物车、小孩这些非目标过滤掉。第四是统计周期支持 1 分钟、10 分钟等不同粒度。第五是使能时间段可以按一周内每天不同时段设置规则生效时间比如营业时间外不统计。# 典型的大华 IPC RTSP 取流地址格式供服务器拉流分析用 # 主码流 rtsp://admin:password192.168.1.64:554/cam/realmonitor?channel1subtype0 # 子码流 rtsp://admin:password192.168.1.64:554/cam/realmonitor?channel1subtype1上面这个 RTSP 地址格式是大华 IPC 的通用规则channel参数对应通道号subtype0是主码流、subtype1是子码流。做客流分析时如果服务器分析能力有限可以拉子码流做分析、主码流做录像这样能降低服务器的解码压力。DH-IVS-PC 在 CIF 分辨率下最小人头检测尺寸是 20×20 像素响应时间小于 1 秒这个参数决定了你的摄像机安装高度和覆盖范围——人头在画面里太小算法就抓不到了。2.3 中心服务器的数据汇总与第三方对接中心服务器不只是个数据中转站它承担了几个关键职能。设备管理方面它统一管理前端编码设备和智能网络视频服务器的状态能实时查看设备运行状态和告警信息。权限管理方面支持多级权限分店和总部的数据可见范围不同。数据汇总方面各路视频服务器的统计上报数据在这里汇聚形成全连锁的客流视图。第三方对接方面中心服务器可以跟 ERP、POS 系统做数据交换把客流数据和销售数据关联起来算出提袋率、平均客单价这些经营指标。对接方式常见做法是通过标准 SDK 接口或者数据库中间表。大华提供标准 SDK第三方系统可以通过 SDK 拉取客流统计数据也可以由中心服务器主动推送。如果 POS 系统有会员识别能力还能把客流和会员消费关联做更细的用户画像。不过要注意POS 对接涉及数据字段映射和同步频率的问题客流数据是按分钟或小时统计的POS 数据是按笔交易的时间粒度不一致需要做聚合对齐。3. 从安装到出报表可复现的部署流程3.1 摄像机安装点位与角度参数安装点位直接决定统计准确率这是整个方案里最不能凑合的环节。出入口统计的摄像机应采用垂直吸顶安装方式推荐用球机垂直向下采集。为什么强调垂直因为算法靠人头和双肩的封闭区域来判断垂直俯视时人头轮廓最清晰重叠影响最小。区域内人流统计可以用枪机角度可以稍微倾斜但也要尽量保证俯视。安装参数有明确的推荐范围人的身高按平均 1.7 米计算摄像机安装高度建议 3 米到 3.5 米距离出入口水平距离 1.5 米到 3 米距离客流方向 0.5 米到 1 米俯视角度不小于 70 度。这几个数字不是随便定的——高度太低画面覆盖范围不够高个子会出画高度太高人头像素太小低于 20×20 像素就检测不到。水平距离和客流方向的距离决定了人流在画面中的停留时间太近的话人一闪而过跟踪算法来不及建立轨迹。# 安装后验证 RTSP 流是否正常 ffplay -rtsp_transport tcp rtsp://admin:password192.168.1.64:554/cam/realmonitor?channel1subtype0 # 或者用 ffmpeg 抓一帧看画面角度 ffmpeg -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/cam/realmonitor?channel1subtype0 -frames:v 1 -y snapshot.jpg上面两条命令是安装调试时常用的验证手段。ffplay直接拉流看实时画面确认摄像机角度和覆盖范围是否符合预期。ffmpeg抓一帧存成图片方便在电脑上仔细看画面里人头的大小和清晰度。注意要加-rtsp_transport tcp参数UDP 模式下有些网络环境会丢包导致花屏。抓帧之后用图片查看器放大看如果画面里正常身高的人头直径小于 20 像素就得调整安装高度或换更高分辨率的摄像机。3.2 规则配置与统计周期设置规则配置在客户端软件里操作核心是画检测区域和定义进出方向。检测区域支持不规则多边形沿着出入口的实际边界画就行不用画太大刚好覆盖人流通道即可。进出方向的定义逻辑是在画面上画一条虚拟线或者定义一个方向向量算法根据目标穿越方向来判断是进还是出。这里有个容易翻车的点——方向定义反了进变成出、出变成进报表数据全反。配置完之后一定要在现场实际走几趟看实时计数是否跟实际方向一致。统计周期支持 1 分钟、10 分钟等粒度这个设置影响数据量和报表精度。如果只是看每天的客流趋势10 分钟粒度足够了如果要分析高峰期每分钟的客流波动就得设 1 分钟。但周期越短数据量越大中心服务器的存储和查询压力也越大。常见做法是平时用 10 分钟粒度做活动或特殊分析时临时改成 1 分钟。-- 客流统计数据表结构示意中心服务器侧 CREATE TABLE traffic_count ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id VARCHAR(64) NOT NULL COMMENT 设备编号, channel_no INT NOT NULL COMMENT 通道号, rule_id VARCHAR(32) NOT NULL COMMENT 规则ID, stat_time DATETIME NOT NULL COMMENT 统计时间点, period_minutes INT DEFAULT 10 COMMENT 统计周期(分钟), enter_count INT DEFAULT 0 COMMENT 进入人数, exit_count INT DEFAULT 0 COMMENT 出去人数, region_id VARCHAR(32) COMMENT 区域编号, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_device_time (device_id, stat_time), INDEX idx_region_time (region_id, stat_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;上面这张表是中心服务器侧存储客流统计数据的典型结构。device_id和channel_no定位到具体摄像机和通道rule_id对应配置的统计规则stat_time是统计时间点period_minutes记录统计周期。enter_count和exit_count分别存进入和出去的人数。两个索引分别支持按设备和按区域的时间范围查询。实际部署时这张表的数据量增长很快——假设 100 个通道、10 分钟粒度一天就是 14400 条记录一年就是 525 万条所以分区和归档策略要提前规划。3.3 报表导出与数据验证报表功能支持年报、月报、日报、时报展示形式有折线图和柱状图数据可以导出成 Excel。导出格式一般是 CSV 或 XLS字段包括时间、进入人数、出去人数、滞留人数等。验证数据准确性有个简单方法在低峰期安排几个人按已知顺序进出看系统计数是否跟实际人数一致。比如安排 5 个人依次进入、3 个人出去系统应该显示进 5 出 3。如果偏差超过 1就要检查安装角度或规则配置。准确率指标方面官方给的数据是一般环境下 85% 到 95%标准环境下可达 95%。一般环境指正常人流、没有达到拥挤程度标准环境指人流稀疏、重叠情况少。这个参数很实在——它没有吹牛说 99%而是给了个区间。实际项目中出入口宽敞、人流不密集的场景做到 95% 以上是可能的但遇到促销活动、人流拥挤的时候准确率会明显下降因为人体重叠严重算法很难区分个体。4. 避坑与排查那些让统计数字失真的细节4.1 人头检测不到或计数偏少现象实时画面里明明有人经过但计数不增加或者一批人过去只计了两三个。原因最常见的是人头像素太小。DH-IVS-PC 在 CIF 分辨率下最小人头检测尺寸是 20×20 像素如果摄像机安装太高或者用了低分辨率码流人头在画面里只有十几个像素算法就抓不到。其次是目标大小过滤设置过严把正常人头也过滤掉了。还有一种情况是检测区域画偏了人流实际走的路径没有完全覆盖在区域内。解决先抓一帧画面用图片工具量一下画面里正常身高的人头直径有多少像素。低于 20 像素就调整安装高度或者把码流从 CIF 换成 D1 或 720P。然后检查目标大小过滤参数把最小尺寸适当调小。最后确认检测区域是否覆盖了所有人流通道特别是出入口比较宽的时候区域要画满整个通道宽度。4.2 进出方向反了现象报表里显示进店人数是负数或者明显跟实际相反——早上开门时出店人数暴增。原因进出方向定义跟实际人流方向不一致。配置的时候可能把画面上的方向搞反了或者摄像机安装方向跟预期相反。解决在现场实际走几趟一个人从外往里走看实时计数是加在「进入」还是「出去」上。如果反了在规则配置里把方向向量翻转 180 度。改完之后再走几趟验证。这个坑很常见尤其是多个出入口方向不一致的时候每个通道都要单独验证。4.3 多人并排通过时计数偏少现象两三个人并排走进来系统只计了一个或两个。原因人体重叠导致算法把多个人识别成一个目标。这是俯视角度下客流统计的固有难点——两个人挨得近人头和肩膀的轮廓在画面里连成一片算法分不开。官方参数里说的「一般环境 85%-95%」就是这个原因标准环境人流稀疏才能到 95%。解决安装时尽量让摄像机垂直向下减少倾斜角度带来的重叠。出入口通道如果比较宽可以考虑装两台摄像机从不同角度覆盖或者用更高分辨率让每个人头的像素更多、更容易区分。另外规则里的目标大小过滤不要设得太宽避免把两个人粘连的区域当成一个大目标。4.4 统计周期设置不当导致数据量爆炸现象中心服务器磁盘很快满了查询报表越来越慢。原因统计周期设得太短比如设了 1 分钟每个通道每天产生 1440 条记录100 个通道就是 14.4 万条一年就是 5000 多万条。如果没有分区和归档策略数据库很快撑不住。解决默认用 10 分钟粒度只有做专项分析时才临时改成 1 分钟。中心服务器的数据库要按时间分区比如按月分区历史数据定期归档到冷存储。查询报表时限制时间范围不要一次性查一整年的 1 分钟粒度数据。4.5 网络丢包导致统计断档现象某个时间段的数据缺失报表上出现空白。原因前端摄像机到智能网络视频服务器之间的网络不稳定RTSP 流丢包导致分析中断。UDP 传输模式下这个问题更明显。解决RTSP 取流时强制用 TCP 传输虽然延迟稍微高一点但稳定性好很多。网络交换机要保证带宽足够8 路 1080P 码流大概需要 32Mbps 以上的稳定带宽。如果网络环境差可以适当降低码流分辨率用 D1 代替 1080P 做分析画质对人数统计的影响没有想象中那么大但带宽压力小很多。5. 进阶技巧用 SDK 把客流数据接进自己的系统大华提供标准 SDK 接口这意味着你可以不依赖它的客户端软件把客流统计数据直接拉进自己的业务系统。常见做法是用 SDK 的实时数据回调接口服务器每统计完一个周期就主动推送数据过来你的程序收到后写入自己的数据库再跟 POS 数据做关联分析。# 大华 SDK 客流数据回调的伪代码示意具体 API 名称以实际 SDK 文档为准 # 登录设备 login_id client.login(ip192.168.1.100, port37777, useradmin, pwdpassword) # 订阅客流统计事件 def on_traffic_event(event): # event 包含通道号、统计时间、进入人数、出去人数、规则ID record { channel: event.channel, stat_time: event.time, enter: event.enter_count, exit: event.exit_count, rule_id: event.rule_id } # 写入自己的业务数据库 db.insert(traffic_count, record) # 实时计算转化率需结合 POS 数据 if pos_data_ready(event.time): conversion calc_conversion(event.enter_count, pos_data) cache.set(fconversion:{event.time}, conversion) client.subscribe_traffic_event(callbackon_traffic_event)上面这段伪代码展示了 SDK 对接的基本思路登录设备、订阅客流事件、在回调里处理数据。实际 SDK 的 API 名称和参数结构会有差异但逻辑是一样的。关键点在于回调函数里不要做耗时操作否则会阻塞后续事件。我一般会把数据先写进消息队列再由消费者慢慢处理入库和计算。验证 SDK 对接是否成功有个简单方法在设备端配置一个 1 分钟周期的规则然后观察自己的数据库里是否每分钟都有一条新记录且进入和出去的人数跟客户端软件显示的一致。如果数据对不上先检查时区设置——设备端和服务器端时区不一致会导致统计时间偏移这个坑我踩过报表上数据看着有但时间全错位了。从那以后我每次做 SDK 对接都强制先跑一遍时区校验和心跳检测确认设备时间和服务器时间差在 1 秒以内才继续。希望帮到你。本文还有配套的精品资源点击获取