cv2.VideoCapture(0)初始化耗时20秒是否属于正常现象

cv2.VideoCapture(0) 初始化耗时长达20秒不属于正常现象。常规内置/USB摄像头在驱动、适配正常的情况下，初始化耗时应在1-3秒区间，初始化完成后帧读取、渲染流程正常，说明视频流传输、编解码、渲染链路无硬件或核心逻辑故障，长耗时基本由以下几类原因导致，可对应排查：

• 捕获后端自动枚举重试
  OpenCV调用摄像头时不会直接固定使用系统对应视频接口，会按默认优先级逐个尝试可用的捕获后端（Windows下会依次尝试MSMF、DirectShow、VFW等，Linux下尝试V4L2、GStreamer等），如果某一个后端存在驱动兼容问题，会等待接口超时后再尝试下一个后端，累计耗时很容易拉长到十几到二十秒。
  修复方式是初始化时手动指定适配当前系统的捕获后端，跳过自动枚举流程：
  • Windows环境：替换初始化语句为 cap = cv.VideoCapture(0, cv.CAP_DSHOW)
  • Linux环境：替换初始化语句为 cap = cv.VideoCapture(0, cv.CAP_V4L2)
  • MacOS环境：替换初始化语句为 cap = cv.VideoCapture(0, cv.CAP_AVFOUNDATION)
    绝大多数场景下，指定后端后初始化耗时会回落到正常区间。
• 设备枚举冲突
  如果系统内安装过虚拟摄像头（直播推流虚拟摄像头、会议软件虚拟摄像头、采集卡虚拟设备），这类设备会和实体摄像头一起出现在系统视频设备列表中，OpenCV按序号0打开设备时，可能先尝试打开存在响应问题的虚拟设备，等待超时后才会切到实体摄像头。可以在系统设备管理器中禁用不需要的虚拟视频设备，或者直接指定实体摄像头的设备路径代替序号0做初始化。
• 版本兼容bug
  部分4.5.x、4.6.x分支的OpenCV版本存在已知的MSMF后端初始化bug，搭配高分辨率摄像头时会反复协商分辨率、帧率参数直到超时，升级到最新稳定版OpenCV即可修复。
• 系统权限等待
  MacOS 10.14及以上版本、部分开启安全模块的Linux发行版，会在应用首次调用摄像头时触发权限校验，如果系统权限服务响应延迟，等待用户授权/权限校验的时间会被计入VideoCapture的初始化耗时。在系统隐私设置中提前给对应运行环境开放摄像头权限，即可消除这类等待耗时。

测试代码 #

import numpy as np
import cv2 as cv

cap = cv.VideoCapture(0)   # 原语句此处存在长耗时

if not cap.isOpened():
    print("Cannot open camera")
    exit()
while True:
    # 逐帧捕获
    ret, frame = cap.read()
    # 帧读取成功时ret为True
    if not ret:
        print("Can't receive frame (stream end?). Exiting ...")
        break
    gray = cv.cvtColor(frame, cv.COLOR_BGR2GRAY)
    cv.imshow('frame', gray)
    if cv.waitKey(1) == ord('q'):
        break
cap.release()
cv.destroyAllWindows()

上述代码的帧读取、渲染逻辑无问题，不需要调整循环部分的实现。

内容的提问来源于stack exchange，提问作者daniel