C++打开V4L2设备需先确认/dev/video0存在且可读写，再用ioctl(VIDIOC_QUERYCAP)检查V4L2_CAP_VIDEO_CAPTURE和V4L2_CAP_STREAMING支持；设格式时type必须为V4L2_BUF_TYPE_VIDEO_CAPTURE，pixelformat须枚举获取，并用VIDIOC_G_FMT验证驱动是否修改参数。
如何用 C++ 打开 V4L2 设备并检查格式支持
直接 open("/dev/video0", O_RDWR) 不代表设备就 ready，很多嵌入式板子（如 RK3399、i.MX6）默认没有启用摄像头节点，或驱动未加载。先确认 /dev/video0 存在且可读写，再用 ioctl(fd, VIDIOC_QUERYCAP, &cap) 检查是否支持 V4L2_CAP_VIDEO_CAPTURE 和 V4L2_CAP_STREAMING —— 缺一不可。常见错误是只查了 CAPTURE 就开始设格式，结果 VIDIOC_S_FMT 返回 EINVAL，其实是没 streaming 支持。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
ls -l /dev/video*确认节点权限，非 root 用户需加 udev 规则或改组（如video组） - 运行
v4l2-ctl --list-devices和v4l2-ctl -d /dev/video0 --all快速验证驱动状态和当前配置 - 某些 SoC（如全志 H3）需要先
echo 1 > /sys/class/video4linux/video0/power才能响应 ioctl
设置像素格式和分辨率时哪些参数不能乱填
V4L2 对 struct v4l2_format 的 type 字段非常敏感：必须是 V4L2_BUF_TYPE_VIDEO_CAPTURE，填错成 V4L2_BUF_TYPE_VIDEO_OUTPUT 会静默失败；pixelformat 要从 VIDIOC_ENUM_FMT 枚举出来，硬写 V4L2_PIX_FMT_YUYV 可能不被硬件支持 —— 嵌入式摄像头模组（如 OV5640、GC2053）常只支持 YUYV 或 MJPEG，不支持 RGB24。设完格式后务必再用 VIDIOC_G_FMT 读回，检查驱动是否“悄悄”改了 width/height（比如强制对齐到 16 像素边界）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要跳过
VIDIOC_ENUM_FMT枚举步骤，尤其在资源受限的 ARM 平台，驱动可能只暴露 1–2 种格式 - 设分辨率优先选驱动返回的
discrete尺寸，避免用stepwise区间随意指定，否则VIDIOC_S_FMT可能返回成功但实际无效 - YUYV 是最通用的原始格式，比 RGB 更省带宽；若需 RGB，通常得靠用户态转换（用
libyuv或手写查表），别指望硬件直出
内存映射（mmap）方式采集图像的关键陷阱
嵌入式设备 RAM 紧张，mmap 是主流方式，但容易卡在 buffer queue 环节。典型流程是：先 VIDIOC_REQBUFS 申请 N 个 buffer（N=2~4 足够），再对每个 buffer 调 VIDIOC_QUERYBUF 获取 offset，最后 mmap。问题在于：有些 BSP（如 NXP 的 L4.14.98 内核）要求 VIDIOC_REQBUFS 后必须立刻 VIDIOC_QBUF 全部 buffer，否则 VIDIOC_STREAMON 失败；还有些平台（如 Rockchip）对 mmap 的 length 参数极其敏感，必须严格等于 buf.length，多 1 字节都会 mmap 失败。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 调
VIDIOC_REQBUFS前把count设为 0 清空 buffer，防止残留状态干扰 -
VIDIOC_QBUF必须在VIDIOC_STREAMON之前完成，且每个 buffer 的index要从 0 开始连续提交 -
mmap的prot参数用PROT_READ | PROT_WRITE，即使只读也要写权限，某些驱动（如 OV2685 的 v4l2 驱动）内部会写入元数据
为什么 poll() 总是超时，或者图像帧重复/丢帧
嵌入式环境里 poll() 返回 POLLIN 后，必须立刻 VIDIOC_DQBUF 取帧，否则下次 poll() 仍会立即返回（buffer 还在队列里），造成“假唤醒”。更隐蔽的问题是：如果 DQBUF 后忘记 QBUF 回去，buffer 数量越来越少，最终流中断。另外，某些摄像头模组（如 GC0308）在低光照下会自动降帧率，导致应用层按固定间隔 poll() 出现长时间阻塞。
实操建议：
立即学习“C++免费学习笔记（深入）”；
-
poll()的timeout别设 0（忙等）或 -1（死等），设 500ms 较稳妥，超时后检查VIDIOC_STREAMON状态和硬件连接 - 每次
DQBUF成功后，立即用相同index调QBUF，形成循环队列；可用std::queue<uint32_t>管理空闲 index - 用
v4l2-ctl -d /dev/video0 -C brightness查看自动曝光是否开启，关掉它能让帧率稳定，代价是图像可能过曝或欠曝
硬件差异远比文档写的复杂：同一份代码在 RK3326 上跑通，在 AM335x 上可能因 DMA 缓存一致性问题花屏，这时候得查 CONFIG_ARM_DMA_MEM_BUFFERABLE 是否启用，而不是怀疑代码逻辑。
