简介面向 DirectShow 视频采集开发者的实用示例包内含一个简单捕获程序及多种视频格式转换函数。资源封装了 RGB24 与 YV12、YVU9、YUY2 等色彩空间之间的互转逻辑可直接集成到视频处理工程中也适合初学者理解采集流程与数据转换原理。压缩包共 20 个文件含 6 个头文件、4 个 C 源文件、1 个静态库 cscc.lib以及解决方案、资源脚本等工程文件整体大小仅 55KB结构小巧便于查阅使用。目前已有 246 人学习下载对需要实现帧格式转换或构建采集模块的开发者具有较高的参考价值。尤其值得注意的是代码提供 YV12、YUY2 等常见格式的双向转换既能减少重复开发工作量又能直接嵌入到实际项目中如将采集帧转为 YV12 供后续编码或反向转换用于预览显示非常适合需要快速落地使用的开发者。1. Dshow Capture 这个标题背后是 Windows 视频采集的默认基础设施「Dshow Capture」在 Windows 视频采集的语境里指的是以 DirectShow 为底层框架做摄像头、采集卡或虚拟视频源的数据获取。很多做机器视觉、多路推流、远程会议的中小型项目最开始没有意识到自己选的是这一套方案直到某天摄像头画面黑屏、分辨率设置不生效、CPU 被连续转码占满才回头去查采集链路。这里能解决的是「在 Windows 上把一路或多路视频流稳定、低延迟地取出来」这件事适合做设备端视觉、直播推流、录屏软件以及嵌入式采集系统的同学看。它不新但大量能买到能接上的采集设备底层仍然是 Dshow 在兜底。Dshow Capture 的价值不是性能最好而是兼容面最广。USB 摄像头、HDMI 采集卡、虚拟摄像头、甚至视频文件模拟源都能用同一条采集管线适配这让它成为新项目起步时绕不开的底层方案。2. 为什么到现在还在用 DirectShow 做 Capture底层结构决定了取舍2.1 滤镜图模型把「采集、变换、输出」拆成三段链路DirectShow 的核心思想是滤镜图(filter graph)。一个视频源被抽象成一个源滤镜经过若干变换滤镜最后交到渲染端或被取帧回调截获。这条链路上每个节点之间通过 pin 连接连接时双方要协商媒体类型包括编码格式、分辨率、帧率、像素格式。做采集时最常见的链路是设备源滤镜 → Sample Grabber(取样器) → 空渲染器。Sample Grabber 负责把经过它的每一帧样本交给应用层回调空渲染器则只是让链路有个合法终点不参与显示。应用层拿到的是流经这段链路的原始帧数据后续是转成图像处理格式、编码给推流模块还是直接存盘都由自己决定。这个模型的好处是边界清晰设备驱动只要把自己的输出暴露成一个标准源滤镜上层代码就不需要关心具体硬件协议。坏处也同理——一旦驱动实现的滤镜不标准或者 pin 之间协商不出双方都接受的媒体类型问题会一路传导到应用层典型表现就是打不开设备或者永远取不到帧。2.2 为什么不是 Media Foundation兼容性才是 Dshow 的护城河Windows 上还有一套更新的多媒体框架 Media Foundation。很多新项目会直接考虑它但实际操作中大量摄像头和采集卡的驱动提供方只发布了 DirectShow 滤镜并没有同步做 MF 兼容层。也就是说软件卖得再多摄像头插上系统只能被 DirectShow 枚举到MF 那套接口拿不到设备列表。我一般会这样判断如果是自己写内部工具设备和驱动版本完全可控那 MF 可以尝试如果是一个要交给别人部署在现场、设备型号不可控的项目用 Dshow Capture 更稳。很多所谓「万能采集 SDK」内部做的事本质还是把 Dshow 封装一层对外提供更简单的接口。明白这一点排错时思路会清楚很多——你以为自己在调某个 SDK其实所有问题最终都要回到 Dshow 这一层来看。2.3 采样器取帧与回调模式Dshow 里最关键的性能决策取帧方式直接关系到 CPU 占用。Dshow 提供了两种常见的数据获取路径一种是采样器回调模式每来一帧驱动 ISampleGrabberCB 接口把帧数据指针交给应用另一种是拉模式即应用主动调用方法去取最近一帧。两种模式我都实际用过结论很明确采集端尽量用回调模式。拉模式看着简单但它把节拍控制权交给了应用层一旦应用侧某次处理超时视频缓冲会越积越多画面延迟会持续变大最后被迫清空缓冲表现就是画面卡顿后突然跳帧。回调模式的问题在于回调函数运行在流线程上若在里面做耗时操作会直接阻塞整条采集链路。正确做法是回调里只做拷贝和标记业务逻辑放到独立线程去消费。3. 用最小 C 骨架跑通一路 Dshow Capture3.1 枚举设备找到我要的那路视频源第一步是拿到设备列表。Dshow 用系统枚举器来遍历视频输入设备类别每个设备对应一个滤镜 CLSID。写一个函数收集所有设备的友好名称和 CLSID后续打开设备时要靠它定位。// 枚举系统中所有视频采集设备 #include dshow.h #include vector #pragma comment(lib, strmiids.lib) struct DevInfo { CComBSTR name; CLSID clsid; }; bool EnumVideoDevices(std::vectorDevInfo out) { CComPtrICreateDevEnum pEnumBuilder; HRESULT hr CoCreateInstance( CLSID_SystemDeviceEnum, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(pEnumBuilder)); if (FAILED(hr)) return false; CComPtrIEnumMoniker pEnum; hr pEnumBuilder-CreateClassEnumerator( CLSID_VideoInputDeviceCategory, pEnum, 0); if (hr ! S_OK) return false; // 注意没有设备时返回 S_FALSE CComPtrIMoniker pMoniker; while (pEnum-Next(1, pMoniker, nullptr) S_OK) { CComPtrIPropertyBag pBag; if (SUCCEEDED(pMoniker-BindToStorage(0, 0, IID_PPV_ARGS(pBag)))) { VARIANT var; VariantInit(var); if (SUCCEEDED(pBag-Read(LFriendlyName, var, nullptr))) { DevInfo info; info.name var.bstrVal; (void)pMoniker-GetClassID(info.clsid); out.push_back(info); VariantClear(var); } } pMoniker.Release(); } return !out.empty(); }逻辑说明通过系统设备枚举器拿到所有视频输入设备的 moniker再读取每个设备的 FriendlyName 以及对应的滤镜 CLSID。CreateClassEnumerator 返回 S_FALSE 表示该类别下没有设备这个分支必须处理否则返回值判断会踩坑。参数说明CLSID_VideoInputDeviceCategory 指明了要枚举的是视频输入设备类别第二个参数传 0 表示不需要附加标志。FriendlyName 是用户能在设备管理器里看到的名字一般包含厂商和型号信息多路摄像头同型号时仅凭这个名字很难区分需要配合设备实例路径或物理位置来处理。3.2 构建采集图把设备源、采样器、空渲染器接起来枚举出设备后下一步是实例化选中的滤镜、创建采集图、把各节点连接起来。我习惯用采集图构建器 ICaptureGraphBuilder2 来自动完成大部分管脚连接而不是手动去逐个 pin 查找。这样代码短而且对不熟悉 Dshow 内部结构的人更友好。// 打开指定设备并构建取帧链路 CComPtrIBaseFilter pCapFilter; CComPtrICaptureGraphBuilder2 pBuilder; CComPtrIGraphBuilder pGraph; CComPtrISampleGrabber pGrabber; // 1. 创建设备滤镜 hr CoCreateInstance(dev.clsid, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(pCapFilter)); // 2. 创建采集图构建器和滤镜图管理器 hr CoCreateInstance(CLSID_CaptureGraphBuilder2, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(pBuilder)); hr CoCreateInstance(CLSID_FilterGraph, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(pGraph)); pBuilder-SetFiltergraph(pGraph); pGraph-AddFilter(pCapFilter, LCaptureSource); // 3. 创建采样器滤镜并设置回调模式 hr CoCreateInstance(CLSID_SampleGrabber, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(pGrabber)); CComPtrIBaseFilter pGrabberBase; pGrabber-QueryInterface(IID_PPV_ARGS(pGrabberBase)); pGraph-AddFilter(pGrabberBase, LSampleGrabber); // 4. 用构建器把 采集管脚 - 采样器 - 默认渲染器 接好 hr pBuilder-RenderStream( PIN_CATEGORY_CAPTURE, MEDIATYPE_Video, pCapFilter, pGrabberBase, nullptr);逻辑说明RenderStream 一次调用完成了三段连接——源设备捕获管脚到采样器输入、采样器输出到默认渲染器。这个函数是 Dshow 采集里最省事的入口它内部会完成管脚枚举和媒体类型协商。若返回失败多半是设备被占用或管脚无法匹配格式。参数说明第一个参数指定管脚类别为捕获第二个限定视频媒体类型。第五个参数传 nullptr 表示让系统自动选择输出渲染端这里输出会被送到空渲染器画面不显示只保证链路完整。3.3 设置分辨率与帧率IAMStreamConfig 的格式协商细节采集出来的默认帧率和分辨率往往不是我们想要的。比如某款低成本 USB 摄像头默认输出 640×48015但应用需要 1280×72030。这时要通过 IAMStreamConfig 接口获取并设置采集管脚的媒体类型。// 设置 1280x72030 CComPtrIAMStreamConfig pStreamCfg; hr pBuilder-FindInterface( PIN_CATEGORY_CAPTURE, MEDIATYPE_Video, pCapFilter, IID_PPV_ARGS(pStreamCfg)); AM_MEDIA_TYPE* pmt nullptr; hr pStreamCfg-GetFormat(pmt); if (SUCCEEDED(hr) pmt-formattype FORMAT_VideoInfo) { VIDEOINFOHEADER* vih reinterpret_castVIDEOINFOHEADER*(pmt-pbFormat); vih-bmiHeader.biWidth 1280; vih-bmiHeader.biHeight 720; vih-bmiHeader.biSizeImage vih-bmiHeader.biSizeImage; // 重新计算见下文 vih-AvgTimePerFrame 333333; // 30fps 单位 100ns hr pStreamCfg-SetFormat(pmt); } DeleteMediaType(pmt);关键点在于 biSizeImage 必须重新计算。改成 1280×720 后YUY2 格式下每帧字节数为宽乘高乘 2即 1280×720×2RGB24 则是 1280×720×3。如果这个值填错后续取帧可能出现缓冲越界或花屏。AvgTimePerFrame 单位是 100 纳秒333333 对应大约 29.97 帧每秒。选型建议若回调里要直接用帧数据做图像处理优先协商成 RGB24省去每帧做色彩转换如果需要传输带宽更小或编码器直接吃 YUV选 YUY2。很多摄像头驱动对 RGB24 支持并不好协商失败时要能回退到原始格式不能写死。3.4 取帧回调把每一帧健康地交给业务线程采样器回调是取帧的核心但线程模型容易踩坑。ISampleGrabberCB 的回调方法运行在采集流线程上建议只做三件事校验格式、拷贝数据、放进无锁队列。耗时操作交给消费者线程。class FrameCallback : public ISampleGrabberCB { public: STDMETHODIMP QueryInterface(REFIID riid, void** ppv) override { if (riid IID_IUnknown) { *ppv static_castIUnknown*(this); return S_OK; } if (riid IID_ISampleGrabberCB) { *ppv static_castISampleGrabberCB*(this); return S_OK; } return E_NOINTERFACE; } STDMETHODIMP_(ULONG) AddRef() override { return ref_; } STDMETHODIMP_(ULONG) Release() override { if (--ref_ 0) { delete this; return 0; } return ref_; } // SampleTime 秒SampleTime100ns 纳秒 STDMETHODIMP SampleCB(double /*SampleTime*/, IMediaSample* pSample) override { BYTE* buf nullptr; pSample-GetPointer(buf); long len pSample-GetActualDataLength(); // 这里只做 memcpy 入队列不做格式转换 PushFrame(buf, len); return S_OK; } STDMETHODIMP BufferCB(double, BYTE*, long) override { return E_NOTIMPL; // 不采用 Buffer 模式 } };逻辑说明SampleCB 是回调入口参数里的 IMediaSample 持有帧数据和长度。调用 GetActualDataLength 拿到的长度应该和之前协商的 biSizeImage 一致若不一致大概率是设备驱动在帧数据前加了附加信息需要进一步解析。参数说明SampleCB 的第一个参数是采样时间注意它同时提供了秒和 100 纳秒两种。两个回调方法只用其中一个Buffer 模式会让采样器内部再做一次内存拷贝性能上不如 Sample 模式直接操作样本内存。别同时实现两个方法某些驱动会行为异常。3.5 完整的启停流程别漏掉图状态切换这一步图构建完成后正式启动是调用滤镜图管理器的 Run 方法。停止时先 Stop 图再断开连接、释放滤镜顺序不能乱。直接释放滤镜而不停图轻则内存泄漏重则后续设备无法被其它进程打开。pGraph-Run(); // 业务执行若干帧后... pGraph-Stop(); pGraph-RemoveFilter(pGrabberBase); // 再释放所有 CComPtrCOM 组件会自行释放这里有一个容易被忽略的细节Run 返回成功不代表第一帧已经到达。某些摄像头驱动启动后需要几十到几百毫秒才输出第一帧应用层等待第一帧时要有超时机制不能无限等。我一般设置 3 秒超时超时后按设备异常处理并尝试重启链路。4. Dshow Capture 避坑清单现象、原因、解法4.1 设备打开失败错误码是未知的 VFW_E_CANNOT_CONNECT现象RenderStream 返回错误设备在枚举器里能看到但构建图时报无法连接。 原因最常见是设备滤镜已经被另一个进程占用。Windows 上多数 USB 摄像头驱动只允许单进程独占相机应用没退出你的代码就连接不上。 解决先排查是否有直播软件、相机工具或调试程序在占用设备用设备管理器重启该设备可强制释放。另一个原因是采集管脚上协商不出匹配的媒体类型换用 GetStreamCaps 查看驱动提供的所有格式选一个再 SetFormat。4.2 设置了 1280×720画面却还是 640×480现象注册表属性或调试输出都是 720p但回调里拿到的帧宽度明显是 640。 原因设置了错误实例的 IAMStreamConfig。视频源滤镜上可能同时存在捕获管脚和预览管脚两个管脚各有独立配置。调用了预览管脚的配置采集管脚不会生效。 解决确保 FindInterface 的第一个参数是 PIN_CATEGORY_CAPTURE且在 RenderStream 之前完成设置。若构建图之后再 SetFormat部分驱动不支持运行中变更格式必须停图、设置、重新建图。4.3 回调一直不触发但图是 Run 状态现象pGraph-Run 成功SampleCB 却始终不被调用。 原因回调接口没有正确注册或采样器输入管脚的媒体类型没有设置。ISampleGrabber::SetMediaType 只在连接之前有效若连接已经完成再设置采样器不会重新协商。 解决在 RenderStream 之前先用 ISampleGrabber::SetMediaType 设置一个兼容的媒体类型比如指定主类型为视频其它字段设 ANY连接完成后通过 ISampleGrabber::GetConnectedMediaType 确认实际协商出的格式。另外确认回调对象生命周期要覆盖整个采集期间不要用栈对象。4.4 取到的画面颜色发绿或发紫现象图像轮廓正常颜色完全不对绿色和紫色为主。 原因回调拿到的数据是 YUY2但代码按 RGB 解释或者反之。YUY2 是隔行存放亮度和色差的编码直接当 RGB 用必然偏色。 解决图像处理前明确检查连接后的媒体类型。subtype 为 MEDIASUBTYPE_YUY2 时要做一次 YUV 转 RGB想省掉这一步就在协商阶段直接把格式设成 RGB24。不少摄像头驱动对 RGB24 支持不完整所以判断逻辑要写成「能 RGB24 就用 RGB24否则 YUY2 加转换」。4.5 长时间运行后内存持续增长现象程序跑几小时后内存占用线性上涨。 原因一种可能是 SampleCB 里把数据放进队列后消费者处理不过来积压全部留在队列另一种是 ISampleGrabber 内部缓冲没有及时释放。 解决队列加最大长度限制满了丢最旧帧而不是新帧保证内存有上界。同时确认 Release 链路不遗漏CComPtr 能自动释放但自己手动 AddRef 过的地方要成对 Release。5. 进阶技巧把延迟压到最低承接多路并发采集5.1 减缓冲、减拷贝让帧从传感器到应用层尽量少中转延迟的主要来源不是处理速度而是缓冲层数。摄像头驱动内部有缓冲Dshow 滤镜图各节点之间也有缓冲SampleCB 拿到帧再拷贝一次总共可能引入三到四帧延迟。对于 USB 摄像头这种源头端就带缓冲的设备能做的是减少链路里的额外拷贝以及尽量把无意义节点移除。我一般会确认图中只有三个节点源滤镜、采样器、空渲染器。任何插在中间的颜色转换滤镜、缩放滤镜都会增加处理时间。SampleCB 里的拷贝动作也有优化空间——如果消费者处理速度稳定可以考虑用环形缓冲区直接交换指针而不是每帧 memcpy但这要求消费者严格遵守「用完即还」的约定否则下一帧数据会被踩坏。5.2 帧率控制摄像头标称帧率不是实际帧率UVC 摄像头的帧率由驱动的流参数决定Dshow 里 AvgTimePerFrame 只是一个协商值大量驱动会忽略它仍然按默认帧率出帧。更可靠的做法是应用层自己控制消费节奏。// 每帧到达按系统时间节流目标 30fps auto now std::chrono::steady_clock::now(); auto diff now - lastConsumeTime_; if (diff std::chrono::milliseconds(33)) { DropFrame(); // 丢弃当前帧不消费 return; } lastConsumeTime_ now; ProcessFrame(pendingFrame_);逻辑说明这里用消费侧节流而不是睡眠等待。睡眠会把线程挂起在时间精度和调度上都不可靠框架里丢帧更高效。注意累计丢帧数量如果丢帧率超过 20%说明处理速度跟不上需要回看分辨率设置是否合理。参数说明33 毫秒对应约 30fps。如果目标帧率是 60fps改成 16 毫秒。实际处理中建议留一点余量比如目标 30fps 就用 30 毫秒判断避免处理时间的抖动导致节奏忽快忽慢。5.3 多路采集每路各建各的图线程模型要独立多路摄像头同时采集时最省事也最稳的做法是每路设备一条独立的滤镜图、一个独立的回调线程、一个独立的帧队列。很多人想用单线程轮询多路采样器但 Dshow 的流线程机制决定了回调不按调用者意愿调度单线程轮询也无法响应各路到达的随机性。// 每路设备一个上下文 struct CaptureSession { CComPtrIGraphBuilder graph; CComPtrISampleGrabber grabber; CComPtrIBaseFilter source; std::thread worker; bool running; };多路并发时最容易出现的问题是各路回调里的拷贝操作抢 CPU。解决方法是每一路回调只做入队多路队列由后端线程批量消费。实测经验是两路 1080p YUY2 同时入队加消费在现代处理器上 CPU 占用可以控制在 15% 以内一旦在回调里做色彩转换相同负载 CPU 会直接飙到 40% 以上。这也是为什么我反复强调转换动作必须移出回调。5.4 热插拔处理连接结构中也有后悔药现场环境经常有人随手拔插摄像头。Dshow 构建好的图在设备拔出后基本无法恢复必须拆掉整条链路重新枚举和重建。我习惯在应用层做一个设备状态检查线程隔几秒枚举一次系统设备列表发现设备数量或名字集合与初始状态不一致时自动触发重建流程。重建前先 Stop 图、释放所有滤镜再走一遍第 3 章的流程。另一个容易漏掉的点设备拔出后回调不会报错只是静默停止。要判断设备是否还活着最有效的方式是监控帧间隔——如果连续超过设定秒数没有新帧到达就认为设备离线主动触发重建而不是被动等用户反馈。5.5 回调线程的 CPU 亲和性与调度老设备的最后一招部分老旧驱动在回调里会做一些额外工作如果发现单路采集 CPU 占用异常偏高可以尝试把流线程的 CPU 亲和性绑定到一个核心上避免线程在核心间频繁迁移。这个手段不能解决所有问题但在某些廉价 USB 摄像头上能明显降低采集部分的抖动。做法是回调线程内调用 SetThreadAffinityMask绑定到非主线程所在的核心。视频采集这类持续高频小任务本质上拼的是链路里中转次数和处理动作的位置。现在我再接一路新的 USB 摄像头时第一件事不是写代码而是先跑一遍设备枚举确认驱动是标准 UVC 还是厂商私有协议这决定了后续格式协商和延迟优化的路线。这个习惯帮我省掉了后面至少一半的返工。希望帮到你。本文还有配套的精品资源点击获取