3. 帧率控制与同步：固定帧率读取、时间戳同步、丢帧策略

摄像头流调优，说白了就是跟「时间」打交道。你想想看，摄像头采集、OpenCV 解码、YOLO 推理、结果绘制，这一整套流程跑下来，每一帧花的时间都不一样。如果不管不顾地死循环读帧，视频流要么卡成 PPT，要么内存爆掉。

我个人习惯，拿到一个摄像头项目，第一件事不是调模型，而是先把帧率控制写好。为什么？因为帧率不稳，后面所有优化都是白搭。

3.1 固定帧率读取：别让摄像头牵着鼻子走

很多新手写摄像头读取，直接这样：

while True:
    ret, frame = cap.read()
    # 处理 frame...

这有什么问题？cap.read() 是阻塞的，摄像头给多快，你就读多快。如果摄像头是 60fps，你的处理跟不上，帧队列就会越积越多，延迟越来越高。

我建议的做法，是主动控制读取节奏：

import cv2
import time

cap = cv2.VideoCapture(0)
target_fps = 30
frame_time = 1.0 / target_fps

while True:
    t_start = time.time()
    
    ret, frame = cap.read()
    if not ret:
        break
    
    # 处理 frame...
    
    elapsed = time.time() - t_start
    sleep_time = frame_time - elapsed
    if sleep_time > 0:
        time.sleep(sleep_time)

核心逻辑就一句话：每帧固定间隔，处理快了就等，处理慢了就丢。这个「等」很关键，它让整个系统的节奏可控。

3.2 时间戳同步：给每一帧打上「身份证」

固定帧率只是第一步。真正做多路摄像头、或者摄像头与传感器融合时，时间戳才是命根子。

我在项目中遇到过一个问题：两路摄像头分别采集画面，一路 30fps，一路 15fps。如果不用时间戳对齐，你根本不知道哪两帧是「同时」拍的。结果做拼接时，画面错位，看起来像鬼影。

时间戳的添加时机很讲究。我建议在 cap.read() 返回后 立即 打戳，越早越好：

import cv2
import time

cap = cv2.VideoCapture(0)
while True:
    t_capture = time.time()  # 读帧前打戳
    ret, frame = cap.read()
    
    if not ret:
        continue
    
    # 将时间戳附加到帧上
    timestamp = t_capture
    
    # 后续处理...

为什么不在 cap.read() 之后打？因为 read() 本身可能阻塞几十毫秒，等它返回再打戳，时间已经不准了。

打戳时机	优点	缺点
read() 之前	最接近真实采集时间	如果 read() 失败，戳白打了
read() 之后	简单直接	包含了解码延迟，不准
处理完成之后	记录输出时间	完全不反映采集时间

我个人习惯用 双时间戳：一个记录采集时间（t_capture），一个记录处理完成时间（t_done）。这样既能对齐帧，又能监控处理延迟。

3.3 丢帧策略：当处理跟不上时，果断放弃

这是最容易被忽视，但也是最关键的一环。你想想看，如果 YOLO 推理需要 50ms，而摄像头是 30fps（33ms 一帧），那处理速度永远追不上采集速度。这时候怎么办？

我曾经见过一个项目，没有丢帧策略，结果内存占用一路飙升，最后程序 OOM 被系统杀掉。嗯，这就是典型的「处理不过来了还在硬扛」。

丢帧策略的核心思想：只处理最新的帧，跳过积压的旧帧。

import cv2
import time
from collections import deque

cap = cv2.VideoCapture(0)
frame_queue = deque(maxlen=2)  # 只保留最近 2 帧

def capture_thread():
    while True:
        ret, frame = cap.read()
        if ret:
            frame_queue.append((time.time(), frame))

def process_thread():
    while True:
        if len(frame_queue) == 0:
            time.sleep(0.001)
            continue
        
        # 只取最新的一帧
        timestamp, frame = frame_queue[-1]
        frame_queue.clear()  # 丢掉所有旧帧
        
        # 用 timestamp 和 frame 做推理...

丢帧策略有三种常见模式：

1. 最新帧优先：只处理队列里最新的帧，其余全丢。适合实时性要求高的场景。
2. 固定间隔采样：每 N 帧处理一帧，其余直接丢弃。适合处理能力固定的场景。
3. 自适应丢帧：根据处理耗时动态调整丢帧率。处理慢了就多丢，处理快了就少丢。

我个人最常用的是「最新帧优先 + 自适应」的组合。先保证实时性，再根据 CPU 负载动态调整目标帧率。

3.4 整体流程：帧率控制与同步的完整架构

把上面三块拼起来，就是一个完整的帧率控制与同步系统。我画了一张图，你看一眼就明白了：

3.5 实战避坑指南

最后分享几个我踩过的坑：

• 别用 cv2.waitKey() 做帧率控制。它的精度只有 10ms 左右，而且在不同操作系统上表现不一致。用 time.sleep() 或 time.perf_counter() 循环等待更靠谱。
• 多线程时注意时间戳竞争。采集线程和处理线程共享帧队列，时间戳必须在采集线程中打，不要在消费时补打。
• 丢帧计数器一定要加。我曾经调试一个项目，总觉得画面卡，加了丢帧计数器才发现每秒丢了 20 帧。没有数据，你根本不知道问题在哪。
• 固定帧率不要设得太高。设 30fps 但实际只能跑 15fps，那丢帧策略会疯狂丢帧，画面反而更差。我建议先测一下处理耗时，再反推目标帧率。