bcm2835-v4l2 / sunxi-v4l2

灵芯派的 V4L2 驱动根本不会因为“设置 320×200”去重启传感器或重新协商媒体类型，它只在驱动层做裁剪/缩放，所以零额外耗时；Windows 的 Direc

 

一、V4L2 为什么敢“秒切”

1. 摄像头硬件本身只输出 固定几种分辨率（比如 1920×1080 MJPEG、640×480 YUYV …）。
2. 灵芯派内核驱动（bcm2835-v4l2 / sunxi-v4l2）在 open() 时就已经让传感器跑在 某一种原生模式（通常是 1920×1080 MJPEG）。
3. 当你 cap.set(CAP_PROP_FRAME_WIDTH, 320) 时，V4L2 只做两件事：
   • 在 VIDIOC_S_FMT 里把返回的 width/height 字段改成 320×200；
   • 后续每次 read() 到达时，驱动 现场做裁剪或缩小，再把数据拷贝到用户空间。
     传感器时钟一次都没停，所以感觉不到延迟。

---

二、Windows DirectShow 为什么“必卡”

1. DirectShow 的 Capture Pin 在 graph 运行后 不允许动态改格式；
2. 你一旦 set(320, 200)，Filter Graph Manager 必须：
   • 停止整个 graph → 释放 Pin → 重新协商 AM_MEDIA_TYPE → 重新 connect → 再 run；
3. 这一步要 重新打开内核流接口，USB 摄像头固件会收到 SET_CUR 请求，很多芯片会 掉电-上电 切换输出，物理重启流 3-4 s 就这样来的。

 

 

1. 灵芯派（V4L2）
   • 驱动确实很少重启传感器，你设任意分辨率都当成「用户想要的后处理尺寸」——实时裁剪/缩放，成本就是 CPU（或 NEON/VPU）算力。
   • 例外：如果你设置的尺寸正好等于驱动列表里的某个原生模式，部分驱动会「顺水推舟」把传感器切过去，这时 CPU 开销为零，但切换本身仍比 Windows 快得多（内核级，无 Pin 重建）。
2. Windows
   • DirectShow / MediaFoundation 的框架规定：Pin 一旦运行就不能改格式，所以「前期固定」与「后期 CPU 裁」是二选一——
     • 想省 CPU → 提前选好原生分辨率，接受 3-4 s 重启；
     • 想秒开 → 原生分辨率+软件 resize，代价是持续占用 CPU/GPU 算力。
   • 因此只有 Windows 才需要纠结「启动慢 vs 运行慢」的权衡。

总结一句话：
灵芯派永远可以「后期软件裁」而几乎不额外耗时；Windows 下如果你不想等 3-8 s，就必须接受后期 CPU 裁。

import cv2, time

def fast_open():
    start = time.time()
    # 1) 原生打开
    cap = cv2.VideoCapture(0, cv2.CAP_DSHOW)
    cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)   # 减少内部缓冲
    # 2) 立即读一帧
    ret, frame = cap.read()
    open_time = time.time()
    print(f"原生打开+首帧: {open_time - start:.3f}s  shape={frame.shape}")

    # 3) 软件缩到目标尺寸
    small = cv2.resize(frame, (320, 200))
    resize_time = time.time()
    print(f"软件缩放耗时: {resize_time - open_time:.3f}s")

    cv2.imshow("small", small)
    cv2.waitKey(0)
    cap.release()

if __name__ == "__main__":
    fast_open()