简介这是一份面向计算机视觉开发者与视频监控、智能交通、工业自动化方向工程师的实战资源围绕 YOLOv8 与 RTSP 实时视频流的结合展开帮助读者搭建可实时处理网络摄像头视频流并识别画面目标物的检测系统。压缩包共 467 个文件约 169.25MB以 145 个 py 源码与 215 个 pyc 编译文件为主体辅以 80 个 yaml 模型与数据配置、6 个 pt 权重文件以及少量 jpg 测试图、sh 启动脚本、md 说明文档和前端页面资源覆盖从模型推理到结果展示的完整链路。资源内含 camera.html 等可视化页面与示例图片便于快速验证检测效果。目前已有 220 人学习下载。通过源码与配置文件的组合读者可掌握 RTSP 拉流、帧预处理、YOLOv8 推理、结果处理与前端反馈等关键环节并参考权重与 yaml 配置进行微调适合具备一定 Python 与深度学习基础、希望将目标检测落地到实时视频场景的开发者。1. YOLOv8 接 RTSP 流从拉流到画框一条能跑通的链路长什么样手里有一台海康或大华的网络摄像头想用 YOLOv8 做实时目标检测这件事听起来只是「读视频 推理」两步实际动手会发现卡点全在中间RTSP 地址拼不对、OpenCV 拉流延迟越跑越大、断流之后程序直接卡死、GPU 利用率上不去。YOLOv8 基于 RTSP 流目标检测本质是把「网络摄像头的实时视频流」当成输入源替代本地 mp4 文件让检测模型持续消费帧并输出带框的结果。它适合做安防周界、工地安全帽、园区车辆统计这类需要 7×24 小时跑的现场也适合 RK3588、Orin、GTX1660Ti 这类边缘设备做本地推理。这篇不聊论文只讲一条我实际跑通过、能复现的链路怎么拿到 RTSP 地址、怎么用 OpenCV 或 FFmpeg 拉流、YOLOv8 怎么接、参数怎么调、断流和延迟怎么处理。2. RTSP 拉流与 YOLOv8 推理的对接方式三种方案怎么选2.1 先搞清楚 RTSP 地址的构成和主辅码流RTSP 地址不是随便拼的它由协议头、认证信息、IP、端口、路径几段组成。以海康威视为例常见格式是rtsp://用户名:密码IP:554/Streaming/Channels/101其中101的规则是「通道号 码流号」1是主码流2是子码流。大华的结构不同通常是rtsp://用户名:密码IP:554/cam/realmonitor?channel1subtype0subtype0是主码流1是子码流。这里有个血泪经验做 YOLOv8 检测时优先用子码流。主码流常见是 2560×1440 甚至 4K帧率 25fps直接喂给模型会先把解码和缩放吃满GPU 反而闲着。子码流一般是 704×576 或 1280×720YOLOv8 输入本来就是 640用子码流画质损失可接受端到端延迟能降一半以上。品牌主码流地址特征子码流地址特征默认端口海康威视Channels/101Channels/102554大华subtype0subtype1554宇视/media/video1/media/video2554提示地址里的用户名密码如果含、#、:等字符必须做 URL 编码否则解析会失败这是最常见的「地址明明对却连不上」原因。2.2 三种拉流方案OpenCV、FFmpeg 子进程、GStreamer方案一OpenCV 直接cv2.VideoCapture(rtsp_url)。优点是代码最短缺点是默认走 FFmpeg 后端时缓冲不可控延迟会随时间累积。必须加cv2.CAP_FFMPEG并设置CAP_PROP_BUFFERSIZE1但 OpenCV 对 RTSP 的缓冲参数支持并不完整长跑还是容易涨延迟。方案二FFmpeg 子进程拉流输出 rawvideo 到管道Python 读管道。这是我在生产环境最常用的方式因为可以精确控制-rtsp_transport tcp、-fflags nobuffer、-flags low_delay这些参数延迟稳定。方案三GStreamer 管线。适合需要硬解码如 RK3588 的 MPP、Jetson 的 NVDEC的场景性能最好但管线调试成本高gsteamer rtsp服务器这类工具链要单独装。选型建议验证阶段用方案一快速跑通上线用方案二边缘设备追求帧率用方案三。2.3 用 FFmpeg 子进程拉流的最小可跑代码import subprocess import numpy as np import cv2 RTSP_URL rtsp://admin:password192.168.1.64:554/Streaming/Channels/102 W, H 1280, 720 # 必须和子码流实际分辨率一致否则画面错位 # -rtsp_transport tcp 强制 TCP避免 UDP 丢包花屏 # -fflags nobuffer 关闭输入缓冲-flags low_delay 走低延迟解码 cmd [ ffmpeg, -rtsp_transport, tcp, -fflags, nobuffer, -flags, low_delay, -i, RTSP_URL, -f, rawvideo, -pix_fmt, bgr24, -an, # 不要音频 - ] proc subprocess.Popen(cmd, stdoutsubprocess.PIPE, bufsize10**8) frame_size W * H * 3 while True: raw proc.stdout.read(frame_size) if len(raw) ! frame_size: print(流中断或分辨率不匹配) break frame np.frombuffer(raw, np.uint8).reshape((H, W, 3)) # 到这里 frame 就是可直接送 YOLOv8 的 BGR 图像逻辑说明FFmpeg 把 RTSP 解码成 rawvideo 从 stdout 吐出来Python 按固定字节数读取凑够一帧就 reshape。参数上-rtsp_transport tcp是必加项UDP 在弱网下会花屏-fflags nobuffer和-flags low_delay一起用才能压住延迟W、H必须和摄像头子码流实际输出一致写错会导致 reshape 出来的画面是斜的这个坑我踩过不止一次。2.4 把帧送进 YOLOv8 并控制推理节奏from ultralytics import YOLO model YOLO(yolov8n.pt) # 边缘设备用 n服务器可用 s/m while True: raw proc.stdout.read(frame_size) if len(raw) ! frame_size: break frame np.frombuffer(raw, np.uint8).reshape((H, W, 3)) # imgsz640 是 YOLOv8 默认输入conf 按场景调0.25 偏宽松 results model.predict(frame, imgsz640, conf0.25, verboseFalse) annotated results[0].plot() cv2.imshow(rtsp-yolov8, annotated) if cv2.waitKey(1) 0xFF ord(q): break参数说明imgsz决定推理分辨率摄像头子码流是 720p 时设 640 会缩放设 1280 精度略高但速度掉一半conf是置信度阈值安防场景漏检代价高就调到 0.150.2误报多就提到 0.4verboseFalse关掉每帧日志否则控制台会被刷爆。model.predict每帧调用一次如果帧率高于推理速度管道会积压解决办法是加一个「只取最新帧」的丢弃逻辑而不是每帧都推理。3. 参数调优与性能压榨让 GTX1660Ti 和 RK3588 都跑满3.1 模型选型n/s/m 在 RTSP 场景下的取舍YOLOv8 提供 n、s、m、l、x 五档。RTSP 实时检测的核心矛盾是「帧率要跟上摄像头的 25fps」。GTX1660Ti 上yolov8n 用 TensorRT FP16 能跑到 200fps 以上yolov8s 大约 100fpsyolov8m 掉到 40fps 左右。如果单路摄像头s 是精度和速度的平衡点如果要多路4 路以上共用一张卡必须用 n 并做批处理。RK3588 这类 NPU 设备更敏感官方 RKNN 工具链对 yolov8n 支持最好m 以上量化后精度掉得明显。Orin 系列有 NVDEC 硬解 TensorRT可以上 s。注意换模型后必须重新导出.pt不能直接给 RKNN 或 TensorRT 用要走model.export(formatrknn)或formatengine。3.2 抽帧策略不是每一帧都值得推理摄像头 25fps模型只能跑 15fps硬扛的结果是延迟越堆越高。正确做法是主动丢帧维护一个「最新帧」变量推理线程只取最新的一帧处理完再取下一帧中间过期的帧直接扔。import threading latest_frame None lock threading.Lock() def reader(): global latest_frame while True: raw proc.stdout.read(frame_size) if len(raw) ! frame_size: break frame np.frombuffer(raw, np.uint8).reshape((H, W, 3)) with lock: latest_frame frame # 覆盖旧帧天然丢帧 def infer(): while True: with lock: frame latest_frame if frame is None: continue results model.predict(frame, imgsz640, conf0.25, verboseFalse) # 后续画框、推流这样做的效果是无论模型多慢显示的永远是最新画面延迟不会累积。代价是丢掉了中间帧对「玩手机目标检测」「目标检测举手数据集」这类需要连续动作判断的场景要改成保留关键帧或做跟踪补偿。3.3 硬解码与零拷贝把 CPU 占用降下来纯 FFmpeg 软解 720p 25fps 大约吃 12 个核4 路就顶不住了。Jetson 上用nvv4l2decoderRK3588 上用mppvideodec能把解码放到硬件单元。零拷贝是指解码后的帧直接在 GPU/NPU 显存里不经过 CPU 内存往返TensorRT 和 RKNN 都支持这种绑定。如果暂时上不了硬解至少把 FFmpeg 的-threads限制一下别让它把 CPU 全占了给推理留出余量。3.4 多路 RTSP 的并发组织多路场景不要开多个 Python 进程各拉各的内存和句柄会爆。常见做法是一个拉流进程池 一个推理队列或者用 GStreamer 的uridecodebin做多路合流。每路单独记录状态某一路断了不影响其他路重连逻辑按路独立。4. 避坑与排查RTSP YOLOv8 最容易翻车的五个点4.1 现象程序跑几分钟后画面卡住不动原因OpenCV 或 FFmpeg 的输入缓冲在累积网络抖动时帧堆积读的速度跟不上写的速度。解决加-fflags nobufferOpenCV 方案设CAP_PROP_BUFFERSIZE1并且用上面的「只取最新帧」逻辑从消费端强制丢弃。4.2 现象报错Could not find codec parameters或直接连不上原因RTSP 地址错误、认证失败、或者摄像头没开子码流。解决先用ffplay -rtsp_transport tcp 地址单独验证地址能播再进代码。海康的101/102、大华的subtype写错都会报这个。密码含特殊字符要做 URL 编码。4.3 现象画面颜色不对或图像是斜的原因W、H和实际码流分辨率不一致reshape 时错位。解决先用ffprobe查实际分辨率或者用 OpenCV 读一帧打印frame.shape把真实值填进代码。子码流分辨率各厂商默认不同别想当然。4.4 现象GPU 利用率只有 20%帧率上不去原因瓶颈在解码或 Python 读管道不在推理。解决换硬解码或者把 FFmpeg 输出改成-pix_fmt nv12直接喂给 TensorRT省掉 BGR 转换。也可能是model.predict每帧都重新做预处理改用model的 warmup 和固定输入尺寸。4.5 现象断流后程序不退出也不重连原因proc.stdout.read在流断开时可能阻塞或返回空没有超时机制。解决给读取加超时或者用select监听管道检测到连续 N 帧读取失败就 kill 子进程并重新拉起。生产环境必须写重连摄像头重启、网络闪断都是常态。5. 进阶把检测结果推回 RTSP 或转 FLV以及验证延迟的土办法单机画框只是第一步实际项目往往要把带框的视频再推出去给前端看。常见做法是用 FFmpeg 把annotated帧重新编码推成 RTSP或者转成 FLV 给网页播放。推流命令的核心是-f rtsp -rtsp_transport tcp rtsp://...输入用-f rawvideo -pix_fmt bgr24 -s WxH -r 25 -i -注意帧率要和你实际推理输出的帧率匹配写死 25 但实际只有 12播放端会加速或卡顿。ffmpeg -f rawvideo -pix_fmt bgr24 -s 1280x720 -r 15 -i - \ -c:v libx264 -preset ultrafast -tune zerolatency \ -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/out-r 15要和你推理线程实际产出帧率一致-tune zerolatency关掉编码器缓冲-preset ultrafast换速度。如果前端要 FLV把输出改成-f flv rtmp://...或直接写 FLV 文件。验证延迟别靠感觉用土办法拿手机秒表对着摄像头同时截屏检测画面两个时间差就是端到端延迟。我一般要求控制在 300ms 以内超过就说明缓冲没压干净。另一个办法是在画面里叠加时间戳看时间戳和当前时间的差值。最后说个习惯每次改完拉流参数或模型先跑 30 分钟压力测试看内存有没有缓慢上涨、延迟有没有漂移。RTSP 流的坑大多是「跑十分钟没事跑两小时才炸」短测看不出来。这套链路我在园区车辆统计上跑过半年最大的教训就是重连逻辑和丢帧策略必须一开始就写进去后期补的代价是重构整个读取线程。希望帮到你。本文还有配套的精品资源点击获取
