简介面向计算机视觉开发者的高空抛物实时检测项目基于C与OpenCV技术栈融合ViBe背景建模与SORT多目标跟踪算法可应用于智慧社区、工地监管等场景实现抛物目标的自动发现、轨迹判定与告警信息生成。整个源码包在Visual Studio 2019和OpenCV 4.8的x64 Release环境下测试运行共61个文件包含源程序、头文件、动态链接库、可执行文件、演示视频、辅助脚本和使用文档压缩后整体约245.56MB。资源内部细分为工程配置、核心算法、工具脚本与演示素材等部分其中卡尔曼滤波、轨迹预测、重力投影等模块均有独立源码方便按需查阅和二次开发。另附多个实拍演示视频和测试数据生成脚本可直观对比算法效果并能快速生成自己的验证数据。目前已有308人学习浏览目录层级清晰搭配使用说明即可完成环境搭建与程序运行适合需要完整参考方案或继续优化算法的研发人员。1. 高空抛物实时检测监控画面里的“小目标”为什么难抓小区高空抛物检测在工程上跟人脸、车牌这类识别完全不同抛物目标小、速度快、背景持续变化固定枪机画面里“掉下来的东西”往往只有几十个像素。直接上 YOLO 这类目标检测模型小目标漏检率高还得部署 GPU而 C OpenCV 的经典双引擎方案——ViBe 背景建模负责把运动前景从背景里抠出来SORT 多目标跟踪负责把散落的检测框串成轨迹——只靠 CPU 就能贴近实时。这个组合解决的是“先找出来、再跟得住”两条线的问题也是这个标题背后的源码、演示视频和项目说明真正要落地的核心。2. ViBe 背景建模先把“掉下来的东西”从画面里抠出来2.1 先分清这个 ViBe 不是 vibe coding今年编程圈到处在聊 vibe coding检索“vibe”很容易被带到 AI 编程工具那条线上去。高空抛物检测里的 ViBe 是 Visual Background Extractor视觉背景提取器由 Olivier Barnich 和 Marc Van Droogenbroeck 提出2011 年正式发表于 IEEE Transactions on Image Processing2009 年的会议版本已经在学界流传。它属于背景差分领域和帧差法、混合高斯模型MOG2站在同一条赛道上。ViBe 的核心思想一句话就能说清为每个像素维护一个容量为 N 的历史样本集当前帧的像素值和这 N 个样本逐个比较如果统计出足够多的“距离小于阈值 R”的匹配样本就判为背景否则判为前景。它比帧差法强在能“记住”历史比 MOG2 强在参数少、计算量低而且样本更新带随机性——每次更新不仅可能换掉旧样本还可能把新样本扩散到八邻域这让它在树叶晃动、光线缓慢变化时非常稳也是露天阳台场景选它的核心原因。选它做高空抛物还有两个实际理由监控相机是固定的背景建模天然成立抛物目标尺寸小、但属于连续运动的前景背景差分对这种“小且持续运动”的目标不敏感。最后它不需要任何标注训练数据拿到第一帧就能初始化这对现场快速调试太重要了——演示视频能跑通换到现场相机角度改几个参数就能重新初始化成本远低于重新训一个检测模型。2.2 四个必调参数样本数、匹配阈值、最少匹配数与更新率工程上真正要调的就四个参数调明白能覆盖九成现场问题。参数常见取值作用调大 / 调小的后果样本数 N16~20每个像素维护的历史样本数量调大更稳但内存涨、收敛慢调小容易闪烁误检距离阈值 R15~20灰度判定“匹配”的最大像素差调大好把噪声当背景漏检调小噪声全变前景最少匹配 #min2~3命中多少个样本才认作背景调大前景易被吞调小噪点多更新率 φ16~32背景更新抽样的分母调大前景残留久能跟慢目标调小残留短慢目标会被并入背景注意 R 和 #min 对灰度图和彩色图的表现不一样。灰度直接比单通道差值彩色图三个通道分别比任意一个通道差值超 R 就算不匹配。高空抛物场景我一般用彩色图按通道比因为抛物物体和它的阴影在灰度下常常是同一个量级彩色能多一层区分代价是逐像素比较的计算量变成三倍但 720p 分辨率下依然可接受。2.3 OpenCV 没内置 ViBe一个可落地的 C 最小实现OpenCV 的 background subtractor 接口只内置了 MOG2 和 KNNViBe 需要自己实现或移植。核心就三步用第一帧初始化样本集、逐像素分类、随机更新样本。下面是主流程骨架。// vibe.h 核心类 #include opencv2/opencv.hpp #include vector class ViBe { public: ViBe(int N 20, int radius 20, int minMatch 2, int updateRate 16) : N_(N), radius_(radius), minMatch_(minMatch), updateRate_(updateRate) {} void init(const cv::Mat firstFrame) { samples_.resize(N_); for (int i 0; i N_; i) firstFrame.copyTo(samples_[i]); // 第一帧全填为背景样本 } void apply(const cv::Mat frame, cv::Mat fg) { fg cv::Mat::zeros(frame.size(), CV_8UC1); for (int y 0; y frame.rows; y) { for (int x 0; x frame.cols; x) { // 逐个样本比较统计匹配次数 int match 0; for (int i 0; i N_; i) { cv::Vec3b p frame.atcv::Vec3b(y, x); cv::Vec3b s samples_[i].atcv::Vec3b(y, x); if (std::abs(p[0] - s[0]) radius_ std::abs(p[1] - s[1]) radius_ std::abs(p[2] - s[2]) radius_) match; } if (match minMatch_) { fg.atuchar(y, x) 255; // 判为前景不更新样本 } else { // 背景点以 1/updateRate_ 概率替换随机一个样本 if (rand() % updateRate_ 0) { int idx rand() % N_; frame.row(y).col(x).copyTo(samples_[idx].row(y).col(x)); } } } } } private: int N_, radius_, minMatch_, updateRate_; std::vectorcv::Mat samples_; };代码逻辑不复杂但有两个细节直接影响效果一是背景点更新时才做随机替换前景点不更新样本否则抛物物体从运动变静止后会被快速吸收进背景二是真正生产版本要把逐像素双循环改成按行指针遍历并去掉at的边界检查否则 1080p 下性能会很难看。更好的做法是把分类和更新拆成两个函数配合cv::parallel_for_做行级并行顺手把rand()换成线程安全的随机数生成器。提示这只演示了核心逻辑。完整实现还需要邻域样本扩散更新、首帧多帧初始化、以及把更新操作限定在“背景像素的随机抽样集合”上否则前景边缘会出现明显的黑白噪声带。2.4 形态学处理把树叶、飞鸟和小噪点排除在外ViBe 输出的前景掩码直接喂给跟踪器会有大量零散噪点。我一般先用cv::medianBlur去椒盐噪声再用开运算断开细小连接最后提取连通域按面积过滤。cv::medianBlur(fg, fg, 5); cv::morphologyEx(fg, fg, cv::MORPH_OPEN, cv::getStructuringElement(cv::MORPH_RECT, cv::Size(3, 3)));过滤条件里面积下限通常设为画面总像素的 0.01%~0.02%上限设为总像素的 30% 左右宽高比限制在 0.2~5.0防止把横穿画面的汽车压扁成抛物。这些数值会出现在项目说明的 config 文件里现场调试时优先动这里而不是去改 ViBe 的 N 和 R——前者是过滤策略回退成本低后者直接影响建模改错会让整段视频的背景重建。3. SORT 多目标跟踪把检测框串成一条条轨迹3.1 跟踪解决的是“这个框是谁”的问题ViBe 输出的每个前景连通域只是一个孤立的检测框下一帧这些框可能移动了几个像素也可能因为遮挡短暂消失。如果不做关联每一帧的框都是无身份的新目标一根筷子掉下来能报十次。SORTSimple Online and Realtime Tracking就是来解决这个问题的它的全名已经说明定位简单、在线、实时。再次提醒一句SORT 跟 C 标准库里的std::sort没有任何关系std::sort是排序算法SORT 是跟踪框架。检索“sort函数”“c加加中sort函数的用法”进来的朋友别被同名关键字带偏。SORT 的组成只有四块卡尔曼滤波预测、IoU 代价计算、匈牙利算法匹配、轨迹生命周期管理。为什么不用外观特征因为抛物物体小、不像人脸有稳定纹理外观匹配在这个场景里容易失效位置预测加框重叠度在固定摄像头下已经足够。3.2 卡尔曼滤波在 SORT 里只维护一个匀直模型SORT 对每条轨迹维护一个 7 维状态中心坐标 (x, y)、宽高比、高度以及各自的速度分量。运动模型默认是匀速直线。这对抛物物体其实违背物理——真抛物线是匀加速但在 25fps 监控帧率下相邻帧之间目标位移只有几个像素匀速模型的预测误差远小于检测噪声所以工程上依然普遍够用。卡尔曼滤波在这里的作用不是预测得多准而是平滑。它给跟踪器一个“目标应该在哪”的先验匹配时用它和检测框之间的 IoU 当作相似度比直接用上一帧框稳定得多尤其是目标经过楼层遮挡、短暂跳变时。Q 和 R 两个噪声矩阵按像素单位给经验值即可Q 取 1e-2 量级R 取 1e-1 量级实测在高清画面下不需要精细标定。3.3 轨道结构体与 IoU 匹配的实现先定义一个最小可用的跟踪目标结构以及 IoU 计算// Track 结构体每个跟踪目标维护自己的状态 struct Track { int id; int age 0; // 已存活帧数 int hits 0; // 成功匹配帧数 int noMatch 0; // 连续未匹配帧数 cv::KalmanFilter kf; cv::Rect box; // 当前预测框 }; // 两个框的交并比 double iou(const cv::Rect a, const cv::Rect b) { cv::Rect inter a b; double ia inter.area(); if (ia 0) return 0.0; double ua a.area() b.area() - ia; return ia / ua; }匹配流程先对每个存活轨迹用卡尔曼预测出候选框然后构建代价矩阵cost[i][j] 1 - iou(track_i, det_j)交给匈牙利算法求最小总代价的匹配。OpenCV 本身没暴露匈牙利算法接口常见做法是把 munkres-cpp 单文件拷进项目几十行代码无第三方依赖。匹配完成后的状态机很简单匹配上的轨迹更新卡尔曼状态hitsnoMatch清零没匹配上的轨迹noMatch超过maxAge就删除没匹配上的检测新建轨迹但先不对外输出等hits超过minHits再宣告存在防止单帧误检生成鬼影轨迹。3.4 高空抛物场景下 SORT 的参数经验值参数经验值说明maxAge5~10 帧抛物经过遮挡的时间往往小于 0.5s给 10 帧够用minHits3~5 帧太小鬼影多太大报警延迟明显IoU 匹配阈值0.3~0.5低于此值的匹配一律拒绝卡尔曼噪声 Q / R1e-2 / 1e-1 量级按像素单位缩放具体见项目说明中的标定段minHits 和 maxAge 直接决定报警延迟。25fps 下 minHits5 意味着目标要连续检测 5 帧0.2 秒才建立正式轨迹对一个从 20 层掉落、全程约 1.5 秒的目标来说延迟可以接受。帧率掉到 15fps 时这两个值要相应缩小否则轨迹还没建完目标已经落地了。4. C OpenCV 工程实现把 ViBe 和 SORT 串成一条流水线4.1 完整流水线读帧、差分、连通域、跟踪一个典型的主循环流程如下。// main.cpp 主流程 cv::VideoCapture cap; cap.open(rtspUrl); // 或视频文件路径 cap.set(cv::CAP_PROP_BUFFERSIZE, 1); // 只保留最新帧降低延迟 cv::Mat frame, fg; cap frame; ViBe vibe; vibe.init(frame); // 第一帧初始化背景样本 while (cap.read(frame)) { vibe.apply(frame, fg); // 1. 背景差分出前景掩码 preprocess(fg); // 2. 中值滤波 开运算 auto dets extractBoxes(fg); // 3. 连通域过滤得到检测框 tracker.update(dets); // 4. SORT 关联更新轨迹 for (auto t : tracker.tracks) { if (t.hits minHits isFalling(t.history)) { cv::rectangle(frame, t.box, cv::Scalar(0, 0, 255), 2); // 画报警框 // 5. 轨迹判定通过后触发报警逻辑 } } }提取检测框时我习惯用cv::connectedComponentsWithStats而不是findContours前者一次调用能同时拿到每个连通域的面积、外接矩形和质心省掉一轮轮廓遍历代码也干净。cv::Mat labels, stats, centroids; int n cv::connectedComponentsWithStats(fg, labels, stats, centroids); for (int i 1; i n; i) { // 0 号是背景 int area stats.atint(i, cv::CC_STAT_AREA); if (area minArea || area maxArea) continue; int x stats.atint(i, cv::CC_STAT_LEFT); int y stats.atint(i, cv::CC_STAT_TOP); int w stats.atint(i, cv::CC_STAT_WIDTH); int h stats.atint(i, cv::CC_STAT_HEIGHT); dets.push_back(cv::Rect(x, y, w, h)); }注意stats的类型是CV_32S必须用atint读取用atuchar读出来是错误值这是接入 OpenCV 时最容易踩的坑之一。同理cv::Rect的宽高要用width、height别和cols、rows混用否则切片和 ROI 提取经常边界越界。4.2 抛物判定轨迹方向、速度与起点区域三重约束ViBe 加 SORT 只告诉你“有东西在动”要报告“高空抛物”需要再加判定。工程上常用三重约束方向约束轨迹质心的 y 坐标在连续 N 帧内单调递增画面坐标 y 向下为正即持续下落速度约束相邻帧平均位移超过阈值过滤掉云影、窗帘这类缓慢运动区域约束轨迹起点落在楼层窗台 ROI 内落点穿过警戒线。// 方向与速度判定history 为最近若干帧的质心 bool isFalling(const std::dequecv::Point2f hist, int minFrames 4) { if (hist.size() minFrames 1) return false; int downCount 0; for (size_t i 1; i hist.size(); i) { float dy hist[i].y - hist[i - 1].y; if (dy 2.0f) downCount; // 每帧至少下移 2 像素 else if (dy -2.0f) return false; // 出现明显回弹直接否决 } float totalDrop hist.back().y - hist.front().y; return downCount minFrames totalDrop 50.0f; }方向判定要防一个经典误报楼下有人走动时轨迹 y 可能先升后降或者抛物在画面里只是横向飘过。所以“回弹即否决”和“总位移下限”要同时写死这两个数值对应实际场景就是“至少下落 50 像素且在 4 帧内不回弹”。像素与真实米数的换算要靠标定项目说明里一般会给一条参考警戒线报警逻辑里还要把它画在叠加画面上方便现场核对。4.3 编译环境与运行依赖安装 OpenCV 的常见坑工程以源码压缩包发布时接收方最大的门槛是环境。Windows 上最常见的是microsoft visual c redistributable版本不对导致启动即报 DLL 缺失其次是 OpenCV 预编译库的 VC 版本和本地编译器不匹配。CMake 配置如下cmake_minimum_required(VERSION 3.16) project(dropper) set(CMAKE_CXX_STANDARD 17) find_package(OpenCV REQUIRED) add_executable(dropper main.cpp vibe.cpp sort.cpp) target_link_libraries(dropper ${OpenCV_LIBS})构建顺序建议先按 opencv 安装教程把 OpenCV 配好用官方 sample 确认cv::imread能跑再编译本项目把环境变量隔离出来。用 VSCode 配好 C/C 环境再开 CMake 工程能少一半环境报错。摄像头取流上“opencv 打开rtmp失败”是高频率搜索词——本质是 OpenCV 的 VideoCapture 依赖 FFmpeg拉 RTSP/RTMP 失败时先看cv::getBuildInformation()里有没有 FFmpeg 支持再检查协议串和端口顺序不要反。另外把读取和 ViBe 计算拆到两个线程用std::mutex加双缓冲能明显降低丢帧率这是 C 多线程在图像流水线里最实用的一档做法比在单线程里拼命优化像素循环收益更大。5. 用模拟抛物视频做回归验证几个把参数调稳的具体手法调试阶段最忌讳对着真实视频反复试参数因为真实抛物不可控、无法复现。我一般先录 3~5 段模拟视频从不同楼层扔纸团、矿泉水瓶、塑料袋各几次白天和黄昏各一组再标出每段的抛物起始帧和结束帧。然后固定参数跑完整个视频只统计两件事检出率——应当报出的抛物里实际报出了多少误报率——没有抛物时误报了多少次。演示视频能稳定通过只是起点这个回归集才是判断参数改得对不对的依据。调参按固定顺序走能省大量时间先调连通域过滤的minArea把树叶、飞鸟排干净再调 SORT 的minHits平衡延迟与鬼影然后调 ViBe 的updateRate解决“背景吸收慢目标”最后才动radius_和minMatch。一个常见误用是把 ViBe 更新率调得过大去抑制误报结果抛物物体会在下降中途被当成背景而断轨。正确做法是让 SORT 的maxAge容忍断轨重连比把背景调“迟钝”安全得多。进阶一点的手法是把轨迹可视化叠加到视频上把每条轨迹的历史坐标点用cv::polylines画成尾迹颜色按 id 区分。尾迹比检测框直观得多——尾迹断裂说明 ViBe 前景不稳定尾迹方向总变说明检测框在抖尾迹正常但报警没触发问题就出在isFalling的位移阈值上。这套“回归集 尾迹可视化 轨迹统计”的三件套比任何日志都能更快定位问题在哪一环。本文还有配套的精品资源点击获取