企业官网建设流程全解析

简介：面向Qt与V4L2开发的实践资源，适合需要在Linux环境下完成USB/CSI摄像头采集、实时显示、截图与录像的嵌入式或桌面应用开发者。资源以v4l2框架拉取640×480视频流，转换为QImage后在QLabel/QWidget中呈现，并结合下位机串口通信，可按外部命令触发截图和录像保存。压缩包共225个文件，主体为136个h头文件、30个c源文件与8个cpp文件，另含ffmpeg相关so动态库、pc配置及x264编码库，可直接支撑Linux下的视频编码与封装流程。包体约68.74MB，已有272人学习使用，适合用来理解V4L2采集、Qt显示与串口联调的整体链路。借助目录中的readme、ui设计文件和工程pro配置，可快速定位采集显示模块与录像保存逻辑，节省从驱动层到界面层的对接时间。

1. v4l2拉流 + Qt 显示视频(640*480)，并可截图 与保存视频(录像)：先讲清楚这套方案解决什么

接手过某公司一个桌面端模拟项目X：Linux 工控机上要显示 USB 摄像头画面，界面用 Qt 做，640480 的分辨率，除了实时预览，还得支持随时截图留证、手动录像回放。需求拆开就是标题这句话——v4l2 负责从内核拿帧，Qt 负责把帧画出来，截图和录像在用户态各自落盘。这套组合在 Linux 下的桌面摄像头应用里几乎是最常见、最稳的起点，因为 v4l2 是内核自带框架，Qt 的 QImage 又能直接吃内存像素，不需要引入重型播放链路。适合谁看：手里有 Qt 基础、想在 Linux 下把摄像头采集到显示再到存盘走通一遍的嵌入式或桌面开发者。分辨率为什么不选 1080p？因为 640480 是大多数 US 摄像头驱动的默认出图，带宽占用小、调试成本低，把这条链路跑通了，换高分辨率只是改几个枚举值的问题。

2. v4l2 设备初始化：从打开 /dev/video0 到配好 640*480 参数

2.1 先别急着写代码：用 v4l2-ctl 摸清摄像头底细

拿到一个新摄像头，我的习惯是先用命令行工具确认它到底支持什么格式，而不是直接往代码里写V4L2_PIX_FMT_YUYV。很多 USB 摄像头默认出 MJPEG，你以为设置 YUYV 成功了，实际驱动悄悄换成了别的格式，或者只支持 320*240。先跑两条命令：

ls -l /dev/video* v4l2-ctl --device=/dev/video0 --list-formats-ext

逻辑说明：v4l2-ctl来自 v4l-utils 软件包，--list-formats-ext会列出设备支持的像素格式、分辨率区间和帧率。输出里能看到类似[0]: 'YUYV' (YUYV 4:2:2) 640x480这样的行，说明 640*480 下的原生格式是 YUYV；如果只有'MJPG'，那驱动层面无法直接给你 YUYV 原始帧，后续要么接受 MJPEG 解压，要么找驱动参数协商。参数含义：-d指定设备节点，--list-formats-ext是只读查询，不会改变设备状态，可以放心跑。

2.2 打开设备并设置采集格式：VIDIOC_S_FMT 的正确用法

设置格式是整个链路里最容易出“玄学”问题的环节——你以为设置成功了，摄像头其实没理你。v4l2 规范允许驱动修改你提交的格式参数，所以必须读回实际结果。我一般这样写：

#include <linux/videodev2.h> #include <sys/ioctl.h> #include <fcntl.h> #include <unistd.h> #include <cstring> #include <cstdio> int fd = open("/dev/video0", O_RDWR); if (fd < 0) { perror("open /dev/video0"); return -1; } struct v4l2_format fmt; memset(&fmt, 0, sizeof(fmt)); fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; fmt.fmt.pix.width = 640; fmt.fmt.pix.height = 480; fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; fmt.fmt.pix.field = V4L2_FIELD_NONE; // 渐进扫描，隔行采集这里会出问题 if (ioctl(fd, VIDIOC_S_FMT, &fmt) < 0) { perror("VIDIOC_S_FMT"); close(fd); return -1; } // 读回实际协商后的格式，驱动可能改尺寸和像素格式 ioctl(fd, VIDIOC_G_FMT, &fmt); printf("actual: %ux%u, pixelfmt=0x%08x\n", fmt.fmt.pix.width, fmt.fmt.pix.height, fmt.fmt.pix.pixelformat);

逻辑说明：VIDIOC_S_FMT是设置格式的 ioctl，fmt.fmt.pix里的 width、height、pixelformat 三项是核心。设置完必须再用VIDIOC_G_FMT读一次，对比是否真的拿到了 640*480。参数说明：V4L2_PIX_FMT_YUYV表示每个像素 2 字节，Y 分量和 UV 分量交错存放；V4L2_FIELD_NONE表示不隔行，现代 USB 摄像头基本都是这个值。

2.3 申请帧缓冲并映射：REQBUFS + mmap 的完整配合

v4l2 的采集模式里，我常用 mmap 方式：驱动在内核里准备几块缓冲区，用户态通过 mmap 映射后直接读内存。这样做的好处是零拷贝，采集循环里不需要 malloc 新内存。申请缓冲和映射的代码：

struct v4l2_requestbuffers req; memset(&req, 0, sizeof(req)); req.count = 4; // 环形缓冲数量，4 足够在 640*480 下平滑采集 req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; req.memory = V4L2_MEMORY_MMAP; if (ioctl(fd, VIDIOC_REQBUFS, &req) < 0) { perror("VIDIOC_REQBUFS"); return -1; } // 每块缓冲都需要单独映射 void* buf_base[4] = {nullptr}; size_t buf_len[4] = {0}; struct v4l2_buffer buf; for (int i = 0; i < 4; i++) { memset(&buf, 0, sizeof(buf)); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; buf.index = i; ioctl(fd, VIDIOC_QUERYBUF, &buf); buf_len[i] = buf.length; // buf.m.offset 是驱动给出的页对齐偏移，mmap 时必须用它 buf_base[i] = mmap(nullptr, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, buf.m.offset); // 映射后立刻入队，让驱动知道这块缓冲可以写入数据 ioctl(fd, VIDIOC_QBUF, &buf); }

逻辑说明：VIDIOC_REQBUFS只是申请缓冲数量，真正拿到地址要靠QUERYBUF查询m.offset，再用mmap映射到用户态。buf.index是缓冲编号，环形队列里靠它区分哪块缓冲准备好了。参数说明：req.count在 3 到 5 之间比较合适，太少容易在显示慢时丢帧，太多占内存（640*480 YUYV 每帧约 614KB，4 块也就 2.4MB）。这里的PROT_READ | PROT_WRITE表示映射区域可读可写，MAP_SHARED让内核与用户态共享同一块物理内存。

2.4 启动采集循环：STREAMON 之后反复 DQBUF/QBUF

缓冲全部入队后，用VIDIOC_STREAMON开启数据流。采集循环就是个“取出→处理→放回”的闭环，处理阶段就是后面 Qt 显示和截图录像的入口。核心代码：

enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE; ioctl(fd, VIDIOC_STREAMON, &type); while (g_running) { struct v4l2_buffer buf; memset(&buf, 0, sizeof(buf)); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; // DQBUF 阻塞等待一帧就绪，取出的缓冲被驱动标记为“用户态持有” if (ioctl(fd, VIDIOC_DQBUF, &buf) < 0) { if (errno == EAGAIN) continue; // 非阻塞模式下无帧可用 break; } // buf.index 表示这次拿到了哪块缓冲 // buf.bytesused 是实际数据长度，640*480 YUYV 应为 640*480*2 uint8_t* frame_data = static_cast<uint8_t*>(buf_base[buf.index]); process_frame(frame_data, buf.bytesused); // 处理完必须 QBUF 还回去，否则几轮后系统无缓冲可用，画面卡死 ioctl(fd, VIDIOC_QBUF, &buf); } type = V4L2_BUF_TYPE_VIDEO_CAPTURE; ioctl(fd, VIDIOC_STREAMOFF, &type);

逻辑说明：DQBUF是出队，把驱动填好数据的缓冲交给用户态；处理完用QBUF入队归还。这个循环的节奏决定了帧率，如果process_frame耗时超过一帧间隔，采集就会掉帧。我在 projectX 里把process_frame做得很轻——只拷贝一份 QImage 的内存并发出信号，不在这里调用 Qt 的刷新操作。参数说明：buf.bytesused在突发错误时可能变成 0，处理前要判断；EAGAIN只在非阻塞模式出现；STREAMOFF是停止采集，退出循环后必须调用，否则再次打开设备会报设备忙。

3. Qt 显示视频帧：YUV 转 RGB 与刷新架构的两种写法

3.1 架构选择：采集线程 + 信号槽，而不是在循环里刷 UI

新手最容易踩的坑，是在process_frame里直接调用ui->label->setPixmap()。这个操作会卡住采集循环，UI 线程又被 Qt 事件循环占着，两边互相等，画面帧率直接下来。正确做法是把采集放进独立线程，线程拿到帧后转换成QImage，通过信号槽通知主线程刷新。我先定义一个采集线程类：

class CaptureThread : public QThread { Q_OBJECT public: CaptureThread(int fd, void** buf_base, size_t* buf_len) : m_fd(fd), m_buf_base(buf_base), m_buf_len(buf_len), m_running(true) {} void stop() { m_running = false; } signals: void frameReady(const QImage& frame); protected: void run() override { while (m_running) { // DQBUF、转换 QImage、调用 emit frameReady(img) // 发射信号时 Qt 会把 QImage 拷贝到主线程事件队列 } } };

设置好信号槽连接后，主线程只需要QLabel::setPixmap。信号参数用const QImage&是常见做法，Qt 的跨线程队列连接会做深拷贝，避免消费者用完后生产者还在改内存。我自己习惯在信号参数前加const，这是血泪经验——不加修饰的引用在跨线程队列里容易被误写成直连，变成隐式共享，画面出现半个帧的残影。

3.2 YUYV 转 RGB32：自己写转换函数还是用库

v4l2 给出来的 YUYV 是 4:2:2 采样，Qt 不认这种格式，必须转成QImage::Format_RGB32或Format_RGB888。用 ffmpeg 的 swscale 代价太大，为了 640*480 引入整个解码库不划算。我直接写一个精简转换，每两个 Y 加一个 U、一个 V 组成四个像素点：

void convert_yuyv_to_rgb32(const uint8_t* yuyv, uint32_t* rgb, int width, int height) { // 640*480 满帧时 yuyv 长度 = width * height * 2 for (int y = 0; y < height; y++) { for (int x = 0; x < width; x += 2) { int i = (y * width + x) * 2; int y0 = yuyv[i] - 16; int y1 = yuyv[i + 2] - 16; int u = yuyv[i + 1] - 128; int v = yuyv[i + 3] - 128; // 标准 BT.601 公式，注意符号处理 int r = (298 * y0 + 409 * v + 128) >> 8; int g = (298 * y0 - 100 * u - 208 * v + 128) >> 8; int b = (298 * y0 + 516 * u + 128) >> 8; rgb[y * width + x] = 0xFF000000 | clamp(r) << 16 | clamp(g) << 8 | clamp(b); r = (298 * y1 + 409 * v + 128) >> 8; g = (298 * y1 - 100 * u - 208 * v + 128) >> 8; b = (298 * y1 + 516 * u + 128) >> 8; rgb[y * width + x + 1] = 0xFF000000 | clamp(r) << 16 | clamp(g) << 8 | clamp(b); } } }

讲解：y0/y1是两个亮度分量，u/v是该像素对共用的色度分量。BT.601 的系数是给标清视频用的，640480 正合适。这里的clamp()是自己写的限幅函数，把值夹在 0~255 之间，不做会出颜色溢出。性能上这个双层循环在 640480 下约 30 万次迭代，现代桌面 CPU 单线程轻松跑满 30fps；如果换 1080p，这套朴素循环会吃力，到时候再考虑 SIMD 或库。

3.3 刷新节流：控制 setPixmap 的频率

采集线程按摄像头的帧率发信号，比如 30fps，但 UI 刷新不一定需要这么高频。如果主循环里同时跑录像、截图、按钮事件，每秒 30 次setPixmap会让 Qt 的绘制线程很忙。我习惯做一层节流：记录上次显示时间，超过 33ms（约 30fps）才刷新，或者把采集帧率固定到 25fps，这样录像按 25fps 落盘时帧间隔均匀，不会时快时慢。关键思路是：采集、显示、录像三个频率互相解耦，各自用各自的时间基准。

// 主线程槽函数 void MainWindow::onFrameReady(const QImage& img) { // 节流到 30fps，避免高帧率摄像头拖累界面 qint64 now = QDateTime::currentMSecsSinceEpoch(); if (now - m_lastShowMs < 33) return; m_lastShowMs = now; m_currentFrame = img; // 深拷贝一份，供截图按钮使用 ui->label->setPixmap(QPixmap::fromImage(img.scaled(ui->label->size(), Qt::KeepAspectRatio, Qt::SmoothTransformation))); }

scaled是必要的，因为标签控件往往不是正好 640*480。参数说明：Qt::KeepAspectRatio防止画面拉伸变形；Qt::SmoothTransformation会让缩放时走双线性插值，显示效果比快速变换好，代价是每帧多几毫秒 CPU。这里存储m_currentFrame时是深拷贝，截图按钮拿到的是完整帧，不受scaled影响。

4. 截图与录像保存：从帧缓存到 PNG/MP4 的完整链路

4.1 截图：从 QImage 到磁盘文件的两种路径

截图最直接的方式是按钮槽函数里把m_currentFrame.save()写到磁盘，因为m_currentFrame是我们自己维护的深拷贝，安全可靠。另一种做法从QLabel的当前 pixmap 抠图：ui->label->pixmap().toImage()，但这个图是被scaled过的，尺寸是控件大小，不是原始 640*480，除非你刻意要截图所见即所得，否则不推荐。我保留两条路径，默认走第一路：

void MainWindow::onSnapshotBtn() { // 取当前帧，加时间戳做文件名，避免覆盖 QImage snap = m_currentFrame; // 引用计数浅拷贝，但 m_currentFrame 不被修改，安全 QString name = QString::fromLocal8Bit("snap_%1.png") .arg(QDateTime::currentMSecsSinceEpoch()); if (snap.save(name, "PNG")) { statusBar()->showMessage(QString("截图已保存: %1").arg(name)); } }

save的第二参数指定格式，不传的话 Qt 根据后缀推，PNG 在 Linux 下默认由 Qt 的插件支持。场景里若对截图的实时性要求高，可以给采集线程加一个captureRequested标志，一旦收到按钮信号，下一帧到达时直接保存原始转出的 QImage，而不是等主线程槽函数慢慢深拷贝。640*480 的 PNG 大约 200~400KB，生成速度在毫秒级，普通按钮逻辑足够。

4.2 录像方案选型：原始帧直存 vs 压缩编码

录像保存比截图多一层取舍：存什么格式、压不压缩。我先给三种方案的对比，这是在做之前一定要想清楚的成本账：

原始帧直存在调试阶段很值，因为帧内容和摄像头输出完全一致，方便排除编码器带来的干扰；但 35GB/分钟对磁盘压力太大，我通常只用来验证采集链路完整性。MJPG 方案是 640*480 场景里最平衡的，压缩率够、CPU 不高、代码量少。H.264 文件小，但低码率下画面细节丢失多，而且编码器初始化、PTS 管理都要自己处理，对本需求来说属于“杀鸡用牛刀”。我的选择：默认使用 MJPG 编码，需要无损调试时切换原始帧直存。

4.3 用 OpenCV VideoWriter 保存：QImage 到 cv::Mat 的桥

选 MJPG 的情况下，常见做法是用开源视觉库的VideoWriter封装，省掉自己写 AVI 容器的时间。关键是把 QImage 转成cv::Mat——注意 QImage 的内存行字节数可能是对齐的，不能直接memcpy。我写一个转换函数：

cv::Mat qimage_to_mat(const QImage& img) { // QImage::Format_RGB32 在内存里是 0xAARRGGBB，OpenCV 默认 BGR 顺序不对 QImage converted = img.convertToFormat(QImage::Format_RGB888); // convertToFormat 保证数据连续，这里可以直接包 Mat return cv::Mat(converted.height(), converted.width(), CV_8UC3, const_cast<uchar*>(converted.bits()), converted.bytesPerLine()).clone(); }

录像写入的主循环里，每帧采集信号到达时按需写入，而不是在采集线程里同步阻塞写磁盘：

void MainWindow::startRecording() { m_writer.open("record.avi", cv::VideoWriter::fourcc('M','J','P','G'), 25, cv::Size(640, 480)); if (!m_writer.isOpened()) { QMessageBox::warning(this, "录像", "打开 VideoWriter 失败，检查编码器支持"); } } void MainWindow::onFrameReady(const QImage& img) { // ...显示逻辑... if (m_writer.isOpened()) { m_writer.write(qimage_to_mat(img)); } }

参数说明：fourcc('M','J','P','G')在 Linux 下依赖本地安装的 MJPG 编码器，一些精简版系统没有，isOpened()会返回 false；帧率 25fps 要和实际采集帧率一致，如果摄像头是 30fps 而你写 25fps，播放速度会比真实时间快 20%。clone()是必需的，因为converted一旦离开函数作用域内存就释放了，直接返回 Mat 是悬垂指针，我第一次写这里没 clone，录像后半段全是绿条，排查了一晚上。

4.4 截图与录像并发：互斥锁保护帧数据

截图和录像同时进行时，两个模块都要读m_currentFrame。我在主线程的事件循环里，槽函数是串行执行的，不真正并发；但如果你把录像写入挪到录像线程，就得加锁。稳妥做法是用一个QMutex保护所有对当前帧的读写：

void MainWindow::onFrameReady(const QImage& img) { QMutexLocker locker(&m_frameMutex); m_currentFrame = img; } void MainWindow::onSnapshotBtn() { QMutexLocker locker(&m_frameMutex); QImage snap = m_currentFrame; locker.unlock(); // save 不需要锁，文件 IO 不涉及共享数据 snap.save(...); }

QMutexLocker是 RAII 风格，构造函数加锁，析构自动解锁。unlock()调用后手动释放锁是给 save 让路，避免持锁做磁盘操作，拖慢信号槽队列。这个并发场景在纯单线程下看不出来，但我习惯先把锁加上，因为后期一旦有人为了性能把录像挪到独立线程，这个锁就是后悔药。

5. v4l2 + Qt 避坑排查：五个高频翻车点与处理记录

5.1 画面绿屏或严重花屏

现象：预览窗口出现满屏绿色，或者画面像被撕裂一样，横向条纹错位。原因：像素格式对不上。摄像头实际输出 MJPEG，你按 YUYV 解析，数据完全不是同一套编码；另一个常见原因是 YUYV 和 UYVY 的字节序搞混了，两者只差 U/V 分量位置，转换公式却完全不同。解决：先跑v4l2-ctl --list-formats-ext确认默认格式；在代码里VIDIOC_G_FMT读回实际 pixelformat，打印出来对比。如果设备只支持 MJPG，就先用libjpeg解压，不要硬解。字节序问题就是调换取 u、v 的下标偏移。

5.2 打开 /dev/video0 失败：设备占用与权限

现象：open("/dev/video0", O_RDWR)返回 -1，perror 显示Permission denied或Device or resource busy。原因：当前用户不在 video 组，或者另一个进程已占用摄像头——调试时最容易踩的是之前程序异常退出了，没有 STREAMOFF，驱动认为设备还在采集。解决：权限问题执行usermod -aG video $USER后重新登录；占用问题用fuser -v /dev/video0查是哪个进程占用的，kill掉它；程序里要注册信号处理函数，收到 SIGINT/SIGTERM 时先 STREAMOFF 再退出，防止下次打开卡死。

5.3 预览卡顿，帧率明显低于摄像头标称值

现象：30fps 的摄像头，界面看着只有 15fps 左右，鼠标拖动窗口时掉帧更严重。原因：采集循环和 UI 刷新互相抢占主线程；信号槽里频繁做 QImage 深拷贝；scaled平滑缩放每次都触发完整重采样。解决：采集线程保持独立；信号槽参数不用QImage改用std::shared_ptr<QImage>（Qt 队列连接会复制智能指针，不会复制像素数据），或者主线程槽里只接收后做一次浅拷贝；scaled结果缓存，只有控件尺寸变化时才重新缩放。另外检查是否开了垂直同步，Qt 在 Linux 下默认走 OpenGL 渲染，垂直同步会卡刷新率。

5.4 录像文件播放时后半段花屏或时长不对

现象：AVI 文件用播放器打开，前几秒正常，后面画面变成马赛克块；或者总时长比实际录的时间少。原因：MJPG 编码的关键帧间隔和写入频率不一致；OpenCV 的VideoWriter内部缓冲没刷盘，程序异常退出时文件尾部数据丢失；QImage 转换cv::Mat时没有clone()，导致写入的像素地址在帧消失后变成随机值，这是最常见的“黑匣子”式损坏。解决：录像停止时先调用m_writer.release()确保编码器 flush；转换 Mat 时必须clone()；关键帧间隔在VideoWriter::set(cv::VIDEOWRITER_PROP_QUALITY, 90)之外，还可以用cv::imencode单独控制质量，避免默认压缩过狠。

5.5 程序退出崩溃：QThread 析构与 mmap 未释放

现象：点击关闭窗口后程序卡住，或者直接 segmentation fault；终端里打印QThread: Destroyed while thread is still running。原因：CaptureThread的run()里 while 循环还在 DQBUF 阻塞等待，主线程关闭窗口直接把线程对象析构了；而 fd 和 mmap 区域在退出前没有 munmap 和 close，内核在进程退出时强制回收，导致缓冲队列状态混乱。解决：主窗口closeEvent里先调captureThread->stop()，设置原子标志位让DQBUF超时退出；随后captureThread->wait(500)，等线程真正停止；最后才释放 mmap 区域和 fd。注意DQBUF在阻塞模式下不会立刻返回，需先STREAMOFF，它才会被信号打断。

6. 进阶调试技巧：用丢帧计数和 PTS 校准帧率，给方案兜底

6.1 加一个轻量 FPS 计数器，验证采集到显示的真实帧率

光看画面“感觉流畅”不算数，我做了一个简单的统计模块：采集线程每次 DQBUF 成功就计数，主线程每秒刷新标签显示实时帧率。核心逻辑就是一个滑动窗口：

class FpsCounter { public: void tick() { qint64 now = QDateTime::currentMSecsSinceEpoch(); m_count++; if (now - m_lastShowMs >= 1000) { double fps = m_count * 1000.0 / (now - m_lastShowMs); qDebug() << "capture fps:" << fps << "dropped:" << m_dropped; m_count = 0; m_lastShowMs = now; } } private: qint64 m_lastShowMs = 0; int m_count = 0; int m_dropped = 0; };

把这个计数器放在 DQBUF 之后的process_frame入口，画面卡不卡、实际采集帧率多少，一眼就能看出来。我自己的使用习惯是：接入新摄像头时先跑 2 分钟，如果计数帧率比标称低 10% 以上，优先排查是不是process_frame耗时超了帧间隔，或者 USB 带宽被其他设备挤占。这个习惯帮我提前发现了两个标称 60fps 实际只能跑到 42fps 的摄像头，避免录像时间轴偏快。

6.2 用 v4l2_buffer 的 timestamp 做帧间隔统计

比 FPS 计数器更准的是看相邻两帧的时间差。struct v4l2_buffer里的timestamp字段是内核打的时间戳，单位随V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC标志，精度是微秒。我在采集循环里记录上一帧的buf.timestamp.tv_usec，相减后就能看到每帧间隔是否均匀。如果某段时间间隔忽大忽小，说明 USB 传输不稳，录像文件里对应的位置就会掉帧。这个数据比 FPS 平均值更直观：平均值掩盖了掉帧的瞬间，而逐帧间隔会把偶发卡顿暴露出来。

6.3 断流重连：摄像头掉线后的自恢复

生产环境里摄像头偶尔会断流，比如 USB 线虚接、驱动复位。我在process_frame里加了一个超时判断：如果DQBUF连续 2 秒返回 EAGAIN，就主动走一遍完整的停止流程——STREAMOFF、munmap、close，然后sleep(1)重新 open、REQBUFS、STREAMON。注意重新打开时格式参数要重新设置一遍，摄像头驱动复位后很多参数会回到默认值，我之前漏了这步，重连成功后画面颜色全偏。这个自恢复逻辑放在一个独立的管理线程里，不阻塞 UI 刷新。

调试链路走到这里，回头总结一条规律：v4l2 采集层的问题九成能通过v4l2-ctl命令先定位，Qt 显示层的问题九成出在跨线程刷新和内存生命周期上，而截图录像的坑集中在编码器和容器格式的选择上。每次接新摄像头，我都会先用这套组合验证一遍再开始写业务逻辑，目前为止翻车的概率很低。如果你正卡在某个环节，建议先按上述顺序逐个排查——尤其先跑v4l2-ctl --list-formats-ext再动手写代码，这条能帮你省下大半排查时间。希望帮到你。

本文还有配套的精品资源，点击获取