简介这份资源面向计算机视觉入门与进阶学习者提供一套基于Python的行人检测完整实现重点解决视频场景下行人定位与连续跟踪的问题可服务于智能交通、视频监控等方向的练手与课程实践。压缩包共25个文件约155.2MB包含2个py源码文件、2段avi测试视频、11个bmp与5个png行人样本图像以及4个xml工程配置文件和1个iml模块描述样本与视频可直接用于特征提取和检测效果验证。目前已有8175人学习下载具备一定的参考基础。源码围绕HOG特征提取与SVM分类器展开覆盖灰度化与归一化、多尺度窗口划分、梯度方向直方图构造及块归一化等环节并给出检测框输出与简单跟踪的衔接思路读者可据此理解从特征到分类再到跟踪的完整链路并在此基础上替换样本、调整参数或迁移到其他物体检测任务。1. 行人检测视频源码包一份能直接跑起来的计算机视觉入门资源前阵子帮一个做安防的朋友看项目他手里有一段园区门口的行人视频想统计进出人数又不想从零搭环境。我翻出这份「python行人检测视频源码」资源包解压后直接跑通了检测流程从读视频到画框输出一气呵成。它本质上是一套基于 Python 的行人检测演示工程核心是调用预训练模型对视频逐帧推理把行人用矩形框标出来附带完整可运行的源码和示例视频。适合两类人一是刚接触计算机视觉、想找一个能跑通的目标检测 demo 建立手感的新手二是需要快速验证行人检测可行性、再决定是否深入优化的从业者。它不解决高精度追踪和跨镜头重识别但作为计算机视觉行人检测的起点省掉了环境配置和模型下载的折腾。2. 拆开源码包检测流程与模型选型逻辑2.1 视频行人检测的完整链路行人检测看着简单实际是一条固定链路视频解码取帧 → 图像预处理 → 模型推理 → 后处理过滤 → 画框写回视频。这份源码把这条链路拆成了几个函数主循环负责读帧检测函数负责推理绘制函数负责标注。理解这条链路比记住某个 API 更重要因为后面换模型、调阈值、改输入尺寸动的都是链路上的某个环节。常见做法是用 OpenCV 的VideoCapture读视频逐帧转成模型需要的输入格式推理完再用rectangle画框。源码里对帧率做了保留处理输出视频的 FPS 和原视频一致这点对后续做人数统计很关键——帧率错了统计的时间窗口就全乱了。预处理部分通常包括缩放和归一化缩放尺寸直接决定检测精度和速度的平衡源码默认值偏保守后面会讲怎么调。2.2 为什么选预训练模型而不是自己训练这份资源用的是预训练检测模型没有附带训练脚本。这个选择对入门场景是合理的行人检测的公开预训练模型已经能覆盖大部分常规视角自己标注数据训练的成本远高于直接推理。源码里模型加载部分做了本地缓存判断第一次运行会走下载流程之后直接读本地权重。需要说清楚边界预训练模型的类别里通常包含「人」这一大类不区分站立、行走、骑行也不做姿态估计。如果你的场景是密集人群或者遮挡严重预训练模型的漏检会明显上升这时候才需要考虑换更重的模型或者做微调。源码包的价值在于把推理链路跑通让你先看到效果再判断要不要往深处走。2.3 环境依赖与首次运行依赖不多主要是 OpenCV 和推理框架。建议单独建虚拟环境避免和系统里其他项目的版本打架。下面是我习惯的初始化步骤# 创建并激活虚拟环境Python 3.8 以上即可 python -m venv ped_env source ped_env/bin/activate # Windows 用 ped_env\Scripts\activate # 安装核心依赖版本不必锁死但建议 opencv 用 4.x pip install opencv-python numpy # 如果源码用的是某推理框架按其 requirements 补齐 pip install -r requirements.txt逻辑说明虚拟环境隔离是为了防止 OpenCV 版本冲突这类冲突的典型表现是cv2.imshow报错或者视频写不出去。requirements.txt里如果有版本号优先按它装不要盲目升级到最新版新版 API 变动可能导致源码里某些调用失效。参数上OpenCV 装opencv-python就够不需要contrib版本除非源码里用到了扩展模块。2.4 跑通第一段视频命令与参数源码入口一般是一个主脚本接受输入视频路径和输出路径两个参数。运行方式大致如下# 基本运行指定输入视频输出默认写到当前目录 python detect.py --input demo.mp4 --output result.mp4 # 调整置信度阈值和输入尺寸平衡漏检与速度 python detect.py --input demo.mp4 --output result.mp4 --conf 0.4 --size 640逻辑说明--conf是置信度阈值低于它的检测框会被丢弃调高减少误检但增加漏检调低反之--size是推理输入边长越大精度越高、速度越慢。我一般先用默认值跑一遍看整体效果再针对具体视频调这两个参数。如果源码没有暴露这些参数就去主脚本里找对应的变量名通常在文件头部集中定义改起来不费事。跑通后先看输出视频有没有正常生成、框有没有画在行人身上这是判断环境是否正常的第一个信号。3. 参数调优与效果验证让检测框稳下来3.1 置信度与 NMS 阈值的配合检测框抖动、同一个行人出现多个重叠框是这类 demo 最常见的观感问题。根源在后处理置信度阈值决定哪些框留下非极大值抑制NMS阈值决定重叠框怎么合并。两个参数要配合调单独调一个往往按下葫芦浮起瓢。我的经验是先固定 NMS 阈值在 0.45 左右再扫置信度。置信度从 0.5 往下降观察漏检是否减少、误检是否可接受如果同一个行人身上出现两三个框说明 NMS 阈值偏高适当降到 0.3 到 0.4 之间。源码里这两个值通常是硬编码的找到后改成命令行参数或者配置文件读取方便反复试。下面是一个把后处理参数抽出来的写法参考# 后处理先按置信度过滤再做 NMS 合并重叠框 def postprocess(boxes, scores, conf_thres0.4, nms_thres0.45): keep scores conf_thres # 置信度过滤低于阈值的框直接丢 boxes, scores boxes[keep], scores[keep] indices nms(boxes, scores, nms_thres) # 合并重叠框 return boxes[indices], scores[indices]逻辑说明conf_thres控制召回与误检的平衡nms_thres控制重叠框的合并力度。参数没有万能值和视频分辨率、行人密度强相关。密集场景下 NMS 阈值要调低否则相邻行人会被误合并成一个框稀疏场景可以适当调高减少框的抖动。3.2 输入尺寸对速度与精度的影响输入尺寸是另一个关键旋钮。源码默认尺寸往往偏小跑得快但小目标行人容易漏。把尺寸调大远处行人的检测率会明显提升代价是帧处理时间上升。我一般按视频分辨率来定720p 的视频用 640 输入基本够用1080p 且行人较远时考虑 800 或 960。验证方法很直接截取视频里行人最远、最小的那一帧单独跑检测看框能不能稳定出现。如果远处行人时有时无就是输入尺寸不够或者置信度阈值偏高。这里有个容易忽略的点——缩放方式。直接拉伸会改变行人宽高比影响检测效果常见做法是保持比例缩放后做填充。源码如果用的是直接 resize可以改成 letterbox 方式效果会有肉眼可见的提升。3.3 用固定片段做回归验证调参最怕改了一个参数、效果好了改另一个又退回去最后不知道哪个组合最优。我的习惯是截取一段 10 到 20 秒的固定片段包含远中近三种距离的行人每次调参都跑这段人工数一下漏检和误检数量记在表格里。参数组合置信度NMS输入尺寸漏检数误检数默认0.50.45416偏多少组合 A0.40.4640中等中等组合 B0.350.35800少偏多这张表不用追求精确目的是让调参有据可依而不是凭感觉来回改。跑完几轮后选一个漏检和误检都能接受的组合固定下来再拿完整视频验证一遍。固定片段验证的好处是可复现换台机器、换个时间跑结论一致。4. 避坑与排查五个真实翻车点4.1 输出视频打不开或只有几帧现象脚本跑完没报错但输出视频用播放器打开是黑屏或者只有开头几帧。原因通常是写视频时的编码器或帧尺寸不匹配OpenCV 的VideoWriter对编码格式和尺寸很挑剔宽高必须是偶数编码器要和文件后缀对应。解决检查VideoWriter的 fourcc 设置.mp4用mp4v尺寸从原视频读取后确保是偶数必要时做一次裁剪。另外确认写循环里write调用在检测之后别把空帧写进去。4.2 第一次运行卡在模型下载现象运行后长时间无输出终端停在下载进度。原因是预训练权重默认从网络拉取网络不稳就会卡住。解决看源码里权重路径的变量手动把权重文件放到对应目录或者改成绝对路径。如果源码没有提供权重下载地址就找同类模型的公开权重替换注意输入尺寸和预处理要和权重匹配否则检测结果会离谱。4.3 检测框整体偏移现象框画出来了但位置和行人对不上整体偏上或偏左。原因是预处理时的缩放和填充没有在绘制阶段还原坐标还停留在模型输入尺度上。解决找到坐标映射的代码确认缩放比例和填充偏移都参与了还原。常见错误是只除了缩放比例、忘了减填充偏移这种偏移在图像边缘最明显。4.4 CPU 上跑得慢到无法接受现象每帧处理好几秒视频跑完要几个小时。原因是模型默认在 CPU 上推理且输入尺寸偏大。解决先降输入尺寸到 416 或 320 看速度是否可接受再考虑换轻量模型。如果机器有独立显卡确认推理框架是否装了对应版本很多框架默认装的是 CPU 版需要单独装 GPU 版。这一步翻车的人不少装完以为能用显卡实际还在跑 CPU。4.5 换视频后效果断崖式下降现象demo 视频效果不错换成自己的监控视频后漏检严重。原因是预训练模型的训练数据视角和你的视频差异大俯视角、逆光、夜间都是典型难点。解决先确认视频本身亮度正常必要时做预处理增强再调低置信度阈值看漏检是否改善如果仍不行说明模型和场景不匹配这时候要么换模型要么考虑用自己场景的数据做微调源码包本身不覆盖这一步。5. 从 demo 到可用加一个简单的越线计数跑通检测只是起点真正有用的是在检测基础上做业务逻辑。拿园区门口场景举例最常见的需求是统计进出人数实现方式是在画面里画一条虚拟线记录检测框中心点跨越线的方向。这个逻辑不复杂但有几个细节决定成败。先定义线的位置和方向。假设线是水平的中心点从上往下跨记为进入从下往上记为离开。每个行人需要一个稳定的 ID 才能判断跨越简单做法是用检测框中心点的最近邻匹配做简易跟踪不追求精度够用就行。下面是一个计数逻辑的骨架# 简易越线计数按中心点纵坐标与虚拟线比较配合最近邻匹配维持 ID tracked {} # id - 上一次的中心点 count_in, count_out 0, 0 line_y frame_height // 2 # 虚拟线位置按场景调整 for det in detections: cx, cy center_of(det) matched_id match_nearest(tracked, (cx, cy)) # 最近邻匹配阈值内视为同一人 if matched_id is not None: prev_y tracked[matched_id][1] if prev_y line_y cy: count_in 1 # 从上往下跨线 elif prev_y line_y cy: count_out 1 # 从下往上跨线 tracked[matched_id or new_id()] (cx, cy)逻辑说明line_y是虚拟线的纵坐标按实际画面调整放在行人必经的位置match_nearest用距离阈值判断是不是同一个人阈值太小会导致 ID 频繁切换、重复计数太大则会把相邻行人混为一人。这个骨架的局限很明显行人并排走或者交叉时最近邻匹配会出错计数偏差随之而来。要做得稳得换更正规的跟踪算法但那已经超出这份源码包的范围了。验证计数是否靠谱我的办法是拿一段已知人数的视频跑一遍人工数实际进出数和程序结果对比。偏差在可接受范围内再上真实场景。这里有个血泪经验虚拟线别放在画面边缘行人刚进画面时检测框还不稳定容易误触发计数放在画面中段、行人完整可见的位置结果会稳很多。从那以后我每次拿到这类检测源码包都先跑固定片段、记参数表、再上业务逻辑三步走完才敢往真实视频上套。希望帮到你。本文还有配套的精品资源点击获取
