简介这份资源面向计算机视觉开发者、视频监控与智能交通方向的工程人员提供YOLOv8结合RTSP流实现实时目标检测的完整工程包。内容围绕视频流拉取、模型推理、结果处理与可视化展示展开适合具备一定深度学习基础、希望将检测模型落地到实时视频场景的读者参考。压缩包共467个文件约169.25MB以145个py源码与215个pyc编译文件为主体辅以80个yaml配置、6个pt权重、若干jpg测试图及sh脚本、前端页面资源覆盖模型配置、推理脚本与展示界面等模块。目前已有220人学习下载。借助其中的权重文件、配置模板与示例图像读者可快速搭建RTSP拉流检测流程理解预处理、推理与结果反馈各环节并参考前端页面完成检测结果的可视化呈现为二次开发与场景调优提供可复用的工程基础。1. YOLOv8 接 RTSP 流做目标检测从拉流到画框一条能跑通的链路手头有一台海康或大华的网络摄像头想让它「看懂」画面里有没有人、有没有车最省事的路径就是把 YOLOv8 和 RTSP 拼在一起。RTSP 是摄像头出厂就带的实时流协议YOLOv8 是当前落地最顺的目标检测模型两者中间隔着一个「怎么把流稳定喂给模型」的工程问题。这件事听起来简单真做起来翻车点集中在三处拉流卡顿、解码堆积、画框延迟。我见过太多人第一次跑通是在本地视频文件上一换成 RTSP 地址就发现帧率掉到个位数或者跑几分钟内存就爆了。这篇面向的是已经装好 Python 环境、手里有摄像头或 RTSP 测试地址的从业者。不管你是想在工控机上做个demo还是准备往 RK3588、Orin 这类边缘设备上迁链路的核心逻辑是一样的拉流、解码、推理、渲染、输出。区别只在解码后端和推理后端怎么换。下面按「先跑通最小闭环再调参数最后避坑」的顺序讲每一步都给能直接抄的命令和代码。2. RTSP 拉流与 YOLOv8 推理的最小闭环2.1 为什么用 OpenCV 的 VideoCapture 起步而不是一上来就上 GStreamerRTSP 拉流在 Python 里最省事的入口就是cv2.VideoCapture。它底层在 Linux 上通常走 FFmpegWindows 上走 MSMF 或 FFmpeg能直接吃rtsp://开头的地址。选它起步的理由很实际不用装额外的 GStreamer 插件不用写 pipeline 字符串三行代码就能拿到帧。GStreamer 的优势在硬解码和低延迟但那是链路跑通之后才需要考虑的优化一上来就写 pipeline 容易在环境依赖上卡半天。常见做法是先确认摄像头 RTSP 地址格式。海康的地址一般是rtsp://用户名:密码IP:554/Streaming/Channels/101大华是rtsp://用户名:密码IP:554/cam/realmonitor?channel1subtype0。101里的第一个1是通道号01是主码流换成102就是子码流。子码流分辨率低、码率小做检测预处理反而更划算这点后面参数章节会展开。import cv2 from ultralytics import YOLO # 换成你自己的 RTSP 地址子码流通常更省带宽 RTSP_URL rtsp://admin:password192.168.1.64:554/Streaming/Channels/102 # 加载 YOLOv8 预训练权重n 版最轻适合先跑通 model YOLO(yolov8n.pt) cap cv2.VideoCapture(RTSP_URL) if not cap.isOpened(): raise RuntimeError(RTSP 打开失败先检查地址和网络) while True: ret, frame cap.read() if not ret: print(取帧失败可能是流断了) break # 直接推理conf 先给 0.25 看效果 results model(frame, conf0.25, verboseFalse) annotated results[0].plot() # 画框、类别、置信度 cv2.imshow(YOLOv8-RTSP, annotated) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这段代码的逻辑是VideoCapture建立 RTSP 连接并内部起一个解码线程read()阻塞取一帧 BGR 图像model(frame)把 numpy 数组直接喂给 YOLOv8Ultralytics 内部会做 letterbox 缩放和归一化results[0].plot()返回画好框的图像。参数上conf0.25是置信度阈值先给低一点看召回verboseFalse关掉每帧日志否则控制台会被刷爆。2.2 把推理结果落到控制台和视频文件方便离线核对只在窗口里看画面出了问题没法回溯。我一般会同时做两件事把检测到的类别和数量打到日志把画框后的视频写一份到本地。这样即使现场没人盯着事后也能翻录像确认模型有没有漏检。import cv2 import time from ultralytics import YOLO RTSP_URL rtsp://admin:password192.168.1.64:554/Streaming/Channels/102 model YOLO(yolov8n.pt) cap cv2.VideoCapture(RTSP_URL) # 用摄像头帧率初始化 writer拿不到就默认 25 fps cap.get(cv2.CAP_PROP_FPS) or 25 w int(cap.get(cv2.CAP_PROP_FRAME_WIDTH)) h int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT)) writer cv2.VideoWriter(out.mp4, cv2.VideoWriter_fourcc(*mp4v), fps, (w, h)) frame_id 0 while True: ret, frame cap.read() if not ret: break frame_id 1 results model(frame, conf0.25, verboseFalse) boxes results[0].boxes # 每 30 帧打一次统计避免日志刷屏 if frame_id % 30 0: names [model.names[int(c)] for c in boxes.cls] print(fframe {frame_id}: {len(boxes)} objs, {set(names)}) writer.write(results[0].plot()) cap.release() writer.release()这里的关键参数是cv2.VideoWriter_fourcc(*mp4v)它决定输出编码格式mp4v 兼容性好但压缩率一般。cap.get(cv2.CAP_PROP_FPS)对 RTSP 流经常返回 0所以用or 25兜底。boxes.cls是类别索引通过model.names映射回可读标签。注意results[0].plot()返回的是 BGR 图像直接写 writer 没问题但如果要转 RGB 发给别的模块就得手动转。3. 拉流参数与推理参数的调优帧率、分辨率、跳帧怎么定3.1 RTSP 传输模式选 TCP 还是 UDP直接决定画面碎不碎RTSP 底层可以用 UDP 也可以用 TCP 传 RTP 包。UDP 延迟低但丢包会导致花屏、马赛克TCP 可靠但延迟略高。OpenCV 默认走 UDP在无线网络或跨交换机场景下经常碎屏。强制走 TCP 的做法是改环境变量在import cv2之前设置import os # 必须在 import cv2 之前设置否则不生效 os.environ[OPENCV_FFMPEG_CAPTURE_OPTIONS] rtsp_transport;tcp import cv2 cap cv2.VideoCapture(rtsp://admin:password192.168.1.64:554/Streaming/Channels/102)rtsp_transport;tcp是 FFmpeg 的参数格式分号分隔键值。这个设置对有线网络同样推荐因为丢包重传的代价远小于花屏导致的误检。如果现场网络质量确实差还可以加stimeout;5000000设置超时微秒数避免read()永久阻塞。3.2 跳帧推理不是每一帧都值得送进模型摄像头 25fpsYOLOv8n 在 GTX 1660Ti 上单帧推理大概 8 到 12ms理论上能跟上。但加上解码、画框、显示实际循环往往跑不满 25fps。这时候如果还坚持每帧推理cap.read()的缓冲区会越积越多画面延迟从几百毫秒涨到几秒。解决办法是跳帧每读若干帧才推理一次其余帧直接丢弃或只做显示。import cv2 from ultralytics import YOLO model YOLO(yolov8n.pt) cap cv2.VideoCapture(rtsp://admin:password192.168.1.64:554/Streaming/Channels/102) SKIP 3 # 每 3 帧推理 1 次 idx 0 last_annotated None while True: ret, frame cap.read() if not ret: break idx 1 if idx % SKIP ! 0: # 非推理帧直接复用上一帧画框结果保证显示流畅 if last_annotated is not None: cv2.imshow(YOLOv8-RTSP, last_annotated) if cv2.waitKey(1) 0xFF ord(q): break continue results model(frame, conf0.25, verboseFalse) last_annotated results[0].plot() cv2.imshow(YOLOv8-RTSP, last_annotated) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()SKIP3意味着推理帧率降到约 8fps对人员、车辆这类慢速目标足够。如果检测的是快速移动物体SKIP 要降到 1 或 2。注意非推理帧复用上一帧画框结果只是显示技巧不能用于计数统计否则会重复计数。3.3 输入分辨率与模型输入尺寸的匹配YOLOv8 默认推理尺寸是 640×640。RTSP 主码流常见 1920×1080直接送进去会被 letterbox 缩放到 640小目标信息损失严重。两个选择一是改用子码流通常 704×576 或 640×480二是保持主码流但在model()里指定imgsz1280。后者精度高但显存和耗时都涨。我一般先用子码流跑通确认检测效果不够再换主码流加imgsz。参数常用值影响rtsp_transporttcp避免花屏延迟略增SKIP2~3降低推理负载防延迟堆积imgsz640 / 1280越大精度越高显存和耗时上升conf0.25~0.5越低召回越高误检也越多iou0.45~0.7NMS 阈值密集场景调低4. 避坑与排查RTSP YOLOv8 最常见的五类翻车4.1 现象程序跑几分钟后卡死read() 不返回原因RTSP 流中断或网络抖动FFmpeg 内部缓冲区阻塞cap.read()一直等新包。解决设置超时参数并在取帧失败时重建连接。可以在OPENCV_FFMPEG_CAPTURE_OPTIONS里加stimeout;5000000同时在循环里判断连续失败次数超过阈值就cap.release()后重新VideoCapture。4.2 现象画面延迟越来越大像慢动作原因推理速度跟不上流帧率OpenCV 内部缓冲队列堆积。解决跳帧推理或者开一个独立线程专门read()并只保留最新帧推理线程从共享变量取帧。后者是更彻底的方案核心是让缓冲区永远只有一帧。4.3 现象检测框位置偏移框和物体对不上原因results[0].plot()画框用的是模型输入尺寸的坐标如果手动缩放或裁剪过 frame坐标没同步变换。解决要么不手动改 frame 尺寸要么用boxes.xyxy自己按缩放比例映射回原图再画。4.4 现象GPU 显存持续增长直到 OOM原因每帧model()返回的 results 对象持有 GPU 张量引用循环里没释放。解决推理后及时取需要的数据boxes、names不要让 results 跨帧累积必要时torch.cuda.empty_cache()但更推荐检查是不是把 results 存进了列表。4.5 现象换一台机器就跑不起来报解码器错误原因OpenCV 编译时没带 FFmpeg或者 FFmpeg 缺少 H.264 解码器。解决用cv2.getBuildInformation()确认 FFmpeg 状态装opencv-python而不是opencv-python-headless的某些版本或者改用 GStreamer 后端显式指定videoconvert。提示排查 RTSP 问题先用ffplay -rtsp_transport tcp rtsp://...确认流本身正常再怀疑代码。5. 从单路到多路用线程池把 RTSP 拉流和 YOLOv8 推理解耦单路跑通之后真实项目往往是 4 路、8 路甚至更多。如果每路都用一个while True串行读帧推理总帧率会被最慢的一路拖死。我一般会把架构改成「每路一个拉流线程 一个推理线程池」拉流线程只负责把最新帧塞进队列推理线程从队列取帧跑模型结果通过回调或共享字典输出。import cv2 import threading import queue from ultralytics import YOLO class RTSPWorker(threading.Thread): def __init__(self, url, name): super().__init__(daemonTrue) self.url url self.name name self.q queue.Queue(maxsize1) # 只留最新帧 self.running True def run(self): cap cv2.VideoCapture(self.url, cv2.CAP_FFMPEG) while self.running: ret, frame cap.read() if not ret: continue # 队列满就丢旧帧保证低延迟 if self.q.full(): try: self.q.get_nowait() except queue.Empty: pass self.q.put(frame) cap.release() def get_frame(self): try: return self.q.get_nowait() except queue.Empty: return None model YOLO(yolov8n.pt) workers [RTSPWorker(frtsp://admin:password192.168.1.{64i}:554/Streaming/Channels/102, fcam{i}) for i in range(4)] for w in workers: w.start() while True: for w in workers: frame w.get_frame() if frame is None: continue results model(frame, conf0.25, verboseFalse) # 这里可以把结果推给业务逻辑比如报警、存库 print(w.name, len(results[0].boxes))关键设计是queue.Queue(maxsize1)队列满时丢旧帧而不是阻塞这样推理慢也不会让拉流线程卡住。daemonTrue保证主线程退出时子线程跟着结束。多路场景下 GPU 推理最好串行化因为 YOLOv8 单模型多线程并发调用不一定更快反而可能因为显存竞争变慢。如果路数多到单卡扛不住再考虑多进程或换 TensorRT 加速。这套结构迁到 RK3588 或 Orin 上时把model()换成对应的推理后端即可拉流和队列逻辑不用动。我自己的习惯是先在 PC 上把多路逻辑跑稳再整体移植避免在边缘设备上同时调拉流和推理两个变量。希望帮到你。本文还有配套的精品资源点击获取