应主动控制抽帧节奏：实测时间戳计算真实帧间隔，用sleep补时或跳帧；设缓冲区为1；滑动窗口缓存t帧并格式化为(c,t,h,w)；关闭梯度、及时清显存；用置信度阈值和滑动窗口投票平滑输出。
OpenCV抽帧速率与视频流真实FPS不一致怎么办
直接用 cv2.VideoCapture.read() 循环读帧，常导致抽帧频率远高于视频原始帧率（比如标称30 FPS的RTSP流，实际每秒抽出60+帧），特征序列时间戳错乱，3D-CNN输入的时间维度就失效了。
根本原因是OpenCV默认不严格同步解码时钟，尤其对网络流或变码率视频。必须主动控制采样节奏：
- 用
cap.get(cv2.CAP_PROP_FPS)获取视频声明的FPS，但**不能直接信它**——RTSP流常返回0或错误值，得靠实测 - 改用时间戳校验：每次
cap.read()后调用cap.get(cv2.CAP_PROP_POS_MSEC)，记录相邻帧毫秒差，滑动窗口计算真实间隔 - 设定目标帧间隔（如33ms对应30 FPS），若当前帧距上一帧太近，
time.sleep()补齐；太远则跳过该帧（避免堆积） - 对RTSP流，加
cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)减少缓冲区积压，降低延迟
3D-CNN输入张量形状怎么和OpenCV抽帧对齐
PyTorch的 torchvision.models.video.r3d_18 或自定义3D-CNN要求输入是 (N, C, T, H, W)：批次、通道、帧数、高、宽。但OpenCV读出的是 (H, W, C) BGR格式单帧，且帧是逐帧获取的，不是一次性加载。
关键不是“把所有帧读完再堆叠”，而是构建滑动窗口缓存：
- 初始化一个
deque(maxlen=T)（如T=16），每读一帧就cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)转RGB，再cv2.resize(frame, (W, H))到模型输入尺寸（如112×112） - 转成
np.float32并归一化（除以255.0），再np.transpose(..., (2, 0, 1))把通道提到前面 → 得到(C, H, W) - 入队后，若长度满T，则
np.stack(deque_list, axis=2)得到(C, H, W, T)，再np.transpose(..., (0, 3, 1, 2))对齐(C, T, H, W) - 注意：不要用
torch.stack在GPU上实时拼接——CPU→GPU拷贝开销大，先在CPU组好再一次性送入GPU
实时推理时GPU显存爆掉的常见原因
看着只跑单路视频，nvidia-smi 却显示显存占满、OOM报错，大概率不是模型太大，而是数据管道没控住：
-
cv2.VideoCapture对RTSP流未设超时，网络抖动时会卡死并不断重试，后台悄悄缓存几十秒帧数据 - PyTorch默认开启梯度计算（
torch.is_grad_enabled() == True），即使只是推理，也需显式加with torch.no_grad(): - 忘记调用
torch.cuda.empty_cache()—— 尤其在循环中反复新建tensor但没释放引用时，显存不会自动还给系统 - batch size看似是1，但3D-CNN的T维（如16帧）被当成“伪batch”，实际等效batch=16，显存占用≈线性增长
行为识别结果抖动严重，怎么平滑输出
单个16帧窗口的3D-CNN输出一个logits向量，argmax后类别跳变频繁（比如“挥手”→“静止”→“挥手”），不是模型不准，是时间粒度太细、缺乏上下文。
别在后处理里简单取众数，要模拟人类判断节奏：
- 维护一个长度为K（如5）的结果队列，每次新预测插入队尾，移除队首 → 滑动窗口投票
- 但更有效的是加置信度阈值：只当最高logit >
0.7且比第二名高0.3以上时才采纳，否则沿用上一帧结果 - 对连续相同动作维持计数器，只有持续≥3个窗口才触发“动作开始”事件；中断≥2窗口才触发“动作结束”
- 注意：所有这些逻辑必须在CPU做，别让GPU等待后处理，否则帧率直接腰斩
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
