简介：这份文档是浙江大华技术股份有限公司出品的客流统计分析解决方案，面向商场、连锁店等商业场所的运营与技术人员，用于解决客流数据采集、统计与决策支持问题。方案从背景分析、视频智能客流统计系统、大华视频智能分析系统讲起，逐步展开系统总体架构、设计说明与高精度、实时性、可视化、多维度分析等特点，并详细说明规则设置、查询统计、实时显示、设备管理等主要功能，最后给出安装点位、网络规划、系统调试等施工方案，目录结构完整、层次清晰。资源包为单个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:password@192.168.1.64:554/cam/realmonitor?channel=1&subtype=0 # 子码流 rtsp://admin:password@192.168.1.64:554/cam/realmonitor?channel=1&subtype=1

上面这个 RTSP 地址格式是大华 IPC 的通用规则，channel参数对应通道号，subtype=0是主码流、subtype=1是子码流。做客流分析时，如果服务器分析能力有限，可以拉子码流做分析、主码流做录像，这样能降低服务器的解码压力。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:password@192.168.1.64:554/cam/realmonitor?channel=1&subtype=0" # 或者用 ffmpeg 抓一帧看画面角度 ffmpeg -rtsp_transport tcp -i "rtsp://admin:password@192.168.1.64:554/cam/realmonitor?channel=1&subtype=0" -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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

上面这张表是中心服务器侧存储客流统计数据的典型结构。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(ip="192.168.1.100", port=37777, user="admin", pwd="password") # 订阅客流统计事件 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(f"conversion:{event.time}", conversion) client.subscribe_traffic_event(callback=on_traffic_event)

上面这段伪代码展示了 SDK 对接的基本思路：登录设备、订阅客流事件、在回调里处理数据。实际 SDK 的 API 名称和参数结构会有差异，但逻辑是一样的。关键点在于回调函数里不要做耗时操作，否则会阻塞后续事件。我一般会把数据先写进消息队列，再由消费者慢慢处理入库和计算。

验证 SDK 对接是否成功，有个简单方法：在设备端配置一个 1 分钟周期的规则，然后观察自己的数据库里是否每分钟都有一条新记录，且进入和出去的人数跟客户端软件显示的一致。如果数据对不上，先检查时区设置——设备端和服务器端时区不一致会导致统计时间偏移，这个坑我踩过，报表上数据看着有，但时间全错位了。

从那以后我每次做 SDK 对接，都强制先跑一遍时区校验和心跳检测，确认设备时间和服务器时间差在 1 秒以内才继续。希望帮到你。

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