简介：基于DirectShow与Qt5的Windows摄像头拍照录像软件源码，是一套面向C++开发者和多媒体爱好者的完整工程示例。项目把微软DirectShow流媒体处理能力与Qt5图形界面结合起来，解决Windows环境下摄像头实时预览、图像抓拍和视频录制的常见需求，可直接作为二次开发基础或多媒体课程设计参考。压缩包共415个文件、约11MB，含155个头文件、140个C源文件和8个C++源文件，并配有多类工程配置文件、文档、图标及辅助脚本；源码包含视频捕捉、AVI写入、摄像头窗口、日志记录、图像格式处理等模块，目录划分清晰，便于按功能定位代码。目前已有402人学习下载。对想了解DirectShow过滤器图结构、Qt5界面与视频采集联动的学习者，这套代码提供了完整的落地范例；开发者可以替换设备抽象层、扩展编码或存储格式，快速构建自定义拍照录像工具。

1. 为什么这份 DirectShow + Qt5 摄像头源码值得先下载：先看清它能解决什么

如果你要在 Windows 上把一个普通 UVC 摄像头变成“能实时预览、能拍照、能录像”的桌面软件，手头又不想从 Media Foundation 的接口堆里慢慢啃，这份基于 DirectShow 和 Qt5 的 C++ 源码包就是一个很合适的底稿。它不是一个写了半个界面就停下的 Demo，而是把设备枚举、预览窗口、图片保存、AVI 录像、日志记录和插件入口串成了一个完整可跑的软件框架，适合两类人：一类是刚开始做 Windows 视频采集、需要对照完整调用链的新手；另一类是团队里突然要“一周内给上位机加摄像头功能”的开发者，直接在这个工程上改界面、改保存路径，比从空工程搭稳得多。

我拿到源码后没有急着看某个文件，而是先做了两件事：把文件清单按“代码、配置、资源、夹带”分类，再用最小工程把预览跑通。这两步做完，后面拍照和录像的坑基本都能预料到。这篇笔记就按这个顺序讲，先给你能吃透源码骨架的方法，再拆拍照、录像两条链路，最后把混编时最常踩的问题列清楚。目标很直接：下载后你能改、能跑、能排错，而不是看一遍就关掉。

2. 先识别工程骨架：把 412 个文件拆成核心、配置与夹带三部分

源码包里有 412 个文件，听着不少，但真正决定软件能不能跑的核心文件不超过十个。我在第一次打开这类工程时，最怕的不是代码看不懂，而是构建系统把不该编译的文件也拽了进来，导致一编译就是几十个链接错误。所以先别急着看代码，先把工程骨架摸清。

2.1 按职责拆文件：界面、采集、录像、日志、插件各归各位

先看文件名就能把职责分出来，这是最快也最准确的路径。下面是我常用的“文件职责表”，你也可以把它当二次开发的修改索引：

拿到源码后，我一般会先在根目录跑一个 find 命令，不靠眼睛清点文件。这样做的好处是，编译器看到的文件集合和人在资源管理器里看到的文件集合经常不一致，跑一次命令就能提前发现多余文件。

# 统计源码包里 c/cpp/h 文件数量，并验证核心文件是否都在 find . -type f \( -name "*.c" -o -name "*.cpp" -o -name "*.h" \) | sort # 单独检查任务关键文件 ls -la AVILib.cpp VideoCapture.cpp WebcamWindow.cpp \ Logger.cpp ImageFormats.cpp VideoDevice.cpp main.cpp \ uvcapture_plugin_import.cpp

这段命令的逻辑是：第一句列出所有会被编译器识别的源文件，方便你判断工程目录是否干净；第二句则是确认骨架文件没有缺失。参数上我故意没有加-maxdepth，因为有些工程的源码会放在两层或三层子目录里，限制深度反而会漏掉文件。如果第二句里有文件缺失，先别急着补写，去文本文件或 HTML 说明里找对应说明，很多缺失只是文件名大小写不同。

2.2 EWD、EWP、RAPP 与杂项文件：先备份，再决定要不要进构建

这类工程里经常混着 IDE 工作区文件、调试启动脚本、博客模板和硬件工程片段，最容易让人误判的是 EWD 和 EWP。常见做法是，EWP 指向工程的文件列表和编译选项，EWD 保存调试器工作区状态，RAPP 常常是资源打包或应用生成的描述文件。这些文件本身不是运行时代码，但它们决定了原作者的编译环境参数，比如头文件包含路径、链接库列表、输出目录。

我的建议是先原样备份，再手动建一个干净工程。不要直接去改 EWP，因为你不知道原作者用的编译器版本和扩展项是什么，改一处就可能导致整个工程无法加载。更稳妥的做法是新建一个 Qt 工程文件，把核心源文件按 2.1 的表拖进去，再从 EWP 里抄需要的包含路径。

这里要特别提醒一点：源码包里如果出现stm8s_tim1.c、stm8s_tim5.c、stm8s_tim2.c、stm8s_can.c、cap.Debug.cspy.bat这类文件，不要认为它们是摄像头软件的一部分。这类带外设寄存器名字的文件明显属于嵌入式 MCU 工程，很可能是打包时夹带进来的碎片。它们一旦被 IDE 自动加入编译，最常见的症状是 LNK2005 重复定义，或者一堆不认识的宏未定义。拿到包后先把它们隔离出来。

# 把 MCU 相关夹带文件移到 _exclude 目录，避免被 IDE 扫描 mkdir -p _exclude mv stm8s_tim1.c stm8s_tim2.c stm8s_tim5.c stm8s_can.c _exclude/

这段操作很简单，但能少踩一半构建坑。mkdir -p会保证目录存在，mv把不相关文件挪出源码搜索路径。注意，stm8s_tim1.c这类文件如果原来就出现在工程文件里，移动之后要在工程文件里同步删掉对应条目，否则编译器仍会按绝对路径去找它。

2.3 建议的最小编译顺序：先跑通预览，再谈拍照和录像

我拿到工程后不会直接打开就编译整个项目，而是按“最小可运行”的原则推进。第一步只编译main.cpp + WebcamWindow + VideoDevice + VideoCapture，先把摄像头预览跑出来；第二步再加ImageFormats做拍照，不保存到文件，先在界面上显示图片信息；第三步再引入AVILib做录像。这样每一步的报错范围都很小，排查起来快得多。

如果源码包里没有现成的 Qt 工程文件，我会按下面这个最小.pro配置来建：

QT += core gui widgets CONFIG += c++11 # DirectShow 和 Windows 多媒体相关库 LIBS += -lstrmiids -luuid -lole32 -lvfw32 SOURCES += main.cpp \ WebcamWindow.cpp \ VideoDevice.cpp \ VideoCapture.cpp HEADERS += WebcamWindow.h \ VideoDevice.h \ VideoCapture.h

这里有个容易忽视的点：strmiids是 DirectShow 的 GUID 定义库，不链接它就会在CLSID_FilterGraph这类符号上报无法解析；ole32负责 COM 初始化相关调用；vfw32是 AVI 写文件时需要的库。很多新手只加了strmiids，结果一调用AVIFileOpen就链接失败，其实缺的是vfw32。我一般会用这个最小工程先跑通设备枚举，再逐步把其他源文件加回来。

3. 拍照链路拆解：设备枚举、Filter Graph 与 QImage 转换

拍照看起来只是“抓一帧存成图片”，但 DirectShow 里这帧数据要经过设备枚举、Filter Graph 建立、采样回调、格式转换四步才能到 Qt。这里最容易翻车的不是算法，而是 COM 初始化和色彩格式。

3.1 枚举设备：别把第一个 Filter 当成唯一选项

摄像头可能不止一个，甚至同一个 USB 接口插上不同设备后，设备顺序也会变。所以工程里设备枚举不能用固定索引，必须用 DirectShow 的系统设备枚举器遍历视频输入目录，再向用户展示设备名。这一步对应源码里的VideoDevice.cpp，核心逻辑可以简化成这样：

#include <dshow.h> #include <setupapi.h> void EnumCameraDevices() { CoInitialize(nullptr); // DirectShow 调用前必须初始化 COM ICreateDevEnum* devEnum = nullptr; IEnumMoniker* enumMon = nullptr; HRESULT hr = CoCreateInstance(CLSID_SystemDeviceEnum, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&devEnum)); if (FAILED(hr)) return; hr = devEnum->CreateClassEnumerator(CLSID_VideoInputDeviceCategory, &enumMon, 0); if (hr == S_FALSE) { // S_FALSE 表示没有视频输入设备，不要再调用 Next return; } IMoniker* moniker = nullptr; while (enumMon->Next(1, &moniker, nullptr) == S_OK) { IPropertyBag* bag = nullptr; moniker->BindToStorage(nullptr, nullptr, IID_PPV_ARGS(&bag)); VARIANT name; VariantInit(&name); if (SUCCEEDED(bag->Read(L"FriendlyName", &name, nullptr))) { // name.bstrVal 就是设备显示名 } VariantClear(&name); bag->Release(); moniker->Release(); } }

这段代码有几个参数值得注意：CLSID_SystemDeviceEnum是 DirectShow 为系统枚举器预置的类 ID，CLSID_VideoInputDeviceCategory表示只看视频输入设备目录。CreateClassEnumerator返回值是S_FALSE时，代表机器上根本没有摄像头，这时的正确做法是直接返回，而不是继续调用Next。FriendlyName是设备属性里的用户友好名，同一颗摄像头在不同 USB 端口可能显示不同名称，所以 UI 显示和底层 Filter 要分开保存，不能拿字符串做匹配。

3.2 建立采集链路：把 Sample Grabber 插在摄像头和预览中间

设备枚举拿到IMoniker后，下一步是让 DirectShow 把这个设备对应的 Filter 实例化，并连出一条“摄像头 → Sample Grabber → Null Renderer”的链路。Sample Grabber 是中间截帧的关卡，Null Renderer 负责把不想要的视频输出丢弃掉，这样预览数据既能走进我们的回调，又不会被重复绘制。

IGraphBuilder* graph = nullptr; ICaptureGraphBuilder2* capBuilder = nullptr; CoCreateInstance(CLSID_FilterGraph, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&graph)); CoCreateInstance(CLSID_CaptureGraphBuilder2, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&capBuilder)); capBuilder->SetFiltergraph(graph); IBaseFilter* srcFilter = nullptr; // 这里用枚举阶段得到的 moniker 创建真实的采集 Filter moniker->BindToObject(nullptr, nullptr, IID_PPV_ARGS(&srcFilter)); // 自动把 srcFilter 的输出连接到 Sample Grabber 再到 Null Renderer capBuilder->RenderStream(&PIN_CATEGORY_PREVIEW, &MEDIATYPE_Video, srcFilter, grabberFilter, nullptr);

RenderStream是这段代码里最省事的 API，它会自动寻找合适的引脚并完成连接。第一个参数PIN_CATEGORY_PREVIEW表示连接的是预览引脚而不是捕获引脚，这样做的原因是很多摄像头驱动会在高帧率录制时限制预览帧率，预览链路独立出来会更稳定。第二个参数MEDIATYPE_Video指定只连视频流，不会把无关的音频流拉进来。

3.3 在 BufferCB 回调里把原始帧转成 QImage，而不是直接操作界面

到了这一步，Source Filter 会不断把摄像头数据送到 Sample Grabber，Sample Grabber 再通过BufferCB回调把帧交给我们。这里最重要的一条纪律是：回调线程不是 UI 线程，你绝对不能在回调里直接更新QLabel或弹窗。正确做法是把帧数据跨线程发到 Qt 主线程，再由主线程做转换和显示。

class FrameGrabberCB : public ISampleGrabberCB { public: STDMETHODIMP_(ULONG) AddRef() override { return 1; } STDMETHODIMP_(ULONG) Release() override { return 1; } STDMETHODIMP QueryInterface(REFIID iid, void** ppv) override { return E_NOTIMPL; } STDMETHODIMP BufferCB(double sampleTime, BYTE* buffer, LONG length) override { if (!buffer || length <= 0) return E_FAIL; QByteArray frameData(reinterpret_cast<const char*>(buffer), length); QMetaObject::invokeMethod(m_receiver, "onRawFrame", Qt::QueuedConnection, Q_ARG(QByteArray, frameData)); return S_OK; } };

这段代码的关键点是Qt::QueuedConnection。它保证onRawFrame一定在 Qt 主线程执行，不会和点击按钮、刷新窗口产生线程竞争。QByteArray在这里是帧数据的传输载体，拷贝一整帧确实有内存开销，但 720p 场景下可以接受。如果你要跑 4K，就要改成共享缓冲或帧池，否则拷贝损耗会明显提高。帧数据的宽、高、格式不能靠猜，最好在连接 Sample Grabber 之前，通过AM_MEDIA_TYPE把媒体类型设置成 RGB24，这样回调里拿到的就是最接近 QImage 的格式。

AM_MEDIA_TYPE mt = {}; mt.majortype = MEDIATYPE_Video; mt.subtype = MEDIASUBTYPE_RGB24; mt.formattype = FORMAT_VideoInfo; // 在连接图之前设置 Sample Grabber 想要的媒体类型 grabber->SetMediaType(&mt);

这里要特别留意“RGB24”和“BGR24”的差别。很多 UVC 摄像头驱动实际输出的是 BGR 顺序，而 QImage 的Format_RGB888按 RGB 顺序解释，直接转换会看到画面偏色。源码里ImageFormats.cpp存在的意义之一就是处理这个问题，常见做法是在保存前做一次rgbSwapped()。

// 在 onRawFrame 中构造 QImage QImage rawImg(reinterpret_cast<const uchar*>(frameData.constData()), width, height, QImage::Format_RGB888); // 如果发现红色和蓝色交换，就执行一次像素通道交换 QImage normalImg = rawImg.rgbSwapped(); normalImg.save("capture_" + QDateTime::currentDateTime().toString("yyyyMMdd_hhmmss") + ".jpg", "JPG", 92);

rgbSwapped()会把第一个通道和第三个通道互换，正好解决 BGR 转 RGB 的问题。save的第三个参数是 JPEG 质量，默认值 90 到 95 之间比较合理，太高会让文件体积暴涨，太低会在文字类画面上出现明显锯齿。拍照保存不要放在回调里，应该放在onRawFrame里用队列控制，或者干脆只在用户点击快门时取最新一帧，避免同步 I/O 卡住采集线程。

4. 录像链路落地：AVIFile 封装参数与常见编码选择

拍照只需要截一帧，录像则需要连续把帧写进容器文件。工程里AVILib.cpp承担的就是这部分工作。它围着 Windows 的vfw.h接口做封装，核心是要把帧率、编码格式、关键帧节奏和文件缓冲都控制好。

4.1 用 AVIStreamWrite 而不是 AVISave：把写盘节奏握在自己手里

很多初学者一上来就用AVISave，因为它参数少、调用一次就能生成文件。但它会把整个录像过程当成一次批量保存操作，内存消耗大，也不方便在录制中途停止或插入时间戳。源码里的常用做法是先把 AVI 文件打开，建立视频流，然后每采集到一帧就写一次，这样停止按钮一按就能立刻收尾。

#include <vfw.h> void StartAviRecording(const QString& filePath, int width, int height, int fps) { AVIFileInit(); AVIFile* aviFile = nullptr; HRESULT hr = AVIFileOpen(&aviFile, reinterpret_cast<LPCWSTR>(filePath.utf16()), OF_CREATE | OF_WRITE, nullptr); if (FAILED(hr)) return; AVISTREAMINFO info = {}; info.fccType = streamtypeVIDEO; info.fccHandler = mmioFOURCC('M', 'J', 'P', 'G'); // 用 MJPG 而不是裸 RGB info.dwScale = 1; info.dwRate = fps; info.dwSuggestedBufferSize = width * height * 3; AVISTREAM* stream = nullptr; AVIFileCreateStream(aviFile, &stream, &info); if (!stream) return; BITMAPINFOHEADER bi = {}; bi.biSize = sizeof(BITMAPINFOHEADER); bi.biWidth = width; bi.biHeight = height; bi.biPlanes = 1; bi.biBitCount = 24; bi.biCompression = BI_RGB; AVIStreamSetFormat(stream, 0, &bi, sizeof(bi)); // 之后每拿到一帧： // AVIStreamWrite(stream, frameIndex++, 1, frameData, frameSize, // AVIIF_KEYFRAME, nullptr, nullptr); }

这段代码里fccType = streamtypeVIDEO表示这是视频流，fccHandler指定编码器代号。mmioFOURCC('M','J','P','G')是 MJPEG 的 FOURCC 值，选它而不是裸 RGB 是因为 MJPEG 在绝大多数 Windows 播放器里兼容性都很稳，文件大小也只有裸 RGB 的三分之一左右。dwScale和dwRate合起来决定帧率：dwRate / dwScale = 30，所以如果dwRate = 30，dwScale必须为 1。AVIStreamSetFormat告诉封装层每一帧的数据头是什么格式，这里用了BI_RGB，配合 MJPEG 编码器，底层会自动编码。

4.2 帧率、缓冲与关键帧：录像参数不能照抄拍照

录像链路的参数和拍照完全不同。拍照对单帧质量敏感，录像对连续性和同步性敏感。我一般会先列一张参数表，把容易写错的地方标出来：

录像时的真实坑在内存增长。如果你在回调里每帧都new一块数据，丢给写盘线程后不释放，录制十分钟内存就到了几个 GB。源码里AVILib.cpp的理想封装应该是循环复用缓冲槽，写盘线程消费完一块后才归还给采集线程。

4.3 录像文件打不开：先检查 FOURCC 和 AVIStreamSetFormat

录出来的 AVI 文件在播放器里打不开，是录像功能最常见的失败点。第一步检查fccHandler，如果你用了 0 或者BI_RGB，很多播放器会把它当成未压缩视频流，却因为缺少AVIStreamSetFormat的格式头而直接拒绝播放。第二步检查AVIStreamWrite每帧写入的字节数，不能超过dwSuggestedBufferSize。第三步检查结束前是否正确调用AVIStreamRelease和AVIFileRelease，文件尾没写完整，播放器就会判断文件损坏。

我在调试这种问题时，通常会在AVIStreamWrite调用的下一行加一个帧计数日志，每 30 帧打一行，确认写盘线程没有在排队。如果帧计数正常但文件还是打不开，就重点查AVIStreamSetFormat是否真的被调用了，很多封装库把这个调用放在接口里，却因为没检查返回值而静默失败。

5. 避坑：DirectShow + Qt5 混编常见的 6 个问题

DirectShow 和 Qt5 混编的坑，多数不是单一技术难，而是两种线程模型和两种内存管理混在一起。下面这六条是我在实际调整里反复见过的，按“现象 → 原因 → 解决”写清楚。

5.1 回调线程里直接更新 QLabel，程序启动预览就闪退

现象：点击开始预览后，窗口能弹出来，但第一个画面出现时崩溃，崩溃地址不稳定，每次都在 Qt 的绘制模块里。原因：Sample Grabber 的BufferCB运行在 DirectShow 的采集线程，不是 Qt 主线程，直接调用QLabel::setPixmap触发了跨线程绘制。解决：回调里只做数据传递，用QMetaObject::invokeMethod(..., Qt::QueuedConnection)把帧数据转给主线程；同时在窗口关闭时，先把回调的接收对象置空，再释放 Filter Graph。

void WebcamWindow::closeEvent(QCloseEvent* e) { // 先停采集，再释放 DirectShow 对象，顺序不能反 m_capture->Stop(); m_capture->ReleaseGraph(); QWidget::closeEvent(e); }

这里Stop和ReleaseGraph的顺序很重要。如果先释放 Graph，采集线程可能还在回调里访问已经释放的 Filter，导致访问已释放内存。先让IMediaControl::Stop()返回，再释放对象，才能保证没有线程继续往里跑。

5.2 画面颜色偏红偏蓝，拍出来的照片被误判为摄像头坏了

现象：预览正常，但拍出来的 JPEG 红色和蓝色对调，绿色部分基本不变，人脸像一坨紫。原因：摄像头输出的是 BGR24，而 QImage 默认用 RGB888 解释。解决：在构造 QImage 之后，对Format_RGB888的图像执行rgbSwapped()；更彻底的做法是在 Sample Grabber 里直接设置MEDIASUBTYPE_RGB24之前，通过IAMStreamConfig::GetStreamCaps查询驱动支持的格式，避免驱动自动转换成你不熟悉的 YUY2 格式。

5.3 切换分辨率后画面黑屏，重新启动软件才恢复

现象：预览窗口只显示黑色，但设备枚举仍能认出摄像头，日志里也没有报错。原因：Filter Graph 在运行状态时切换分辨率，Source Filter 的视频头没有重新协商，许多 UVC 驱动会直接停止输出。解决：切换分辨率前先停止 Graph，再通过IAMStreamConfig::SetFormat设置新的VIDEOINFOHEADER，最后重新运行 Graph。不要试图在运行中修改媒体类型，Windows 的老接口对动态格式切换支持非常差。

5.4 工程里混入 stm8s_tim*.c，编译时出现 LNK2005 重复定义

现象：编译到链接阶段报错，提示_tim1_...这类符号重复定义，或者大量无法解析的寄存器地址宏。原因：源码包夹带了单片机工程文件，stm8s_tim1.c和stm8s_tim5.c里的全局符号被一并编入 Windows 桌面程序。解决：把这类文件移到_exclude目录，并在工程文件里删除对应条目。如果再出现重复定义，用grep -n "stm8s_tim" *.ewp找到残余引用，一并清理。

grep -rn "stm8s_tim" --include="*.ewp" --include="*.vcxproj" --include="*.pro" .

这条命令会把所有工程配置里引用 MCU 文件的地方都查出来，避免手动删除后又被某个配置文件带回来。对这些命令行参数，我的建议是养成先全局搜一次再编译的习惯。

5.5 录出来的 AVI 只能看前几秒，拖动进度条就花屏

现象：录像文件很小，用播放器从头放没问题，但拖动进度条后画面变成彩色噪点，时间轴也不准。原因：没有在每个关键帧位置写AVIIF_KEYFRAME，播放器在随机访问时找不到可解码参考帧。解决：在AVIStreamWrite调用里，把dwFlags参数设为AVIIF_KEYFRAME。如果摄像头帧率本来就只有 15 帧，可以考虑每帧都当关键帧写，虽然文件稍大，但兼容性最好。

5.6 高 DPI 屏幕上预览窗口只占屏幕四分之一

现象：4K 屏上软件界面被 Windows 放大，但摄像头预览画面只有左上角一小块。原因：Qt5 默认启用高 DPI 缩放，而 DirectShow 侧返回的视频尺寸仍是物理像素，两者没有对齐。解决：在main.cpp的程序入口调用SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)，并让QLabel的固定尺寸跟随逻辑分辨率，不要用物理像素直接设置控件大小。这样预览画面会正常缩放，但文字又不会糊掉。

6. 进阶：把 DirectShow 回调接进 Qt 事件循环，并照着三个指标验收

写到最后一步，我想讲一个我后来一直坚持的做法：不要让 DirectShow 回调直接依赖某个具体 QWidget，而是在中间加一层采集工作线程，用 Qt 的信号槽把“设备枚举、开始采集、帧到达、采集停止”四个事件全部串起来。这样做的好处是，窗口可以随时重建，录像模块可以独立启动，回调代码也更容易单元验证。

这里的核心是把QThread当作一个可复用的运行容器，而不是在WebcamWindow里写线程逻辑。通常我会定义一个CaptureWorker对象，让它继承QObject，在start()槽里初始化 DirectShow，并在主线程发送previewReady信号。

class CaptureWorker : public QObject { Q_OBJECT public slots: void start() { CoInitializeEx(nullptr, COINIT_MULTITHREADED); m_running = true; // 建立 Filter Graph 后进入采集循环 while (m_running) { // 从 Sample Grabber 的输出队列取最新一帧 QImage frame = takeLatestFrame(); if (!frame.isNull()) { emit frameReady(frame); } // 让出 CPU，避免空转 QThread::msleep(5); } } void stop() { m_running = false; } signals: void frameReady(const QImage& frame); };

这段代码最关键的一点是采集循环并不直接处理 DirectShow 回调里的原始 buffer，而是由工作线程统一从帧队列取出数据并转换成QImage。frameReady信号连接到WebcamWindow的预览槽函数后，Qt 会自动按AutoConnection决定跨线程投递，主线程不会产生界面竞争的焦虑。

最后，我每次改完这种工程，都会强制走一遍三个验收指标。第一个是预览延迟：站在摄像头前挥手，到窗口看到动作，时间要小于 200 毫秒，达不到就检查回调里是否做了不必要的编码转换。第二个是长时间录像稳定性：连续录制 30 分钟，内存占用曲线应该是平的，如果稳步上涨，优先查帧缓冲是否泄露。第三个是文件兼容性：录出来的 AVI 必须能被常见播放器直接拖入播放，不能只在自己电脑上能看，换个播放器就花屏。这三项都过了，源码才算真正落地到可用状态。

从那以后，我每次拿到新的摄像头源码包，都强制先做三件事：跑一遍文件分类命令、把回调里的 UI 调用删干净、用最小工程跑通预览后再碰录像。这三个动作加起来不到十分钟，但能避开后面几个小时的黑匣子排错。希望这份 DirectShow + Qt5 源码包的拆解过程能帮到你，下载后照着前四章改，多数设备都能直接跑起来。

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