前几个月我完整搭了一套基于 YOLOv8 的火焰与烟雾检测系统内部代号就叫 FireNet。起因是一个模拟园区项目里需要给已有摄像机加一道“自动盯梢”能力几十路画面连续滚动值班人员不可能每帧都盯住尤其夜里或者节假日火苗刚起、烟雾刚冒的那几十秒往往就是能不能控制住火情的关键窗口。项目目标很直白——给定任意一路监控画面系统能在数秒内识别出火和烟给出位置框和置信度并且把结果推到一个可视化的监控页面上形成完整闭环而不是只停留在“训练完模型打印个 mAP”的阶段。这篇文章把我整个落地的过程拆开讲从数据怎么搜集、标注规范怎么定到训练参数怎么选、模型怎么导出再到推理服务和 Web UI 怎么对接最后把现场实战中踩过的误检、显存、坐标错位这些坑也一并复盘。内容适合两类人一类是刚接触 YOLO 系列、想用一个完整项目把训练到部署链路走通的入门者另一类是已经在做安防视觉集成、正头疼火焰烟雾检测误报率太高的开发者。全程没有炫技只有能照做的路径。1. 项目缘起为什么火焰烟雾检测非要做以及为什么选 YOLOv81.1 需求场景和系统边界先说场景。这个项目的目标场景是普通工业环境的视频监控最常见的就是厂房、仓库、配电房外围、垃圾堆放区和园区主干道。这些地方摄像头早就装好了但摄像头本身没有“看懂画面”的能力传统方案里全靠人盯大屏而人盯屏幕的注意力极限大概只有几十分钟。更关键的是火焰和烟雾在监控画面里的表现往往很含蓄——初期可能只是一个小火苗或者一片淡淡的烟等肉眼能明显看出来时往往已经烧了有一阵了。所以系统的最基本功能定位是输入任意一张监控画面或一段视频流输出火焰和烟雾的目标框、类别和置信度再叠加一层报警逻辑比如“连续 N 帧都检测到火焰”之后才提示值班人员避免偶发误报打扰。这套能力并不需要替代消防主机它的价值在于提前量消防烟感和温感通常要到温度浓度到了一定阈值才触发而视觉检测可以在发现可视烟雾或明火的数十秒内就发出预警。我最初把边界卡得很死只检测两类目标——火焰和烟雾不做火灾等级评估不做火势蔓延预测。原因很简单目标检测模型做的是“定位分类”要是硬塞太多语义判断就会把系统拖进不确定的复杂度里。把边界切小后面训练和调优都会省很多事。1.2 选型理由YOLOv8 在这个任务上的比较优势技术选型上我对比过三条路线传统视觉算法、两阶段检测器、YOLO 系列单阶段检测器。传统视觉算法基本是颜色阈值加运动检测原理是用 HSV 颜色空间提取暖色区域再用帧间差分判定是否运动。说实话用来做火焰检测能出一点效果但限制非常大火焰颜色跨度大低温焰偏红黄、高温焰偏蓝白烟气又是半透明的背景一旦有阳光、车灯、红色设备就会大量误报。我不太建议把它当作主力方案只适合作为极简单场景的辅助判断。两阶段检测器比如早期的 Faster R-CNN精度潜力不错但推理速度在视频流场景下不太友好一台普通工作站跑一路 1080P 都费劲更别说后续还要并行多路视频。工程上很难接受。最后落在 YOLOv8 上核心原因是它在精度、速度和工程生态之间平衡得很好。YOLOv8 是单阶段 anchor-free 架构推理时一次前向就直接输出类别和框不像两阶段那样先提候选再二次分类。同时它的训练框架非常成熟数据组织、增强策略、评估指标全部内置权重也支持从 COCO 预训练模型迁移过来对火焰烟雾这种小数据集很友好。还有一点很实际YOLOv8 官方提供了 n/s/m/l/x 多个尺寸的版本可以根据部署硬件灵活切换不像某些框架只能靠调网络结构。1.3 全链路架构一览FireNet 的最终链路分四层数据层收集公开样本和自采数据统一标注成 YOLO 格式划分训练集与验证集。训练层用预训练权重微调监控 mAP 和召回率筛选最优权重文件导出 ONNX 格式。推理层写一个常驻后台服务读取本地视频、RTSP 流或单张图片完成预处理、模型推理、后处理和报警判断。可视化层后端通过 WebSocket 把检测结果和实时帧推到浏览器页面前端完成画面展示、检测框叠加、历史统计和报警记录。整体跑下来单路视频在普通显卡上能做到 30 FPS 以上的检测速度1080P 画面从输入到结果推送到前端延迟在 200 毫秒以内四路视频并行也还能稳稳运行。下面我按链路顺序把每一层的实操细节和踩坑过程写出来。2. 数据冷启动火焰和烟雾样本从哪里来、怎么整理成可用数据集2.1 数据来源的合并与去重策略火焰烟雾检测数据集的第一个难点是样本稀缺。日常生活里随手拍的照片不少但真正适合模型训练的监控视角火灾图像并不像通用物体那样随手就能攒几万张。我采用的是“公开数据集 自采数据补充”的组合方式。公开部分我把多个常见火灾检测数据集合并到一起筛选出画面清晰、目标明确的图像。合并时有个坑要注意不同来源的数据集标注口径不一致有的把 smoke 标成/smoke有的把火焰和烟雾合成一个类有的坐标格式是归一化的有的是像素坐标。我统一写了一段脚本把所有标注转成 YOLO 需要的格式——每行一个目标格式是“类别ID 中心点x 中心点y 宽 高”前四个数值全部归一化到 0 到 1 之间。合并去重不能只看文件名因为同一个视频抽帧出来的不同图片可能高度相似。我用感知哈希算了一遍相似度把相似度超过阈值的帧直接丢弃避免训练集和验证集之间存在“近亲”数据否则指标虚高到后期部署才发现根本扛不住真实场景。自采部分更贴近真实部署环境。我找了几台不同朝向的摄像机在安全条件下拍摄了纸箱燃烧、油盘火焰、烟雾弹释放等场景再把画面抽帧选出来。这一块不需要特别多三五百张就够但视角要和最终部署场景尽量一致比如都是俯视或平视的监控视角这样模型泛化才有保障。2.2 类别定义与标注规范这个环节我非常建议多花时间。标注质量直接决定模型上限与其训练时反复调参不如一开始把标注规范钉死。FireNet 只定义两个类别fire画面中明显可见的火焰区域包括明火和带火焰的灼烧物。smoke烟雾区域包括白烟、黑烟和半透明烟羽但排除水蒸气、霾和雾。标注时候容易纠结的场景我在项目里定了几条硬性规则火和烟同时出现且区域重叠时分别标两个框框可以重叠但 fire 的框优先级高。如果火焰周围有一大圈烟雾fire 只框住火焰核心区域smoke 框住可见烟的范围。目标太小且无法确定具体边界的不标。比如 640 分辨率下小于 10×10 像素的模糊烟团标了反而会引入大量噪声。半透明烟雾的边界不确定时以肉眼可见轮廓为准宁大勿小但要保证框内烟雾占比超过一半。说实话烟雾的标注最难。它没有清晰的边缘人眼判断都有分歧。我的处理办法是找两个同学同时标同一批图不一致的地方逐张讨论最终留下共识样本。数量不需要特别多但每一张都要经得起推敲。2.3 数量配平与数据增强整理完之后训练集总共约 6000 张其中纯火焰样本约 2400 张纯烟雾样本约 2000 张火烟共存样本约 1000 张负样本约 600 张。负样本是指那些没有火也没有烟、但容易误判的图包括阳光直射下的橙色设备、红色卡车、傍晚的晚霞、路灯灯光、夜间车灯这些图对压制误报至关重要。类别分配上fire 和 smoke 的总标注框大约保持在 5:4整体不至于严重失衡。负样本占比控制在 10% 到 15%太少了起不到压制误报的作用太多了模型会变得过度保守真实火焰反而漏报。数据增强方面YOLOv8 训练时内置了 Mosaic、随机翻转、HSV 扰动、仿射变换等一系列增强策略我基本都保留但额外做了两个调整。一是把 HSV 的饱和度扰动范围加大因为火焰颜色在不同燃烧阶段差异极大黄色、橙色、红色、白色都要覆盖到二是关闭了随机旋转 90 度这类大角度增强因为监控画面里的火焰永远是“向上燃烧”的旋转 90 度后的火焰形态在现实中几乎不存在强行增强只会让模型学到错误先验。训练集和验证集按照 8:2 划分划分时确保来自同一个视频的帧尽量放到同一侧。这是针对视频抽帧数据的通用经验不然同源帧同时出现在训练集和验证集里验证指标会好看得失真。3. 训练细节让 YOLOv8 在自建数据上稳定收敛的完整过程3.1 训练环境与硬件条件训练用的机器不是多 fancy 的服务器就是一台带 8GB 显存消费级显卡的工作站配合 32GB 内存。软件环境是 Python 3.10、PyTorch 2.x、CUDA 11.8YOLOv8 的官方开源实现推理阶段额外用 ONNX Runtime。这种配置很接近大多数开发者手头能拿到的设备所以对个人或小团队复现是有参考价值的。如果显存只有 6GB可以把模型从 s 换成 n输入尺寸保持 640依旧能训练只是最终精度会有小幅下降。3.2 数据集配置文件的编写YOLOv8 训练前需要准备一个数据集配置文件指定类别数量和路径。我是这样写的path: ./datasets/flame_smoke train: images/train val: images/val nc: 2 names: 0: fire 1: smoke注意 train 和 val 这里写的是相对 path 的路径。图片放在 images/train 和 images/val 下对应的标签放在 labels/train 和 labels/val 下。YOLOv8 靠文件名的前缀自动匹配图片和标签所以图片 a.jpg 对应的标签必须叫 a.txt这个对应关系错一个字符都会导致训练时读取不到标签。3.3 模型选型与训练参数决策模型我选的是 yolov8s.pt 作为起点也就是 COCO 预训练的小尺寸版本。为什么不选 n 或 l这里解释一下n 尺寸在火焰这种目标形态不够“标准化”的任务上精度偏低边缘部署除外l 尺寸精度更高但推理速度和显存占用都上来了普通工作站跑一路视频还好多路并行就会紧张。s 是性价比最稳的选择适合“一台机器盯四路画面”这种典型场景。训练命令我直接用了 YOLOv8 的命令行格式yolo detect train \ dataflame_smoke.yaml \ modelyolov8s.pt \ epochs120 \ imgsz640 \ batch8 \ device0 \ patience20 \ project./runs/FireNet \ seed42几个关键参数单独说明imgsz640输入分辨率。640 是速度和精度的折中。但火焰烟雾里存在不少小目标特别是早期小火苗和远处淡淡的烟640 分辨率下容易漏检。我验证时会额外用 imgsz896 跑一遍如果小目标 mAP 明显更高就在导出模型时也按 896 导出推理成本增加但换取漏检率下降。batch88GB 显存下YOLOv8s 配 640 输入batch16 会有一半概率爆显存。我试过梯度累积等效放大 batch但实际发现火焰数据并不需要特别大的 batch8 足以稳定收敛所以就没有强行堆。patience20连续 20 个 epoch 验证集指标不提升就提前终止。这个参数防止过拟合也能节省时间。我的训练跑到第 96 个 epoch 就自动停了说明第 76 个 epoch 之后基本没有明显提升。优化器保持官方默认的 SGD 配置momentum0.937、weight_decay5e-4。自适应优化器 AdamW 前期收敛快但火焰烟雾这种小数据集上后期容易震荡SGD 更稳。3.4 训练曲线分析和权重筛选训练过程中我重点盯三个指标而不是只盯 loss验证集 precision、recall、mAP50。火焰检测场景里漏报比误报可怕得多所以我对 recall 的要求更高如果 recall 和 precision 冲突我优先保 recall。最终 s 模型在验证集上的指标大约是precision 0.81、recall 0.86、mAP50 0.84、mAP50-95 0.56。对一个只有 6000 张图的小数据集来说这个结果已经能进入实用阶段了。训练结束后runs/FireNet 目录下会生成多个权重文件我选的不是最后一个而是 best.pt——也就是验证集 mAP50-95 最高的那一个。实际部署时可以先下载 best.pt 到本地跑几段真实场景视频如果漏报明显就换倒数第二好的权重对比一下有时候 mAP 略低但 recall 更高的权重在真实场景里反而更好用。模型导出我用的是yolo export modelruns/FireNet/train/weights/best.pt formatonnx dynamicFalse imgsz640导出后的 best.onnx 才是推理服务真正加载的文件。这里 dynamic 参数我故意设成 False固定输入尺寸 640×640。动态尺寸虽然灵活但推理时会引入额外的显存分配开销多路视频场景下容易造成显存碎片化固定尺寸更稳。4. 推理服务预处理、后处理和多路视频流接入的工程化处理4.1 Letterbox 预处理与坐标映射模型训练用的是 640×640 的方形输入但监控画面基本都是 16:9直接暴力拉伸会破坏目标形状检测精度会掉。正确做法是等比例缩放后做填充也就是常说的 letterbox。我用了一段自写的预处理函数def letterbox(img, new_shape(640, 640), color(114, 114, 114)): h, w img.shape[:2] ratio min(new_shape[0] / h, new_shape[1] / w) nw, nh int(round(w * ratio)), int(round(h * ratio)) dw, dh (new_shape[1] - nw) // 2, (new_shape[0] - nh) // 2 resized cv2.resize(img, (nw, nh), interpolationcv2.INTER_LINEAR) canvas np.full((new_shape[0], new_shape[1], 3), color, dtypenp.uint8) canvas[dh:dh nh, dw:dw nw] resized return canvas, ratio, dw, dh这个函数返回的 ratio、dw、dh 必须保存下来后处理时把模型输出的归一化坐标映射回原图就需要它们。具体的映射公式是x_center (x_center - dw) / ratio y_center (y_center - dh) / ratio width width / ratio height height / ratio这个映射看起来简单但也是项目里最容易翻车的环节之一。后面第 6 章我会专门复盘一次坐标错位的完整排查过程。4.2 ONNX Runtime 推理与 NMS 后处理YOLOv8 导出的 ONNX 模型输出张量形状是 (1, 4类别数, 8400)。8400 是模型在三个不同尺度特征图上生成的预测框总数每个候选框对应一个长度为 42 的向量——前 4 个是框坐标后面是两类目标的置信度。我推理时的关键代码如下import onnxruntime as ort import numpy as np import cv2 session ort.InferenceSession( best.onnx, providers[CUDAExecutionProvider, CPUExecutionProvider], ) def detect(frame): canvas, ratio, dw, dh letterbox(frame) blob canvas.astype(np.float32) / 255.0 blob np.transpose(blob, (2, 0, 1))[None] pred session.run(None, {session.get_inputs()[0].name: blob})[0] pred np.transpose(pred, (0, 2, 1))[0] boxes, scores, labels [], [], [] for row in pred: cls_scores row[4:] cls_id np.argmax(cls_scores) cls_conf cls_scores[cls_id] if cls_conf 0.25: continue cx, cy, w, h row[:4] x1 (cx - w / 2 - dw) / ratio y1 (cy - h / 2 - dh) / ratio x2 (cx w / 2 - dw) / ratio y2 (cy h / 2 - dh) / ratio boxes.append([x1, y1, x2, y2]) scores.append(float(cls_conf)) labels.append(int(cls_id)) keep cv2.dnn.NMSBoxes(boxes, scores, 0.25, 0.45) results [] for i in keep: idx int(i) results.append((boxes[idx], scores[idx], labels[idx])) return results完整性来说这里我做了两件事一是用 sigmoid? 实际上 YOLOv8 输出已经是 sigmoid 之后的置信度直接 argmax 即可不必再加激活函数二是 NMS 的 IoU 阈值用 0.45重叠的同一目标只会保留一个框。注意一个工程点我特意把 NMS 里的置信度阈值设成 0.25看起来不高但火焰和烟雾的形态本来就不像人、车那样清晰阈值太高会把刚起步的小火苗滤掉。如果现场误报多我会把这个阈值提到 0.35 或 0.4但不会超过 0.5。4.3 报警去抖用滑动窗口替代单帧判断模型单帧输出有多大的波动实际测试里同一团烟在相邻两帧里可能一帧置信度 0.6、下一帧掉到 0.3也可能连续 3 帧有框、第 4 帧突然没有。如果拿单帧结果直接报警值班室会被折腾疯。我采用的是滑动窗口策略每路视频流维护一个长度为 5 的环形缓冲区记录最近 5 帧里“是否检测到目标”。只有 5 帧里至少 3 帧检测到目标才触发一次报警状态。同时报警一旦触发就进入一个 60 秒的冷却期冷却期内即使偶发丢掉目标也不会重复报警。这个策略对火焰和烟雾都适用。烟雾刚开始出现时往往很淡模型单帧召回低但连续几帧里只要多数有检出就说明不是噪声。这样既保留了灵敏度又大幅降低了误报频次。4.4 多路视频流的接入方式系统要支持的不只是单路视频。我在推理服务里抽象了一个统一的视频源接口兼容三种输入单张图片、本地视频文件、RTSP 摄像头流。RTSP 接入需要对分辨率做限制很多低成本摄像头默认输出 4K直接喂给模型会把 GPU 直接打满。我在解码端把每一帧先 resize 到不超过 1280 宽再做 letterbox既保证检测细节不丢失又能把推理吞吐控制在合理范围。多路流的调度我也花了一些心思。最开始的版本我为每路视频各开了一个推理线程结果 GPU 显存被吃了 6 个多 G四路视频直接卡成 PPT。后来改成全局共享一个 ONNX Runtime session所有路数共用同一个推理上下文显存占用立刻降到 3.5GB 上下。这就是第 3 章说 fixed 输入尺寸的收益动态尺寸会让显存分配器频繁扩张多路并发时碎片化尤其严重。5. UI 可视化层从模型权重到可交互监控面板5.1 UI 技术选型FastAPI WebSocket 的理由模型推理是 Python 生态UI 部分如果单独造一套重型前端成本太高。我选了 FastAPI 做后端服务前端用原生 HTML 和 JavaScript实时通信走 WebSocket。为什么不选 FlaskFlask 用 SocketIO 做实时通信要套一层额外依赖FastAPI 原生支持 WebSocket而且异步性能更好操作更直接。为什么不选像 Streamlit 或 Gradio 这种一键式工具因为它们内部封装太重检测框叠加和多人同时观看监控画面的需求实现起来反而费劲。FastAPI 加原生前端看着朴素但胜在可控任何修改都能精确落地。5.2 实时推流与检测框叠加的实现我的 UI 核心逻辑是这样的浏览器端通过 WebSocket 连接后端当用户选择视频源后后端推理服务开始逐帧检测并把原始帧和检测结果一起编码为 JPEG 图片以二进制消息推给前端。前端拿到图片后直接画在 Canvas 上同时根据 JSON 消息在 Canvas 上叠加检测框和置信度文字。后端推流核心代码大致如下from fastapi import FastAPI, WebSocket import cv2 import base64 import json app FastAPI() app.websocket(/ws/detect) async def ws_detect(ws: WebSocket): await ws.accept() while True: video_id await ws.receive_text() # 收到的是一次视频源编号 # 实际项目里这里会开启一个推理循环 for frame, dets in stream_detect(video_id): ok, buffer cv2.imencode(.jpg, frame, [cv2.IMWRITE_JPEG_QUALITY, 82]) payload { image: base64.b64encode(buffer).decode(), detections: [ {label: fire, score: s, box: [x1, y1, x2, y2]} for box, s, lab in dets ], } await ws.send_text(json.dumps(payload))几个细节直接决定体验JPEG 压缩质量我控制在 82。质量越高帧体积越大推流带宽消耗越快82 这个档位肉眼基本看不出画质损失但单帧体积能控制到 40KB 左右。前端显示帧率控制在 15FPS 上限并不追求最高值。监控画面不像游戏人眼对火焰检测结果的判断不需要 60 帧的丝滑15FPS 足够流畅也能大幅降低浏览器和网络的负载。检测框叠加在 Canvas 上不在 JPEG 上直接画。这样如果用户想关闭检测框只看原始画面就不需要重新推流。5.3 面板功能拆解实时画面、报警列表、历史趋势实际交付的面板我做了四个区域实时画面区主画面加检测框叠加左上角显示当前视频源名称右上角显示检测 FPS。报警列表区右侧纵向滚动列表每次进入报警状态就追加一条记录内容包括时间、类别、置信度、视频源编号。报警状态消失后自动在记录里标记“已结束”。置信度趋势图用轻量的 Canvas 绘图实现展示最近 1 分钟 smoke 和 fire 的置信度曲线。值班人员看一条上扬的 smoke 曲线比看一屏文字更直观。历史统计区后端把每次检测结果写入 SQLite 表按小时聚合检测次数。这个数据在项目复盘时很有价值可以反推模型在哪一时段误报最多。5.4 报警通知与日志记录报警不能只在页面上弹一条值班人员不可能一直盯着看。我在两个方向做了扩展一是浏览器推送通知二是预留了 Webhook 接口方便后续接到企业微信、钉钉或者短信网关。日志表结构也很简单核心字段就是CREATE TABLE detect_log ( id INTEGER PRIMARY KEY, source TEXT, label TEXT, confidence REAL, created_at TEXT );别小看这张表它是我后续优化模型的依据。每一条错误报警都对应着一个需要被压制的场景我会定期把日志里误报高的时间段截图补充成负样本重新训练。6. 实测踩坑复盘误检、坐标错位、显存与画质问题6.1 暖色物体误报的完整排查链路项目上线到真实场景的第二天误报率突然飙升到一天几十次。打开日志一看所有误报都集中在两个时段午后阳光强烈时和傍晚日落时。报出来的全是“fire”置信度还不低最高的到了 0.72。我第一反应是置信度阈值太低直接提到 0.4误报确实压下去一些但下午四点左右还是会周期性冒出来几条。后来我把误报时刻的现场图片截出来一看顿时明白了——被误判的全是操场边上的红色塑胶跑道、停车场里的橙色保险杠和夕阳下的红砖墙面。这些物体在 HSV 色彩空间里和火焰非常接近模型学的本质是“暖色块等于火”。这个问题的根子不在阈值在训练数据的色彩分布太窄。我随即做了三件事第一收集了现场误报场景的负样本大约 300 张加入训练集第二把 HSV 增强里的色调偏移范围扩大让模型见过更多暖色调的非火物体第三在后处理里加了面积上限过滤正常监控视角下刚起火的火焰面积不会瞬间占满整个画面面积超过画面 60% 的高置信度框直接当作异常丢弃。重新训练后误报率降到了每天两三次而且剩下的误报基本都发生在极端逆光环境属于可以接受的范围。这个案例让我明白一个道理火焰烟雾检测的误报问题光靠调阈值解决不了必须回到数据层面把容易混淆的背景喂给模型。6.2 检测框整体偏移一次坐标映射问题的定位过程有段时间测试视频里检测框的位置明显偏右下方而且框越大偏移越严重。我先是检查了标注文件用可视化脚本把标签画在图上坐标完全正确。又检查了训练代码用的是官方流程没发现问题。最后把怀疑点落在推理预处理上。查了一遍代码问题出在 letterbox 和 resize 混用。我在推理脚本里虽然实现了 letterbox但在接入视频流时又顺手加了一句 cv2.resize把画面强行从 1280×720 拉成了 640×640。这个操作等于把 letterbox 的结果再次拉伸缩放比例被二次篡改后处理映射回的坐标自然就偏了。排查链路很清楚可视化标签正确 - 检查训练流程 - 检查推理入口 - 在预处理函数入口打印图像尺寸和映射参数 - 发现二次 resize 覆盖了 letterbox 的映射变量。修复也简单删掉多余的 cv2.resize把视频帧先截取或缩放到合理宽度再走统一入口的 letterbox。这个坑提醒我任何带模型推理的代码预处理模块必须保持单一入口不能各调各的。6.3 多路视频与显存占用失衡第一次把视频路数从单路扩展到四路时程序启动没问题但跑了不到十分钟第四路画面开始严重掉帧显存占用飙到接近 7GB。我用 nvidia-smi 看了进程明细发现 ONNX Runtime 在每路视频各自的推理线程里创建了独立的会话上下文四个 Context 叠加显存自然爆炸。处理方式前面提到过全局共享一个 ONNX Runtime session用 Python 的线程池做并发推理输入张量采用统一尺寸避免动态 shape 的额外分配。调整后四路总共占显存约 3.5GB稳定跑了几天没有 OOM。另外还有一个容易被忽略的点ONNX Runtime 的 CPU 和 GPU provider 顺序会影响内存占用。如果同时挂着两路画面CPU provider 会预分配不少内存建议只保留实际需要的 provider。6.4 花屏与画面撕裂视频解码层的处理项目调试期间某一路 RTSP 视频源总是间歇性花屏表现为画面下半部分出现绿边或者马赛克块。起初我怀疑推理服务导致但关闭检测只做原始推流花屏依然存在说明问题出在视频源或解码链路。查了下摄像头配置确认该源头采用了 H.264 编码并且开启了 B 帧。B 帧是双向参考帧解码时必须依赖前后的帧OpenCV 自带的 VideoCapture 在部分平台对 B 帧支持不完善一旦丢包就会产生花屏。解决办法有两个方向一是在摄像头后台把编码改成 H.264 Baseline Profile这种配置不使用 B 帧解码容错性最好二是换用 FFmpeg 作为解码后端先转码为低延迟流再喂给推理服务。我在项目里选了前者因为基于开源组件的二次开发更简单可控稳定性和延迟都更可接受。7. 一点运营期经验和后续扩展思路FireNet 跑了一段时间后我最大的体会是这个项目里真正耗时的地方不在训练而在数据整理和误报治理。模型训练本身一晚上就能完成但收集负样本、清洗标注、根据现场日志迭代数据占了我将近一半的时间。做视觉检测的都知道一句话——数据决定上限模型只是逼近这个上限。火焰烟雾检测尤其如此因为它的场景差异极大同一个模型在室内仓库和室外广场的表现可能天差地别。如果后续要继续扩展这个系统我有三个方向可以验证一是接入 PTZ 摄像机跟踪功能。当模型检测到火焰区域后通过 PTZ 协议控制摄像头转动到目标坐标并放大画面用视觉伺服的方式持续跟踪火势位置。这个功能对大型开阔场景特别有价值。二是增加时间维度的信息融合。单帧检测的置信度波动难免如果把最近几秒的检测结果做时序建模能进一步压低误报率。早期的简单做法是滑动窗口统计更复杂的做法可以用一个轻量级的时序网络对检测序列建模提升报警判断稳定度。三是建立误报数据的自动回流机制。每次现场产生一次误报系统自动截取前后各几秒的画面存入一个待标注目录定期由人工筛选后并入负样本集重新训练。这样模型会随着部署时间越来越适应当前场景误报率呈现持续下降趋势。最后分享一个小技巧在 UI 页面里我加了一个“检测调试”开关打开后会在画面上显示当前帧的曝光、对比度、目标置信度和预处理后的缩略图。这个功能平时不显眼但现场调试时极其好用排查误报和漏报时可以直观看到模型“眼里的世界”到底长什么样比对着日志猜高效得多。如果你也要做类似的视觉检测项目强烈建议把这个调试入口保留下来。