DirectShow虚拟摄像头vcam_dshow-master：原理、编译与避坑指南

简介：面向Windows平台多媒体开发者的DirectShow虚拟摄像头实现工程，借助VCam方案将RTSP/HTTP等网络视频流封装为系统可识别的本地摄像头设备，适用于视频会议、直播推流等需要多路虚拟视频源的场景。压缩包共18个文件，其中cpp/h源码用于实现网络流接收与过滤器核心逻辑，bat脚本负责设备注册与卸载，dll为已编译组件，sln/vcxproj为Visual Studio工程文件，整体仅139KB，结构精简。已有2337人学习。通过该工程可掌握DirectShow过滤器开发流程，包括IBaseFilter/IPin等接口实现、缓冲队列应对网络抖动、GraphEdit构建过滤器图以及注册虚拟设备的方法，同时附带README说明与工程截图，便于快速确认环境配置。若需二开或嵌入自有采集流程，可作为轻量级基础模板。

1. vcam_dshow-master 是什么：一个把普通程序变成虚拟摄像头的 DirectShow 工程

虚拟摄像头这个词很容易被误解成“改浏览器设置”或者“装个滤镜”，实际上在 Windows 平台上，它指的是一种特殊的系统组件：一个不连接任何物理采集设备，却让所有支持摄像头调用的软件都以为它是一个真实摄像头的 DirectShow Filter。这个标题里的 vcam_dshow-master，正是一个典型的虚拟摄像头工程，通常是把视频源（屏幕、图片、算法生成的图像）封装成 DirectShow 采集设备，注册后就能出现在各类视频软件的设备列表里。它适合三种人：直播时想用屏幕作为第二机位的开发者、自动化测试里需要稳定视频信号而没有真实硬件的测试人员，以及想搞懂 DirectShow 采集链路底层输出的初学者。

2. DirectShow 管线与虚拟摄像头工作原理：先搞懂帧从哪来到哪去

虚拟摄像头不是通过“截取系统摄像头输出”实现的，而是主动冒充设备。这个区别决定了很多人在使用 vcam_dshow-master 时的调试思路：如果画面不出，问题往往不在画面内容，而在系统有没有把你的 Filter 当成一个合法的采集源。因此，先把 DirectShow 管线中的几个关键角色弄清楚。

2.1 虚拟摄像头的本质：一个把自己伪装成采集设备的 COM 组件

在 Windows 的视频采集体系里，DirectShow 使用一个统一接口来管理摄像头：应用层通过枚举器创建视频输入设备，然后使用 IGraphBuilder 把设备接入一个 Filter Graph。真实摄像头靠硬件驱动暴露接口，虚拟摄像头则是一个纯软件的进程内 COM 对象，必须实现 IBaseFilter、IPin 以及必要的流媒体接口，核心是让系统认为它是一个“采集 Filter”。

常见做法是继承 BaseClasses 里的 CBaseFilter 和 CBasePin，这样做可以避免重复实现很多 COM 样板代码。这个工程被命名为 vcam_dshow，说明它的主要代码策略是围绕 DirectShow 的 CSourceStream 或者自定义推流 Pin 来构造输出帧。虚拟设备不会自己产生视频数据，它的输入侧是软件回调或外部写入，输出侧是 DirectShow 的上下流传输。所以看待这个工程时，脑子里要先有一条线：外部输入帧 -> 内部缓冲 -> 输出 Pin 的 FillBuffer -> Deliver。任何一环断开，都会表现成“设备被识别，但画面是黑的”。

在 Pin 连接阶段，DirectShow 会调用 CheckMediaType 来确认下游请求的媒体类型是不是你支持的。这里不要把所有类型都放行，否则后续转换会非常痛苦。我一般只接受 RGB24 和 YUY2 两种，能覆盖绝大多数消费级软件。

// 输出 Pin 的媒体类型检查：只放行视频，且限于两种常见格式 HRESULT CheckMediaType(const CMediaType* pmt) { // 主类型必须是视频 if (pmt->majortype != MEDIATYPE_Video) { return E_INVALIDARG; } // 次类型只收 RGB24 和 YUY2，其他格式后面转换成本高 if (pmt->subtype != MEDIASUBTYPE_RGB24 && pmt->subtype != MEDIASUBTYPE_YUY2) { return E_INVALIDARG; } return S_OK; }

参数说明：pmt 是 DirectShow 里描述媒体类型的结构体，majortype 为 MEDIATYPE_Video 代表视频流，subtype 决定了像素排列格式。限制 subtype 的种类会让上层调用的格式协商更简单，也让你不需要在一开始就实现一堆像素格式转换器。如果你的虚拟摄像头需要支持特殊格式，可以放宽这里，但同时要在后续的推帧循环里增加转换分支。

2.2 帧数据从哪来：Push Source 模式的推帧循环

DirectShow 的采集设备天然是 Push Source，也就是主动向 Graph 推送帧，而不是等待下游拉取。这是虚拟摄像头实现里最容易写错的部分。虚拟摄像头的线程循环里，每个周期要完成一次“拿帧-拷贝-设时间戳-投递”的动作。下面是简化版的推帧循环，真实工程里会把它拆到 FillBuffer 里，但核心逻辑一样。

// 虚拟摄像头线程循环：每到一个帧间隔就执行一次 while (!m_stop) { // 1. 从输入源取最新一帧，可能是 GDI 屏幕采集或外部回调 BYTE* frame = inputSource->GetLastFrame(); if (frame != nullptr) { // 2. 从媒体样本里拿一块可写内存 BYTE* dst = nullptr; pSample->GetPointer(&dst); if (dst != nullptr) { // 3. 按当前协商好的分辨率拷贝到输出缓冲 memcpy(dst, frame, m_cbImageSize); pSample->SetActualDataLength(m_cbImageSize); } // 4. 时间戳必须是递增值，否则播放端会把帧识别为重复帧 pSample->SetTime(&m_rtStart, &m_rtStop); m_pPin->Deliver(pSample); } // 5. 帧间隔用 10^7 / fps 计算，单位是 100ns Sleep(m_iFrameIntervalMs); }

这段代码里最容易忽略的是 m_rtStart 的更新。很多人把时间戳固定成一个常数，结果播放器看起来一帧都没有。递推方式通常是每帧增加 AvgTimePerFrame，也就是 m_rtStop += m_rtAvgTime。Sleep 的 m_iFrameIntervalMs 与 DirectShow 时间单位不同，这里先用毫秒只是为了可读性，真正工程里建议用等待定时器，后面我会专门讲怎么补偿。

媒体样本 pSample 的生命周期也需要注意：每次从队列取出的样本在使用后应当被释放，否则样本池耗尽，推帧循环会一直拿不到可用内存。很多时候黑屏伴随着内存慢慢上涨，基本就是这个原因。你可以在 Deliver 返回后将 pSample 置空，并在下一轮重新从队列获取。

2.3 注册机制：为什么 regsvr32 一个 DLL 就能让系统认识摄像头

虚拟摄像头的“安装”不是复制文件，而是通过 regsvr32 调用 DLL 里的 DllRegisterServer，把设备信息写进注册表。DirectShow 枚举器在扫描视频输入设备时，会查找固定的类别位点，也就是 CLSID_VideoInputDeviceCategory 对应的注册表分支。每个虚拟摄像头只需要在这个分支的 Instance 子键下，用一个自己的 CLSID 指向 DLL 路径，并且提供 FriendlyName 作为显示名。

这些键写完后，系统才会把你的 DLL 当作摄像头。注意 64 位系统有 32 位和 64 位两套注册表视野，regsvr32 要用对应位数的版本去执行。这个问题在避坑章节里会展开。

另外需要理解为什么必须有 Instance 键：DirectShow 枚举器不是随便扫描所有 CLSID，它只认视频输入设备类别下的实例。很多简化版的 DllRegisterServer 只写了自己的 CLSID，漏掉了 Instance 子键，结果就是设备列表为空。检查时优先看这两个位置，不要一上来怀疑源码逻辑。

3. 把 vcam_dshow-master 跑起来：从源码到系统级虚拟设备

拿到源码后最怕的不是改业务逻辑，而是连编译和注册都走不通。很多 vcam 工程都有同样的特征：没有完整包含 BaseClasses，依赖旧的 DirectShow SDK，或者用 x64 编译后忘记注册成 64 位。这一章给出我常用的跑通路径。

3.1 编译环境与前置依赖：先解决 BaseClasses 和平台工具集

大多数基于 DirectShow 的源码包，编译前最卡人的是 BaseClasses。这是 Windows SDK 附带的 DirectShow 基类库，包含 CBaseFilter、CBasePin、CSourceStream 等常用基类，通常能在 SDK 的旧版示例目录里找到，但新版 SDK 默认不再安装这些示例。我一般会直接从项目依赖的 SDK 版本里复制一份 BaseClasses 源码放到第三方目录，然后用静态库方式编译。

以 VS 2019 环境为例，我会先打开“开发者命令提示符”，执行 vcvars64.bat 初始化环境，再编译 BaseClasses 和主工程。如果工程文件是老的 .vcxproj，直接把平台工具集改成 v142 就能用，字符集建议用 Unicode，多字节那套旧代码在注册表字符串处理上容易出警告但不致命。

call "<VS安装目录>\VC\Auxiliary\Build\vcvars64.bat" # 先编依赖库，再编主项目，Release 比 Debug 更接近真实使用 msbuild baseclasses\baseclasses.vcxproj /p:Configuration=Release /p:Platform=x64 msbuild vcam.vcxproj /p:Configuration=Release /p:Platform=x64

参数说明：/p:Configuration 指定编译配置，Release 用于发布，Debug 方便打断点，但注意 Debug 的线程调度差异可能会导致虚拟摄像头更卡；/p:Platform 指定 x64，如果电脑是 64 位系统且调用方都是 64 位软件，比如新版会议软件，就一定要用 x64。老版本 OBS 或其他 32 位程序无法加载 64 位 DLL，这就是后面设备列表里看不到虚拟摄像头的常见原因之一。

判断源码本身是 32 位还是 64 位，可以直接看工程配置管理器里的活动平台，也可以看链接器输入里的 uuid.lib 路径。最省事的办法是编译两次，分别产出 x64 和 Win32 版本，注册时再按调用方情况选择。不要觉得麻烦，一次到位能省下很多排查时间。

3.2 注册虚拟摄像头：regsvr32 之后发生了什么

编译产物通常是一个 vcam.dll。注册前先确认 DLL 导出表里有 DllRegisterServer，可以用 dumpbin 查看，也可以直接执行注册命令看结果。右键管理员执行注册命令，如果没有任何输出，绝大多数情况是注册成功。

regsvr32 /s x64\Release\vcam.dll

/s 是静默模式，注册成功不弹窗。注册失败会弹错误码，最常见的是 0x80040201，这通常是 DirectShow 相关类别注册失败，要检查系统是否有 DirectShow 基础组件。我建议注册后立刻打开注册表确认，不要只看 regsvr32 是否返回 0。

# 查询虚拟摄像头设备类别下是否出现了你的 CLSID reg query HKLM\SOFTWARE\Classes\CLSID\{你的CLSID}\Instance reg query "HKLM\SOFTWARE\WOW6432Node\Classes\CLSID\{你的CLSID}" /s

第二行是给 32 位进程看的注册表视图。如果你注册的是 32 位 DLL，regsvr32 会自动写 WOW6432Node，但用 reg query 时要注意分别查。注册表的 CLSID 并不是随便写的，它要和你源码里的 DEFINE_GUID 保持一致，否则卸载时找不到对应文件，注册时也会造成遗留。我的习惯是把 CLSID 单独放在一个头文件里，这样修改设备名称时只改 FriendlyName，不用动 GUID。

注册失败时，先看错误弹窗里的 HRESULT，再去事件查看器里找 ActiveDS 相关记录。如果是 0x80070005 代表权限不足，需要管理员权限；如果是 0x8002801C 则可能文件依赖的 C 运行时缺失。最稳妥的临时办法是手动写注册表，把 InprocServer32 指到绝对路径，注册表类型用 REG_EXPAND_SZ，避免路径中的环境变量解析失败。

3.3 最小验证：用 ffmpeg 的 dshow 列表确认设备生效

有一台虚拟摄像头是否被系统认出来，最轻量的办法是用 ffmpeg 的 dshow 输入格式枚举设备。这条命令不需要打开任何图形软件，命令输出里看到 vcam 的名字，就说明注册表和 DLL 加载都通了。

ffmpeg -list_devices true -f dshow -i dummy

看到输出中有一行类似“Alternative name”为 vcam 的条目后，可以进一步预览一帧或抓一下流，确认不是只有名字、没有帧数据。

ffmpeg -f dshow -video_size 640x480 -framerate 30 -i video="vcam" -frames:v 1 out.bmp

这里 video_size 和 framerate 是请求参数，虚拟摄像头内部如果实现了 IAMStreamConfig，会尝试满足请求。抓帧成功说明管道是通的。如果这步失败，但设备列表里已有名字，问题基本集中在推帧线程或格式协商上，而不是注册表。最小验证不推荐直接用大型会议软件，因为它们在设备打开失败后有自己的缓存，很难判断你是配置问题还是设备问题。

如果 ffmpeg 抓帧正常，但你仍怀疑帧序有问题，还可以用图编辑器工具手工连接输出 Pin 到视频渲染器，观察实时画面是否正常滚动。这种工具对查“黑帧但设备在”的问题特别好用，因为它能直接看到 Pin 连接返回的 HRESULT，还能监听媒体事件。

4. 修改虚拟摄像头行为：输入源、分辨率与帧率的三个可调点

跑通后的需求顺序一般是：先换输入源，再改分辨率，最后调帧率。这三个点分别对应采集逻辑、格式协商和定时器设计，也是这个工程里真正的业务价值所在。

4.1 输入源切换：从屏幕抓取到回调缓冲区，改一个枚举值就行

拿到别人的源码，最常见的是虚拟摄像头输出一张静态图片或者直接输出黑色帧。把它改成屏幕采集或外部程序写入的帧，需要先找到输入源抽象层。通常会有类似 InputSource 的纯虚类，下面代码演示如何用一个枚举控制输入源类型。

enum class SourceType { StaticBitmap, // 静态图 ScreenCapture, // 屏幕抓取 ExternalMemory // 外部程序通过共享内存写入 }; class InputSource { public: virtual BYTE* GetLastFrame() = 0; virtual void OnFrameArrived() = 0; }; // 切换输入源：在配置加载处初始化对应的实现 InputSource* CreateSource(SourceType type) { switch (type) { case SourceType::StaticBitmap: return new BitmapSource(L"bg.bmp"); // 加载位图 case SourceType::ScreenCapture: return new GDIScreenSource(); // 定时 BitBlt 抓屏 case SourceType::ExternalMemory: return new SharedMemorySource(0x1234); // 读取共享内存映射 } }

这个设计的参数重点是 ExternalMemorySource 的 key：虚拟摄像头本身不生产内容时，外部程序只需要知道 key 和帧格式，就能自己写像素。很多自动化测试方案就是这么并联在一起的：测试脚本把 UI 渲染结果写入共享内存，虚拟摄像头把它包装成摄像头帧，被测软件就拿到了“摄像头输入”。修改输入源后要不要重新注册？不需要，直接调试即可，但注意你打开的采集软件不会自动感知新格式，需要重启软件。

屏幕采集部分，GDI 的 BitBlt 在 1080p 下能跑 30fps 但 CPU 占用高；如果追求性能，可以用 DXGI Desktop Duplication 拿 GPU 表面的最新帧，再映射成 CPU 可读内存。两种方案在输入源抽象层里只差一个实现类，对上层代码完全透明。我建议先把静态图和共享内存两个输入源试通，最后再上屏幕采集，这样排查时输入侧更容易定位。

4.2 分辨率与帧率协商：SetFormat 里做了哪些事

DirectShow 客户端调用 IAMStreamConfig::SetFormat 时，虚拟摄像头不能只是把参数存起来，它必须同步调整内部发送缓冲的大小和锁存格式。老代码经常犯的错误是只在 GetStreamCaps 里填了几组分辨率，但 SetFormat 里不把 m_pBuffer 重新分配，结果就是画面花屏或直接崩溃。

HRESULT SetFormat(AM_MEDIA_TYPE* pmt) { VIDEOINFOHEADER* pvi = (VIDEOINFOHEADER*)pmt->pbFormat; // 更新分辨率和帧率局部变量 m_width = pvi->bmiHeader.biWidth; m_height = pvi->bmiHeader.biHeight; m_rtAvgTime = pvi->AvgTimePerFrame; // 重算 RGB24 下的缓冲大小，就是 w*h*3 m_cbImageSize = m_width * m_height * 3; delete[] m_pBuffer; m_pBuffer = new BYTE[m_cbImageSize]; // 通知推帧线程，下一帧开始使用新参数 return S_OK; }

参数说明：pvi->AvgTimePerFrame 是 DirectShow 时间单位，100 纳秒每刻度。30 帧每秒对应约 333333，25fps 是 400000。如果把 333333 写成 33.3 这种浮点值，很多播放器会认为帧率惊人地快，于是卡死。另外 biHeight 如果是负数，代表从下到上的 BMP 行序，DirectShow 摄像头通常使用正数逐行，但有些 RGB24 输出会带负号，导致画面上下颠倒。我建议在 SetFormat 里统一校正为正的 biHeight，并且在推帧时按正序写入。

GetStreamCaps 是另一个必须实现的接口，客户端靠它枚举可用的分辨率列表。顺序很重要：把最常用的 1920x1080、1280x720 放在前面，某些软件只读第一个格式。如果默认格式是 320x240，应用首选项里就永远只有 320x240。

// 返回格式列表时，按优先级排列 HRESULT GetStreamCaps(int iIndex, AM_MEDIA_TYPE** ppmt, BYTE* pSCC) { static const SIZE_AND_RATE kFormats[] = { {1920, 1080, 333333}, // 30fps {1280, 720, 333333}, { 640, 480, 400000}, }; if (iIndex < 0 || iIndex >= 3) return S_FALSE; // 填充 AM_MEDIA_TYPE，subtype 使用 MEDIASUBTYPE_RGB24 或 YUY2 return S_OK; }

这里的关键参数是数组顺序直接决定枚举顺序，一些老软件会认为下标 0 的格式是默认格式。如果你的虚拟摄像头被识别成默认 640x480，先回来调整数组顺序，而不是去改注册表。GetStreamCaps 里的 pSCC 是 VIDEO_STREAM_CONFIG_CAPS，用来声明分辨率范围和帧率范围，有些播放器会根据它生成 UI 里的分辨率列表，所以尽量把最大最小值填得准一些。

4.3 颜色空间与格式转换：RGB24 和 YUY2 的选择

视频软件对摄像头设备的偏好不同，老一批应用默认请求 YUY2，因为它是压缩后的彩色信号，占带宽小；但屏幕采集出来的通常是 BGRA 或 RGB，所以需要在虚拟摄像头里做一次转换。不做转换或转换错，会出现红色和蓝色对调、画面发绿、或者黑屏。常见做法是统一在内部保留 RGB24 作为中间格式，输出侧再转换成客户端请求的 subtype。

// 简化版 RGB24 转 YUY2，每两个像素生成 4 字节输出 void ConvertRgb24ToYuy2(const BYTE* rgb, BYTE* out, int width, int height) { const int totalPixels = width * height; for (int i = 0, o = 0; i < totalPixels; i += 2, o += 4) { const BYTE r0 = rgb[0], g0 = rgb[1], b0 = rgb[2]; const BYTE r1 = rgb[3], g1 = rgb[4], b1 = rgb[5]; // Y、U、V 的计算来自 BT.601 标准，做了 128 偏移 out[o + 0] = (BYTE)((66 * r0 + 129 * g0 + 25 * b0 + 128) >> 8); out[o + 1] = (BYTE)((-38 * r0 - 74 * g0 + 112 * b0 + 128) >> 8); out[o + 2] = (BYTE)((66 * r1 + 129 * g1 + 25 * b1 + 128) >> 8); out[o + 3] = (BYTE)((112 * r0 - 94 * g0 - 18 * b0 + 128) >> 8); } (void)height; }

参数说明：这两组系数是标准的 RGB 到 YCbCr 近似公式，Y 用前一个像素算，U 和 V 分别取两个像素的信号，YUY2 本身就是 4:2:2 采样，所以这种简化是可行的。如果画面出现颜色偏色，先检查转换公式里是否遗漏 +128 偏移，YUV 的 U/V 是无符号数。性能方面，这种逐像素循环在 1080p30 下压力很大，建议改成查表法或使用 SIMD。

实际上大多数现代软件更喜欢直接读取 RGB24，因为省去一次软件转换。但如果你的虚拟摄像头要被老的视频采集工具调用，YUY2 往往是唯一会被接受的格式。稳妥做法是同时在 GetStreamCaps 里暴露 RGB24 和 YUY2，让应用选；但实现时别在推帧线程里做转换，而是预分配两个缓冲区，一个保存原始帧，一个保存转换结果，根据当前协商的格式选择投递哪一个。这样切换格式时不会产生半帧。

5. vcam_dshow 使用避坑：5 个反复出现的坑与排查路径

这章是我根据多次接类似工程总结出来的高发问题，每个都按“现象-原因-解决”写清楚。如果你第一次上手，建议先把这一章看完再改代码，能省下大量查黑匣子的时间。

5.1 注册成功但采集软件里看不到设备

现象：regsvr32 返回成功，用软件或 ffmpeg 枚举列表里没有虚拟摄像头。原因通常是注册表视图和进程位数不匹配：64 位采集程序只能加载 64 位 DLL，32 位程序只能加载 32 位 DLL，很多源码只提供了 x64 编译，注册后 32 位程序自然看不到。另外也可能是 DllRegisterServer 只写了 CLSID 分支，没写设备类别 Instance 键。解决：先确认所有采集程序位数，用对应位数的 regsvr32 注册；再用 reg query 检查设备类别分支下是否有你的 CLSID；如果没有，检查源码里的 RegisterServer 是否在枚举器类别下创建了 Instance 子键，手工补上也可以作为临时措施。

5.2 设备列表有名字，打开后黑屏且进程占用 CPU 100%

现象：ffmpeg 里能看到设备，打开后只有黑屏，而且宿主进程 CPU 占用很高。原因通常是推帧循环死等一个从未得到的锁或信号量，常见于输入源是共享内存时，写入方没有启动；也可能是时间戳没有递增，DirectShow 判定为重复帧从而丢弃。解决：先开一个最简单输入源（静态图片）测试，排除输入源问题；再检查 Deliver 返回值，如果返回 S_FALSE 说明下游已经断开，仍然继续推帧会白耗 CPU。时间戳递增问题可以在推帧循环里打印 m_rtStart，确认它是变大而不是恒定。

5.3 分辨率协商失效，指定 1080P 仍输出 640x480

现象：ffmpeg 或视频软件里请求 1920x1080，实际拿到的帧仍是 640x480 或者干脆设备打不开。原因大概率是 SetFormat 接口没有真正重设内部缓冲，或者 GetStreamCaps 没把 1080P 排在索引 0。解决：在 SetFormat 里至少更新三个变量：m_cbImageSize 按新宽高重算、m_pBuffer 重新分配、m_rtAvgTime 从 pvi->AvgTimePerFrame 读取；同时把常用的 1080P 放到 GetStreamCaps 数组开头，并让 SetFormat 的入参格式与其一致。改完后重新打开采集软件，因为大部分软件只在启动时枚举一次格式列表，运行中不会重新读取。

5.4 视频卡顿，实际帧率远低于设定的 30fps

现象：看似在 Sleep(33)，但通过抓帧统计只有 15fps。原因：Sleep 的时间不准确，加上每帧拷贝耗时可能超过阻塞时间，导致实际周期是“耗时+Sleep”而不是“精准定时”。解决：不要用 Sleep 累加，改成绝对时间点。常见做法是使用 timeBeginPeriod 把系统定时器精度调高，再配合 QueryPerformanceCounter 记录下一帧时间点，下面给出一个框架。

// 用 QPC 做绝对时间点调度，避免 Sleep 累积误差 LARGE_INTEGER qpf, qpc; QueryPerformanceFrequency(&qpf); QueryPerformanceCounter(&qpc); LONGLONG next = qpc.QuadPart + qpf.QuadPart / 30; // 初始下一帧 while (!m_stop) { QueryPerformanceCounter(&qpc); if (qpc.QuadPart < next) { DWORD waitMs = (DWORD)((next - qpc.QuadPart) * 1000 / qpf.QuadPart); Sleep(waitMs); continue; } // 计算是否跳帧：如果落后太多则只处理一帧 DeliverFrame(); next += qpf.QuadPart / 30; }

参数说明：qpf 是高频计时器频率，用系统频率除以目标 fps 得到每帧时钟周期，next 是绝对帧边界。每轮循环只算一次 waitMs，比每次累加 Sleep 更准。跳帧逻辑要谨慎：如果推流耗时大于一个帧周期，next 会越追越远，此时应先判断落后程度，若落后超过两帧就直接跳到当前时间点，避免一次补很多帧导致客户端抖动。

5.5 卸载后 DLL 被占用，设备列表残留幽灵设备

现象：关掉软件后执行 regsvr32 /u 报“文件被占用”，再打开枚举列表还能看到摄像头名字，但点开就报错。原因：虚拟摄像头 DLL 被某些音视频软件的预览进程或后台服务加载，卸载时没有释放；或者注册表 Instance 键没有被完整删除。解决：先打开任务管理器，结束所有可能访问了摄像头的进程；再执行 regsvr32 /u，如果仍失败，手动删除注册表里的两个位置：CLSID 分支和设备类别下的 Instance 子键；最后用 ffmpeg 枚举确认列表为空。为了避免幽灵设备，开发和卸载时最好使用独立的测试软件，不要一边开着 OBS 一边反复注册卸载。

6. 从 Demo 到可用：给虚拟摄像头加帧率补偿与延迟消抖的细节技巧

许多人把 vcam_dshow 跑通后就停在了“能出画面”，实际交付给直播或会议软件时，会发现画面在运动时出现一抖一抖，不是编码问题，而是推送帧之间的时间间隔不均匀。进制和颜色空间都正确的情况下，帧率表现的唯一决定性因素就是推帧调度。这里给你一个我自己常用的做法：把“按固定间隔推送”改成“按绝对时间轴推送”，并加入落后补偿。第五章已经给了 QPC 框架，这章重点讲两个补充技巧。

6.1 用双缓冲抵消拷贝耗时

直接在 QPC 循环里调用 DeliverFrame，如果内部的 memcpy 需要 5ms，那么下一帧的开始时间就不会落在绝对时间点上。解决办法是把推帧和拷贝分成两个动作：推帧循环把输入源拷贝到一个后缓冲，Deliver 时只发送一个前缓冲的引用。这样一个 30fps 的流，即使拷贝耗时波动，发送时刻也只取决于定时器。信号量命名要清晰，常用的是一对事件，写入完成置位，Deliver 后清掉，避免事件堆积导致帧排队。

6.2 用 ffmpeg 统计实际帧率验证效果

调完帧率补偿后，不要用眼睛判断顺滑，用抓流统计更可靠。

ffmpeg -f dshow -video_size 1280x720 -framerate 30 -i video="vcam" -t 10 -f null -

命令参数说明：-t 10 表示抓取 10 秒，-f null 表示只解码不做编码输出，统计结束后 ffmpeg 会打印 real-time 和 frame 数，用帧数除以时间就能算出实际帧率。如果在 10 秒里稳定在 290 帧左右，说明推帧节奏没问题；如果只有 150 帧，说明线程调度或输入源延迟依然存在。我最早做类似的虚拟摄像头时，习惯性只用 Sleep(1000/fps)，结果在 720p 下的拍摄画面不断出现周期性抽动，后来把所有时间戳统一成 REFERENCE_TIME 并改用 QPC 绝对点，问题才消除。做这种组件最忌讳把“看起来能跑”当成“可用”，帧率和延迟指标必须靠解码器统计而不是肉眼看。希望这些细节能帮到你。

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