做实时视频AI项目最容易被低估的不是模型精度而是工程化集成。YOLO跑单张图、跑离线视频都很顺一旦要接真摄像头、做多路并发、保证低延迟问题就全冒出来了。这篇文章想聊的是我们把YOLO从实验脚本一步步演进成实时视频AI能力的过程中在SmartMediaKit这套媒体处理框架里做的集成设计与技术实践。适合正在做视频AI平台、算法工程化或者摄像头接入类项目的同学参考里面涉及架构拆分、模型部署、性能优化和一些生产环境才会踩到的坑。1. 为什么单独的 YOLO 服务撑不起实时视频 AI1.1 模型只是其中一环不是全部很多人一开始的路径是这样的训练好YOLO模型写一个Python脚本用OpenCV读视频帧跑模型推理画框然后完事。demo效果不错但往生产环境一放就露馅了。问题出在哪YOLO解决的只是“单帧图像里有什么”这个感知问题。视频AI真正要解决的是“连续画面里正在发生什么”这件事这中间隔着几层东西摄像头的RTSP流怎么稳定接入解码后的视频帧怎么高效送到推理单元模型输出怎么和视频时间轴对齐检测结果怎么触发告警、怎么叠加到直播流上录像回放时怎么检索事件。拿我们做的一个园区监控项目举例需求是识别吸烟和积水。算法部分其实不复杂训练两个YOLO模型就行。但真正占工作量的是接入不同品牌摄像头的视频流、7x24小时稳定运行不崩溃、断网重连不丢事件、多路画面同时分析时GPU不爆显存、检测到目标后1秒内推送给值班室。这些需求模型训练解决不了需要一套完整的媒体处理和调度机制。1.2 SmartMediaKit 在视频 AI 架构里的位置我们内部把这一整套媒体处理框架叫SmartMediaKit定位是“视频接入、媒体处理、模型推理、结果分发”的中间层。它基于FFmpeg和GStreamer做了深度封装核心是一条可编排的数据流管道Source拉流→ Decode解码→ Inference推理插件→ Overlay画框叠加→ Output推流/存储/告警。刚开始我也犹豫过直接用FFmpeg命令行加上Python脚本是不是就够了后来发现不够。FFmpeg擅长做转码和流处理但模型推理不是它的强项Python脚本擅长调模型但处理视频流、做多路复用、管理生命周期又很痛苦。SmartMediaKit的思路是两者结合媒体能力交给底层框架AI能力做成可插拔的插件节点中间用统一的数据结构传递视频帧和推理结果。这样设计还有一个好处——算法团队和工程团队可以并行工作。算法工程师只需要关心插件内部怎么写不需要懂RTSP、H.264、推流这些细节工程团队也不用每次算法迭代都动主干代码换个插件版本就行。这个边界画清楚之后项目推进速度快了很多。1.3 集成带来的三个直接收益把这套集成思路落地之后收益是实打实的。第一媒体层能力直接复用。断流重连、硬解、时间戳对齐、HLS/RTMP打包这些成熟能力不用自己重新造轮子。最开始我们想自己写RTSP客户端写着写着发现坑太多NAT穿透、认证方式、TCP/UDP模式选择每一个都能耗掉好几天。基于FFmpeg/GStreamer封装之后这些问题框架层已经处理掉了。第二推理部分真正做到了可替换。今天跑YOLOv5检测明天换YOLOv11或者加一个人脸识别插件只需要在配置里改一行插件名称管道里的其他模块完全不动。我们后来还加过YOLOv8-seg做实例分割也只是新增一个插件没有改动主链路。第三性能上有了明确的优化空间。解码可以用NVDEC硬解推理可以走TensorRT多路视频可以按batch合并推理。这些优化如果没有框架支撑散落在业务代码里后期维护成本会非常高。2. 整体架构设计一条视频管线的拆分逻辑2.1 从像素到结构化事件的五段流水线SmartMediaKit把一次完整的视频AI处理拆成五段接入、解码、推理、分析、输出。每一段都有明确的职责边界。接入层负责拿流。最常见的输入是RTSP海康、大华、宇视的摄像头基本都支持这个协议。另外还有RTMP、HTTP-FLV、GB28181这些不同项目需求不一样。接入层要做的事情包括建立连接、处理认证、监控连接状态、异常时自动重连。解码层负责把压缩的视频流变成原始帧。这里有两个选择软解FFmpeg的CPU解码和硬解NVDEC/VAAPI。硬解能大幅降低CPU占用但显存占用会增加需要根据硬件配置权衡。解码输出一般是NV12或YUV420P而大多数推理引擎需要RGB输入所以还需要做一次颜色空间转换。推理层接的是YOLO等模型。这一层是SmartMediaKit的插件机制核心输入是一帧或多帧图像输出是检测框、类别、置信度或者分割掩码。推理层要处理模型加载、推理会话管理、预处理、后处理这些事。分析层在推理结果之上做业务判断。比如连续3帧都检测到同一个目标才触发告警避免单帧误检比如对目标做简单的跟踪逻辑判断是否越界、是否滞留比如根据ROI区域过滤无效检测结果。这一层离业务最近也是各个项目差异最大的地方。输出层负责结果分发。推流到Web端可以用WebRTC或者HLS存储到本地可以用MP4录像告警通知走Webhook、MQTT或者直接推送到手机App。输出层不关心业务逻辑只负责把处理好的画面和事件数据送达目的地。2.2 拉流与解码RTSP 接入为什么不能想当然RTSP接入看起来简单拿到URL就能拉流实际跑起来问题很多。我们踩过的第一个坑是传输模式。RTSP有两种传输方式TCP和UDP。UDP延迟低但在复杂网络环境下丢包严重画面频繁花屏TCP稳定性好但网络的抖动会影响实时性。生产环境我们一般强制走TCP优先保证画面完整性。第二个坑是断流重连。摄像头重启、网络波动、带宽被占满都会造成拉流中断。如果没有重连机制整个分析链路就瘫痪了。我们的做法是在接入层做一个状态机正常拉流、读超时、连接断开、重连等待几个状态之间循环。重连要用指数退避策略第一次失败等1秒第二次等2秒最多等30秒不能无脑快速重连否则摄像头会被请求打挂。第三个坑是参数校验。接入一条流之前先用ffprobe检查一下流信息确认编码格式H.264还是H.265、分辨率、帧率、GOP间隔。H.265流比H.264更吃解码性能如果推理机没有硬解H.265的能力CPU会飙得很高。GOP间隔也很重要关键帧间隔太长时我们做事件截图会拿到不完整的画面。2.3 帧缓冲、推理调度与结果回写解码器输出的帧率一般是固定的比如25fps或者30fps。但推理引擎不一定跑得满这个帧率尤其在高分辨率场景下。这里需要有一个帧选择策略按固定间隔抽帧送推理比如每2帧或者每3帧推理一次。这个间隔可以在配置里调让用户在检测密度和算力消耗之间找平衡。帧数据在管道里流动的时候最忌讳的是直接改原始帧buffer。解码器可能正在使用这块内存改坏了会造成花屏、崩溃。我们的做法是给每帧挂一个元数据结构里面存帧的时间戳、序号、以及推理结果。推理插件把结果写入元数据后续的Overlay模块和告警模块从这个元数据里读结果各模块之间不直接共享内存减少并发冲突。多路并发时每路视频流是一个独立的管道实例但推理引擎全局只有一个。这就涉及到调度问题。最简单的做法是各路独立推理互不等待GPU算力有余量时可以尝试把多路帧合并成一个batch推理吞吐会明显提升。这块后面在性能优化部分展开讲。3. YOLO 模型准备与推理性能实战3.1 模型选型从 YOLOv5 到 YOLOv11YOLO发展到今天可选的版本和变体非常多。v5因为生态成熟、资料多仍是很多项目的首选v8在结构上做了优化支持实例分割v11是2024年发布的新版本C3K2模块带来了更快的推理速度。选型不能只看精度排行榜还要考虑和部署环境的兼容性。我们的经验是小算力设备用YOLOv8n或者YOLOv11n检测速度优先中等算力用YOLOv8s或YOLOv11s速度和精度平衡大算力服务器上可以上YOLOv8m甚至更大追求极致精度。如果是做监控场景模型要识别的目标可能不是COCO的80类而是安全帽、工服、烟雾这些自定义类别。这时候就需要自己准备数据并训练。数据标注格式要注意如果是KITTI或者其他标注工具导出的格式要先转成YOLO的txt格式转换时别把类别id搞错归一化坐标也要算对这些细节直接影响训练效果。3.2 模型导出与 TensorRT 加速训练好的PyTorch模型不能直接用要经过转换和优化才能跑在推理引擎上。我们项目是NVIDIA显卡所以统一用TensorRT。转换流程分两步PyTorch导出ONNX再用TensorRT把ONNX转成engine。导出ONNX这一步很简单yolo export modelyolo11s.pt formatonnx opset12ONNX转TensorRT可以直接用trtexec命令行工具trtexec --onnxyolo11s.onnx --saveEngineyolo11s.engine --fp16几个实际经验TensorRT版本和CUDA版本必须匹配我们遇到过版本不匹配导致engine加载失败的问题排查了很久。模型输入分辨率如果固定的话尽量用静态shape不要开dynamic shape静态shape的engine推理速度更快。FP16精度在实际检测任务里几乎不掉点但速度比FP32快一倍以上能开就开。3.3 预处理与后处理里的三个坑YOLO推理的预处理和后处理代码逻辑不复杂但恰恰是容易出错的地方。第一个坑是letterbox。模型输入要求正方形但视频帧是16:9或者4:3直接resize会拉伸变形检测精度下降。正确做法是先把画面等比缩放再填充到模型输入尺寸同时记录padding的偏移量。后处理恢复坐标时要把这个偏移量减掉再除以缩放比例否则检测框会和实际目标错位。// letterbox 记录缩放比例和填充偏移 float scale min((float)model_w / frame_w, (float)model_h / frame_h); int pad_x (model_w - frame_w * scale) / 2; int pad_y (model_h - frame_h * scale) / 2; // 后处理阶段真实坐标 (模型坐标 - pad) / scale第二个坑是BGR和RGB顺序。OpenCV读出来的帧是BGR格式模型训练时用的通常是RGB如果推理输入没有转换channel顺序检测结果会明显变差。这个问题很隐蔽因为不一定会报错只是准确率上不去。TensorRT推理时最好在推理引擎里加一个颜色转换层或者在上游把帧转成RGB再送入输入buffer。第三个坑是NMS阈值设置。conf_thres设得太低会有一堆误检框设得太高又会漏掉小目标。iou_thres同理影响重叠框的抑制效果。我们项目里通常把conf设为0.35到0.5之间iou设为0.45到0.5具体数值还是要看实际测试效果。不同类别如果误检率差异大可以分开配置阈值。3.4 实测数据与性能目标以我们测试用的A10显卡为例跑1080p视频流解码用NVDEC推理用TensorRT FP16实测数据大概是这样模型输入尺寸单帧推理耗时理论最高路数25fps每路YOLOv8s640x640约4ms6路YOLOv11s640x640约3.5ms7路YOLOv11m640x640约8ms3路这个数据仅供参考实际数值和GPU型号、驱动版本、显存大小都有关系。但可以看出来推理延迟只占每帧40ms时隙的十分之一左右瓶颈通常不在推理本身而在解码、拷贝、后续分析这些环节。优化的时候要先用数据说话别一上来就换大模型或者升级显卡。4. SmartMediaKit 集成 YOLO 的实操记录4.1 插件的接口设计SmartMediaKit里的推理插件接口设计得尽量精简。核心是三个方法init、process、release。init负责加载模型和初始化推理会话process接收视频帧返回推理结果release释放资源。class InferencePlugin { public: virtual bool init(const PluginConfig config) 0; virtual InferenceResult process(const VideoFrame frame) 0; virtual void release() 0; };为什么用这么简单的接口因为插件和主框架之间是通过帧元数据通信的不需要传递复杂的自定义结构。主框架负责把帧queue、内存管理、并发调度这些事情都做好插件只做“图像进、结果出”。这降低了算法工程师接入的门槛不用理解整个媒体框架的内部原理。回调机制上我们用的是异步回调而不是同步等待。解码线程把帧推入推理队列后立刻返回不用阻塞等推理完成。推理跑完之后把结果写回帧元数据再触发Overlay或者告警模块处理。这样即使推理突发耗时增加也不会把解码管线堵死最多是减少分析帧率不会造成整条链路卡死。4.2 一个最小可跑的检测告警模块下面这段代码展示的是SmartMediaKit里一个YOLO检测插件加告警回调的最简实现思路实际生产代码会比这个复杂但核心流程就是这样class YoloDetectorPlugin : public InferencePlugin { private: std::shared_ptrInferenceEngine engine_; float conf_thres_ 0.4f; float iou_thres_ 0.5f; std::vectorstd::string class_names_; public: bool init(const PluginConfig config) override { // 加载 TensorRT engine engine_ InferenceEngine::create(config.engine_path); // 读取类别名和阈值 class_names_ config.class_names; conf_thres_ config.conf_thres.value_or(0.4f); iou_thres_ config.iou_thres.value_or(0.5f); return engine_ ! nullptr; } InferenceResult process(const VideoFrame frame) override { // 1. 预处理letterbox BGR转RGB 归一化 Tensor input preprocess(frame); // 2. 推理 Tensor output engine_-forward(input); // 3. 后处理解码检测框 NMS 坐标还原 std::vectorDetection detections postprocess(output); // 4. 判断是否触发告警条件如检测到目标 bool alert false; for (auto det : detections) { if (det.confidence conf_thres_ should_alert(det.class_id)) { alert true; break; } } return InferenceResult{frame.pts, detections, alert}; } };这个插件的核心逻辑就这么简单。真正花时间的是和主框架的接入细节比如推理结果的元数据怎么注册、告警事件怎么发给上层的告警中心、多路并发时插件的线程安全性怎么保证。这些看起来不起眼但都是生产环境稳定性的关键。4.3 低延迟调优推理频率与关键帧联动“实时”这个词在不同场景下的标准不一样。做视频通话延迟要求几百毫秒做安防监控从事件发生到告警推送几秒内都算可接受。对于大多数视频AI分析场景我们的优化目标是“告警事件端到端延迟控制在1秒以内”。优化手段有几个方向抽帧策略。默认是固定间隔抽帧比如每3帧推理一次。对快速移动的目标抽帧间隔太大会漏检。改进方案是在检测区域内做动态抽帧——画面静止时降低推理频率检测到运动区域时提高频率。判断画面是否静止可以用帧间像素差或者简单的运动检测算法成本很低。关键帧联动。H.264/H.265解码时关键帧IDR帧的 decode 开销最小跳帧也最容易。如果业务对实时性要求没那么高可以在每个关键帧到达时触发一次推理这样能减少解码器的压力。但GOP间隔一般很长几十帧甚至上百帧才有一次关键帧单独依赖这个策略会导致事件延迟不可控。所以实际做法是两者结合关键帧必推理普通帧按固定间隔抽推理兼顾延迟和算力。事件截图优化。告警推送时经常要带一张现场图片。如果拿BGR原始帧去编码JPEG会占额外的CPU。我们的做法是直接在解码后的帧上做缩小和JPEG编码或者从最近的IDR帧截图减少编码体积和耗时。4.4 结果叠加与告警联动检测到目标之后用户肯定希望看到画面上有检测框和类别标签。SmartMediaKit的Overlay模块专门做这件事但有个前提画框操作要在编码之前完成不能先推流出去再在播放端画框。流程是这样Overlay模块取回帧元数据里的检测结果把目标框、类别、置信度信息画到原始帧的副本上然后把画好的帧交给编码器推流。这里要注意画框要用帧的副本不要直接在推理插件的输入帧上操作避免内存竞争。告警联动要考虑去抖。单帧检出不算数要连续N帧检出或者在一个时间窗口内检出次数超过阈值才触发告警。这是为了防止画面里某个目标一闪而过造成误报。去抖参数也是配置化的不同场景配置不一样吸烟检测要求快速告警窗口可以短一些积水检测不着急窗口可以长一些。告警事件通过Webhook推给上层业务系统或者通过MQTT推送消息。消息体里包含通道ID、事件类型、时间戳、检测框坐标以及截图URL。上层系统拿到之后可以展示、存档、派发工单。SmartMediaKit本身不关心上层业务怎么处理它只负责把事件干净地投递出去这就是“被集成”的思路——框架提供能力出口业务方按需接入。5. 常见问题与排查技巧实录5.1 多路并发显存不够怎么办这是多路视频接入时最容易碰到的问题。现象是通道数加到一定数量之后推理突然变得特别慢甚至直接报CUDA out of memory。排查思路先用nvidia-smi看显存占用情况确认是哪个进程在吃显存是解码还是推理。很多时候不仅是模型占显存NVDEC也要在显存里存解码帧这个容易被忽略。另外还要查一下是否有显存泄漏推理引擎反复创建销毁会导致显存碎片化肉眼看不到但问题是真实存在的。解决方案按优先级排控制并发策略多路视频不要同时推理做成按时间片轮转每路轮流推理确保GPU不会瞬间被多路请求打爆。合并batch推理把多路视频的帧拼成一个batch送入模型显存占用增加的幅度低于线性吞吐反而更高。缩小输入尺寸如果只是检测小的目标区域可以先把ROI裁剪出来再送模型比整帧缩小更有效。换更小的模型YOLOv11n比YOLOv11s小将近一半显存占用和推理延迟都低不少精度损失在可接受范围内时可以顶上。5.2 推理结果和画面不对应表现是画面里人已经走出去了但画面上还框着刚才那个人。这种问题通常不是模型的问题是时间戳没对齐。常见原因有两个解码线程和推理线程不同步。推理线程拿到的帧可能是几百毫秒之前的结果回写的时候却写到了最新帧上。解决方法是让推理结果携带帧的PTSOverlay模块按PTS匹配帧而不是按顺序取结果。检测框坐标没有按照letterbox参数还原。这个前面提到过如果模型的输入尺寸和原始帧尺寸不一致后处理时必须做坐标逆变换。很多刚接触YOLO集成的同学会在这里卡住检测框要么偏了要么大小不对。排查这类问题有个小技巧在调试模式下把检测框坐标和帧metadata一起打印出来人工对比一下目标实际位置和框的位置能快速定位是坐标问题还是时间同步问题。5.3 RTSP 断流、花屏与重连断流是视频AI项目绕不开的问题。原因可能是摄像头重启、网络抖动、带宽打满、摄像头最大连接数限制。我们要做的是让系统在断流之后能自己恢复并且不能影响其他通道。重连策略前面提过要用指数退避。另外要注意重连请求不能堆积。如果摄像头自己有连接数限制我们频繁重连会把它搞崩溃。正确做法是第一次断开后等1秒重试之后翻倍2秒、4秒、8秒……最多等30秒。同时设置一个总的重试次数上限比如连续重试5次失败之后把通道标记为离线等用户手动处理或者定期巡检恢复。花屏一般发生在网络丢包之后H.264码流不完整导致解码出错。处理办法是先检测画面是否连续花屏如果是主动断开重连强制请求新的关键帧一般能恢复。排查RTSP问题命令行工具有几个很实用ffprobe看流参数ffmpeg -rtsp_transport tcp -i rtsp://... -vcodec copy -f null -测试连续拉流是否稳定tcpdump抓包看网络状况。先把问题定位在接入层还是解码层再针对性处理。5.4 排查工具与性能分析三板斧线上问题不好排查一定要靠数据。我们在SmartMediaKit里每个模块都打了耗时埋点统计P50、P99延迟通过Prometheus和Grafana展示。哪个模块耗时异常一眼就能看到。针对性能问题三个工具组合使用效率最高nvidia-smi dmon持续监控GPU利用率、显存占用、温度判断GPU是不是真的打满了。很多时候GPU利用率只有50%说明瓶颈在CPU侧的预处理或数据拷贝而不是推理本身。nsys和ncu可以分析CUDA kernel的执行耗时定位是哪个环节慢是resize、transpose还是卷积算子。CPU侧的热点可以用perf或者pyroscope看找到解码、格式转换这些环节里真正的慢函数。做性能优化最忌讳凭感觉。我们之前判断推理慢优化了一圈发现瓶颈在网络拉流相当于白干。现在养成的习惯是任何优化之前先看数据优化之后再看数据用P50和P99的变化评估优化效果是否真实有效。我在实际项目中最大的体会是YOLO再强也只是算法层面的一件事真正让一个检测模型变成可用的视频AI能力靠的是把视频接入、推理调度、结果分发这些工程问题一个一个解决掉。SmartMediaKit给了我们一套比较顺手的集成方式但核心还是对整个处理链路有清晰的认知——每一帧从摄像头到最终告警经过了哪些环节每个环节的耗时和瓶颈在哪里心里有数系统才不会失控。