Ubuntu下OpenCV摄像头打不开？从V4L2到GStreamer的完整排查指南

发布时间：2026/10/14 6:23:18
Ubuntu下OpenCV摄像头打不开？从V4L2到GStreamer的完整排查指南
1. 从一次深夜调试说起摄像头为什么就是打不开如果你在 Ubuntu 上跑过 OpenCV 的摄像头采集代码大概率见过下面这种场景代码逻辑看着没问题cv2.VideoCapture(0)也写了但程序要么直接返回False要么卡在read()上不动要么弹出一堆GStreamer的警告然后给你一个空帧。更让人抓狂的是同样的代码在别人的机器上跑得好好的换到你这台 Ubuntu 上就死活不出画面。这个问题的本质是 Linux 的摄像头访问链路比 Windows 和 macOS 复杂得多。在 Windows 上OpenCV 走的是 DirectShow 或者 Media Foundation系统帮你把设备枚举、权限、格式协商都处理得差不多了。但在 Ubuntu 上一个 USB 摄像头从插上到 OpenCV 拿到帧中间要经过内核的 UVC 驱动、V4L2 子系统、用户态的权限控制、OpenCV 的 backend 选择、以及编解码格式的协商。这条链路上任何一环出问题你看到的都是同一个结果——打不开。我前后在 Ubuntu 上折腾过十几种不同型号的摄像头从笔记本自带的集成摄像头到各种 USB 外接模组踩过的坑基本覆盖了这条链路的每一个环节。这篇文章就把这些经验系统性地梳理一遍从最基础的设备识别开始到权限、格式、backend 选择、容器环境一层一层往下拆。不管你是刚接触 OpenCV 的新手还是已经在做视觉项目的老手只要你的摄像头在 Ubuntu 上出过问题这里应该都能找到对应的排查思路。文章里涉及的命令和代码都可以直接复制执行我会尽量把每一步的意图和背后的原理讲清楚而不是只丢一个结论让你去试。2. 先确认系统到底认没认到这个摄像头很多人一上来就怀疑 OpenCV 的代码写错了其实第一步应该先跳出 OpenCV看看操作系统层面有没有正确识别设备。如果系统本身就没认到摄像头那后面所有的调试都是白费功夫。2.1 用 lsusb 和 v4l2-ctl 做设备枚举先插上摄像头然后执行lsusb这个命令列出的是 USB 总线上的设备。如果你看到类似ID 1bcf:2c99 Sunplus Innovation Technology Inc.这样的条目说明 USB 层面已经识别到了。注意这里显示的是 USB 设备的厂商 ID 和产品 ID不一定能直接看出是摄像头但至少证明物理连接没问题。接下来要看的是 V4L2Video for Linux 2子系统有没有为这个设备创建视频节点ls -l /dev/video*正常情况下你会看到/dev/video0、/dev/video1这样的设备节点。这里有个容易踩的坑很多现代笔记本或者某些 USB 摄像头会创建多个 video 节点比如/dev/video0是采集节点/dev/video1是元数据节点/dev/video2才是真正的图像流。如果你打开的是错误的节点自然拿不到画面。要确认哪个节点才是真正能出图的用v4l2-ctl来查sudo apt install v4l-utils v4l2-ctl --list-devices这个命令会按设备分组列出所有 video 节点输出类似Integrated Camera: Integrated C (usb-0000:00:14.0-1): /dev/video0 /dev/video1然后针对每个节点查详细能力v4l2-ctl -d /dev/video0 --all重点看Device Caps这一行。如果显示的是Video Capture说明这个节点支持采集如果显示的是Metadata Capture那它就不是用来出图的。这一步能帮你快速排除掉那些看起来像摄像头但其实不是的节点。2.2 用 ffmpeg 或 cheese 做交叉验证确认了设备节点之后先别急着写 Python用系统自带的工具验证一下摄像头能不能出图。最直接的是ffmpegffmpeg -f v4l2 -i /dev/video0 -frames:v 1 test.jpg如果这条命令能生成一张test.jpg并且能看到画面说明从驱动到 V4L2 这一层完全没问题问题就出在 OpenCV 的配置上。如果这条命令也失败那说明问题在更底层需要先解决驱动或权限的问题。另一个常用的工具是cheeseGNOME 的摄像头应用sudo apt install cheese cheesecheese的好处是它会自动处理格式协商如果它能出图而 OpenCV 不能那基本可以锁定是 OpenCV 的 backend 或者格式参数问题。提示ffmpeg和cheese的验证结果要分开看。ffmpeg走的是 V4L2 原生接口cheese走的是 GStreamer。如果ffmpeg能出图但cheese不能说明 GStreamer 的插件或者管道配置有问题这会影响 OpenCV 的 GStreamer backend。2.3 设备节点存在但打不开的几种典型情况有时候ls /dev/video*能看到节点但一打开就报Device or resource busy或者Permission denied。这两种错误的含义完全不同。Device or resource busy通常是因为已经有别的进程占用了摄像头。Linux 的 V4L2 设备默认是独占访问的同一时间只能有一个进程打开。你可以用fuser或者lsof来查sudo fuser -v /dev/video0 sudo lsof /dev/video0如果看到有进程占用把它杀掉再试。常见的占用者包括之前没退干净的 Python 进程、cheese、浏览器里的视频会议页面等。Permission denied则是权限问题这个在下一节详细说。3. 权限问题为什么 sudo 能跑普通用户跑不了权限是 Ubuntu 上摄像头打不开的高频原因之一。典型表现是用sudo python3 test.py能正常出图但去掉sudo就报错。这说明你的普通用户没有访问/dev/video*设备的权限。3.1 检查当前用户所在的组先看看/dev/video0的属主和权限ls -l /dev/video0输出通常是这样的crw-rw---- 1 root video 81, 0 Jan 1 00:00 /dev/video0注意这里的video组。设备属于root用户和video组权限是rw-rw----也就是说只有root和video组的成员才能读写。如果你的普通用户不在video组里自然就打不开。检查当前用户的组groups如果输出里没有video那就需要把你加进去sudo usermod -aG video $USER这里-aG的a是 append 的意思表示追加而不是覆盖。如果不加a会把用户从其他所有组里移除那就出大问题了。改完之后需要重新登录才能生效。你可以先注销再登录或者直接重启。验证一下groups看到video出现在列表里就说明成功了。3.2 udev 规则与 ACL 的交互有些情况下即使你在video组里设备节点的权限也可能被 udev 规则或者 ACL 改掉。注意前面ls -l输出里那个号它表示这个设备有额外的 ACL 权限设置。用getfacl看一下getfacl /dev/video0如果 ACL 里没有你的用户而你又不想重新登录可以临时用setfacl加一下sudo setfacl -m u:$USER:rw /dev/video0不过这只是临时的设备重新插拔或者重启后就失效了。长期方案还是把自己加进video组。还有一种情况是某些发行版或者桌面环境会通过systemd-logind管理设备访问权限。如果你是通过 SSH 远程登录的logind可能不会给你分配本地设备的访问权限。这种情况下即使你在video组里也可能打不开摄像头。解决办法是在本地终端登录或者手动调整logind的配置。3.3 容器和虚拟环境里的权限传递如果你是在 Docker 容器里跑 OpenCV权限问题会更复杂一层。容器默认是隔离的不会自动继承宿主机的设备节点。你需要在启动容器时显式地把设备映射进去docker run --device/dev/video0:/dev/video0 ...如果容器里还有多个 video 节点可以整个映射docker run --device/dev/video0 --device/dev/video1 ...另外容器里的用户 ID 和宿主机可能不一致导致即使设备映射进去了容器内的用户还是没有权限。这时候要么在容器里也用root跑不推荐要么确保容器内用户的 UID 和宿主机video组的 GID 匹配。注意在容器里跑摄像头采集时除了设备节点还需要确保容器内的/dev下有对应的节点。有些精简的基础镜像可能没有完整的/dev目录结构需要手动挂载或者用--privileged模式安全性较差仅建议在开发环境使用。4. OpenCV 的 backend 选择V4L2、GStreamer 还是 FFmpeg权限和设备都没问题之后下一个要排查的就是 OpenCV 用哪个 backend 来访问摄像头。OpenCV 在 Linux 上支持多种视频采集 backend不同的 backend 走的是完全不同的底层路径行为差异很大。4.1 查看当前 OpenCV 编译了哪些 backend先确认你的 OpenCV 到底支持哪些 backendimport cv2 info cv2.getBuildInformation() print(info)在输出里找Video I/O这一段你会看到类似Video I/O: DC1394: NO FFMPEG: YES avcodec: YES avformat: YES avutil: YES swscale: YES avresample: NO GStreamer: YES v4l/v4l2: YES gPhoto2: NO这里v4l/v4l2和GStreamer都是YES的话说明两种 backend 都可用。OpenCV 默认会优先选择 V4L2但在某些情况下会自动切换到 GStreamer。4.2 显式指定 backend 的写法如果你怀疑是 backend 的问题可以在代码里显式指定import cv2 # 显式使用 V4L2 cap cv2.VideoCapture(0, cv2.CAP_V4L2) # 或者显式使用 GStreamer cap cv2.VideoCapture(0, cv2.CAP_GSTREAMER) if not cap.isOpened(): print(无法打开摄像头) exit() ret, frame cap.read() if ret: cv2.imwrite(frame.jpg, frame) cap.release()实测下来V4L2 backend 对大多数 USB 摄像头兼容性最好因为它直接走内核的 V4L2 接口路径最短。GStreamer backend 的优势在于支持更复杂的管道配置比如你需要做格式转换、缩放、编码的时候可以用 GStreamer 的 pipeline 字符串来精确控制。4.3 GStreamer 管道字符串的实战写法用 GStreamer backend 的时候你可以直接传一个 pipeline 字符串给VideoCapturepipeline ( v4l2src device/dev/video0 ! video/x-raw,width640,height480,framerate30/1 ! videoconvert ! appsink ) cap cv2.VideoCapture(pipeline, cv2.CAP_GSTREAMER)这个 pipeline 的意思是从/dev/video0采集协商成 640x480、30fps 的原始格式然后转换成 OpenCV 能处理的格式最后通过appsink交给 OpenCV。这种写法的好处是你可以精确控制格式协商的每一个环节。比如某些摄像头默认输出的是 MJPEG 格式OpenCV 的 V4L2 backend 有时候处理不好但用 GStreamer 就可以显式指定pipeline ( v4l2src device/dev/video0 ! image/jpeg,width1280,height720,framerate30/1 ! jpegdec ! videoconvert ! appsink )这里image/jpeg指定了摄像头输出 MJPEGjpegdec负责解码videoconvert做颜色空间转换。这条 pipeline 能解决很多 V4L2 backend 下 MJPEG 摄像头出不了图的问题。4.4 backend 选择背后的取舍逻辑为什么 OpenCV 不直接统一用一个 backend因为不同 backend 的设计目标不同。V4L2 是 Linux 原生的视频采集接口延迟最低但功能相对基础对格式协商的容错性一般。GStreamer 是一个完整的多媒体框架功能强大支持复杂的管道和插件但启动开销大配置复杂。FFmpeg 的 backend 更多用于文件解码摄像头采集不是它的强项。我的经验是先用 V4L2 试如果打不开或者格式不对再换 GStreamer。如果两个都不行那问题大概率不在 backend而在更底层的驱动或权限。5. 格式协商失败MJPEG、YUYV 与分辨率陷阱摄像头打不开的另一个高频原因是格式协商失败。USB 摄像头的带宽有限不同的分辨率和帧率组合对应不同的传输格式如果 OpenCV 请求的格式摄像头不支持协商就会失败。5.1 用 v4l2-ctl 查看摄像头支持的所有格式v4l2-ctl -d /dev/video0 --list-formats-ext输出会列出所有支持的像素格式和对应的分辨率、帧率。比如ioctl: VIDIOC_ENUM_FMT Type: Video Capture [0]: YUYV (YUYV 4:2:2) Size: Discrete 640x480 Interval: Discrete 0.033s (30.000 fps) Size: Discrete 1280x720 Interval: Discrete 0.100s (10.000 fps) [1]: MJPG (Motion-JPEG) Size: Discrete 640x480 Interval: Discrete 0.033s (30.000 fps) Size: Discrete 1280x720 Interval: Discrete 0.033s (30.000 fps) Size: Discrete 1920x1080 Interval: Discrete 0.033s (30.000 fps)这个输出信息量很大。你可以看到 YUYV 格式在 1280x720 下只能跑 10fps而 MJPEG 在同样分辨率下能跑 30fps。这是因为 YUYV 是未压缩格式数据量大USB 带宽不够MJPEG 是压缩格式数据量小所以能支持更高分辨率。5.2 OpenCV 默认请求的格式为什么经常失败OpenCV 的 V4L2 backend 默认会尝试用 YUYV 格式因为它是未压缩的处理起来最简单。但很多摄像头在高分辨率下只支持 MJPEG不支持 YUYV。这时候 OpenCV 请求 YUYV 就会失败表现为isOpened()返回False或者read()一直返回空。解决办法是在打开摄像头之前先用cap.set()设置格式import cv2 cap cv2.VideoCapture(0, cv2.CAP_V4L2) cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc(M, J, P, G)) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) cap.set(cv2.CAP_PROP_FPS, 30) if not cap.isOpened(): print(打开失败) exit() ret, frame cap.read() print(读取结果:, ret, 帧形状:, frame.shape if ret else None) cap.release()注意CAP_PROP_FOURCC的设置顺序很关键。有些摄像头要求在设置分辨率之前先设置 FOURCC有些则相反。如果一次不成功可以调整顺序多试几次。5.3 分辨率与帧率的组合约束即使格式对了分辨率和帧率的组合也可能超出摄像头的能力。比如你请求 1920x108060fps但摄像头在 1080p 下最高只支持 30fps协商就会失败。一个实用的排查方法是先用v4l2-ctl列出所有支持的组合然后从最低的分辨率和帧率开始试逐步往上加。比如先试 640x48030fps成功了再试 1280x72030fps最后试 1920x108030fps。这样能快速定位到摄像头的能力边界。另外要注意cap.set()的返回值表示设置是否成功但即使返回True也不代表摄像头真的用了你请求的参数。最可靠的方法是设置完之后用cap.get()读回来确认actual_width cap.get(cv2.CAP_PROP_FRAME_WIDTH) actual_height cap.get(cv2.CAP_PROP_FRAME_HEIGHT) actual_fps cap.get(cv2.CAP_PROP_FPS) actual_fourcc int(cap.get(cv2.CAP_PROP_FOURCC)) print(f实际参数: {actual_width}x{actual_height} {actual_fps}fps, FOURCC: {actual_fourcc})如果读回来的值和请求的不一样说明摄像头做了降级或者用了默认值这时候就要根据实际值来调整你的处理逻辑。6. 那些让人摸不着头脑的报错与日志摄像头打不开的时候终端里经常会刷出一堆看起来毫无头绪的日志。这些日志其实包含了关键线索只是需要知道去哪里找、怎么看。6.1 GStreamer 的警告信息怎么读如果你用的是 GStreamer backend打不开的时候经常会看到类似这样的输出[ WARN:0] global /path/to/opencv/modules/videoio/src/cap_gstreamer.cpp (xxx) handleMessage OpenCV | GStreamer warning: Embedded video playback halted; module v4l2src0 reported: Internal data stream error.这条日志的关键信息是v4l2src0 reported: Internal data stream error。它说明 GStreamer 的v4l2src元素在从设备读取数据时出错了。常见原因包括设备被占用、格式协商失败、或者设备节点不对。另一条常见的警告是GStreamer warning: cannot query video position: status0, value-1, duration-1这条通常不是致命错误只是说明 GStreamer 无法获取视频的位置信息对于实时采集来说可以忽略。6.2 V4L2 的 ioctl 错误码含义用 V4L2 backend 的时候错误信息通常更底层比如VIDIOC_QUERYCAP: Inappropriate ioctl for device这个错误说明你打开的设备节点不是 V4L2 采集设备。可能是打开了一个元数据节点或者打开的根本不是视频设备。回到第 2 节用v4l2-ctl --all确认节点的Device Caps。另一个常见的VIDIOC_S_FMT: Device or resource busy这个说明设备已经被占用了。用fuser或lsof找到占用进程并杀掉。6.3 用 v4l2-ctl 直接抓帧做底层验证如果 OpenCV 的日志看不明白可以用v4l2-ctl直接抓一帧出来绕过 OpenCV 和 GStreamerv4l2-ctl -d /dev/video0 --set-fmt-videowidth640,height480,pixelformatMJPG --stream-mmap --stream-count1 --stream-totest.raw这条命令会从/dev/video0抓一帧 MJPEG 数据保存到test.raw。如果这条命令成功说明从驱动到 V4L2 这一层完全正常问题就在 OpenCV 的配置上。如果这条命令也失败那就要往驱动和硬件方向排查了。test.raw是原始的 MJPEG 数据可以用ffmpeg转成图片看ffmpeg -f mjpeg -i test.raw test.jpg6.4 dmesg 里的 USB 和 UVC 线索如果上面所有方法都失败了最后要看的是内核日志dmesg | tail -50插拔摄像头的时候观察dmesg的输出能看到 USB 枚举和 UVC 驱动加载的过程。常见的错误包括uvcvideo: Failed to query (GET_DEF) UVC control摄像头固件有问题某些控制项不支持。usb 1-1: device descriptor read/64, error -71USB 通信错误可能是线缆或者接口问题。uvcvideo: Found UVC 1.00 device这是正常的识别日志。如果dmesg里连 UVC 设备的识别日志都没有那说明摄像头在 USB 层面就没被正确识别需要检查线缆、接口、供电等问题。7. 特殊场景虚拟机、WSL 与远程桌面下的摄像头前面讲的都是物理机上的情况。如果你是在虚拟机、WSL 或者远程桌面环境下跑 Ubuntu摄像头的问题会更复杂。7.1 虚拟机里的 USB 直通配置在虚拟机里摄像头默认是连到宿主机的虚拟机看不到。你需要在虚拟机软件里把 USB 设备直通给虚拟机。以常见的虚拟机软件为例需要在设置里找到 USB 控制器然后把摄像头设备添加进去。直通之后虚拟机里的 Ubuntu 应该能像物理机一样看到/dev/video0。但要注意直通之后宿主机就不能再用这个摄像头了两者是互斥的。另外虚拟机的 USB 控制器版本也会影响兼容性。USB 3.0 控制器对某些摄像头的兼容性不如 USB 2.0如果直通后识别有问题可以试试切换到 USB 2.0 控制器。7.2 WSL2 下的摄像头访问限制WSL2 本质上是一个轻量级虚拟机默认不支持 USB 设备直通。虽然微软后来加入了一些 USB 支持但对摄像头的支持仍然很有限。如果你在 WSL2 里跑 OpenCV大概率是找不到/dev/video*的。一个变通方案是在 Windows 侧用 OpenCV 采集然后通过网络把帧传给 WSL2 里的程序处理。但这已经超出了在 Ubuntu 上打开摄像头的范畴属于架构层面的调整。7.3 远程桌面下的设备访问如果你是通过远程桌面比如 VNC、RDP连接到 Ubuntu 机器摄像头可能因为logind的会话管理而无法访问。前面提到过logind会根据会话类型分配设备权限远程会话通常不会被授予本地设备的访问权。解决办法是在本地终端登录或者手动调整logind的配置。另一个方案是用v4l2loopback创建一个虚拟视频设备把摄像头的流转发到这个虚拟设备上这样远程会话也能访问。sudo apt install v4l2loopback-dkms sudo modprobe v4l2loopback加载之后会多出一个/dev/videoN节点你可以用ffmpeg把真实摄像头的流转发过去ffmpeg -f v4l2 -i /dev/video0 -f v4l2 /dev/videoN这样 OpenCV 打开/dev/videoN就能拿到画面了。8. 一套可复用的排查流程与我的实操心得把前面所有内容串起来我整理了一套排查流程。每次遇到摄像头打不开按这个顺序走一遍基本能定位到问题所在。8.1 从硬件到 OpenCV 的逐层排查清单排查层级检查命令预期结果常见问题USB 识别lsusb看到摄像头设备线缆、接口、供电设备节点ls /dev/video*存在 video 节点驱动未加载节点能力v4l2-ctl --allDevice Caps 为 Video Capture打开了元数据节点权限groups包含 video 组未加入 video 组占用fuser /dev/video0无输出其他进程占用格式v4l2-ctl --list-formats-ext列出支持的格式请求了不支持的格式底层抓帧v4l2-ctl --stream-mmap成功抓帧驱动或硬件问题OpenCV backendcv2.getBuildInformation()V4L2/GStreamer 为 YESbackend 未编译OpenCV 打开cap.isOpened()返回 Truebackend 或格式问题这张表建议收藏下次遇到问题直接从第一行往下查比盲目试错效率高得多。8.2 几个反直觉的实操经验第一个经验是不要迷信cap.set()的返回值。前面提过cap.set()返回True只代表 OpenCV 接受了你的请求不代表摄像头真的用了这个参数。一定要用cap.get()读回来确认。第二个经验是MJPEG 格式下第一帧可能是坏的。很多摄像头在切换到 MJPEG 格式后第一帧数据不完整read()会返回False或者一张花屏。解决办法是打开摄像头后先连续读几帧丢弃从第二帧或第三帧开始才是稳定的画面cap cv2.VideoCapture(0, cv2.CAP_V4L2) cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc(M, J, P, G)) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) # 丢弃前几帧 for _ in range(5): cap.read() # 从这之后开始正常读取 ret, frame cap.read()第三个经验是USB 延长线和 Hub 是隐形杀手。很多摄像头在直连电脑时工作正常一旦经过 USB 延长线或者 Hub 就出问题。这是因为 USB 摄像头对带宽和供电比较敏感劣质的延长线会导致数据传输出错。如果排查到最后发现是线缆问题换一根短一点的、质量好一点的线往往能直接解决。8.3 写一个带完整错误处理的摄像头封装最后分享一个我在项目里常用的摄像头封装类把前面所有的排查逻辑都集成进去了import cv2 import sys class CameraCapture: def __init__(self, device_id0, width640, height480, fps30, use_mjpegTrue): self.device_id device_id self.width width self.height height self.fps fps self.use_mjpeg use_mjpeg self.cap None def open(self): # 优先用 V4L2 backend self.cap cv2.VideoCapture(self.device_id, cv2.CAP_V4L2) if not self.cap.isOpened(): print(f[错误] 无法打开 /dev/video{self.device_id}) print(请检查1) 设备是否存在 2) 权限是否正确 3) 是否被占用) return False # 设置 MJPEG 格式 if self.use_mjpeg: self.cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc(M, J, P, G)) # 设置分辨率 self.cap.set(cv2.CAP_PROP_FRAME_WIDTH, self.width) self.cap.set(cv2.CAP_PROP_FRAME_HEIGHT, self.height) self.cap.set(cv2.CAP_PROP_FPS, self.fps) # 读回实际参数 actual_w self.cap.get(cv2.CAP_PROP_FRAME_WIDTH) actual_h self.cap.get(cv2.CAP_PROP_FRAME_HEIGHT) actual_fps self.cap.get(cv2.CAP_PROP_FPS) print(f[信息] 实际参数: {actual_w}x{actual_h} {actual_fps}fps) # 丢弃前几帧等待自动曝光稳定 for _ in range(5): self.cap.read() return True def read(self): if self.cap is None: return False, None return self.cap.read() def release(self): if self.cap is not None: self.cap.release() self.cap None if __name__ __main__: cam CameraCapture(device_id0, width1280, height720, fps30) if not cam.open(): sys.exit(1) while True: ret, frame cam.read() if not ret: print([警告] 读取帧失败) continue cv2.imshow(Camera, frame) if cv2.waitKey(1) 0xFF ord(q): break cam.release() cv2.destroyAllWindows()这个封装类的几个设计点值得说明一是优先用 V4L2 backend因为兼容性最好二是默认启用 MJPEG因为大多数 USB 摄像头在高分辨率下都需要 MJPEG 才能跑满帧率三是打开后丢弃前几帧避免自动曝光和自动白平衡还没稳定就拿到偏色的画面四是读回实际参数并打印方便确认摄像头到底用了什么配置。这套代码我在好几个项目里都用过从笔记本集成摄像头到各种 USB 模组基本都能稳定工作。如果遇到打不开的情况按照第 8.1 节的排查清单走一遍配合这个封装类的错误提示定位问题的速度会快很多。摄像头采集看起来是个很基础的功能但在 Linux 上涉及的层次确实比较多。把这条链路搞清楚之后后面做视频处理、目标检测、实时推理这些上层应用就不会再被底层的设备问题卡住了。