OBS如何录制被遮挡的隐藏窗口？其窗口捕获实现原理是什么

当前BitBlt方案的瓶颈原因 #

• 你使用的BitBlt+GetDC(hwnd)属于GDI捕获方案，本质是跨进程请求目标窗口主动将渲染结果同步到GDI设备上下文，涉及多次用户态到内核态的切换和全量像素内存拷贝，本身开销就很高。
• 当窗口被遮挡或最小化时，系统会自动暂停目标窗口的渲染调度来节省资源，每次调用捕获接口时都需要临时触发窗口重绘，这一步的耗时会随系统负载波动，从几毫秒到几百毫秒不等，自然无法满足稳定60fps的要求。
• 捕获逻辑和cv2VideoWriter的写入逻辑在同一线程同步执行，编码、写入这类IO密集型操作的耗时会直接叠加到单帧总耗时上，进一步放大帧率波动。

1. 底层使用更高效的捕获接口，跳过GDI层 #

• 优先采用Windows Graphics Capture (WGC)：这是Win10 1803及以上版本自带的官方捕获接口，也是当前主流录屏、直播软件的默认方案。它直接从DWM（桌面窗口管理器）的全局渲染队列中读取窗口的显存纹理，不需要触发目标窗口重绘，也完全不受窗口遮挡、最小化状态的影响，捕获过程在内核态完成，单帧耗时稳定在1~5ms，天生支持60fps以上的捕获需求。
• 对旧版本系统做兼容时，会采用渲染接口Hook+共享纹理的方案：Hook目标进程的Direct3D/OpenGL渲染接口，直接将窗口渲染的显存纹理放到共享内存区域，捕获进程只需要读取共享内存的纹理地址即可拿到帧数据，不需要做全量像素的跨进程拷贝，耗时同样非常稳定。

2. 全流程异步解耦 #

捕获、编码、写入三个环节拆分为独立线程运行，互不阻塞：

• 捕获线程仅负责拉取帧数据，拿到帧后直接写入线程安全的帧队列就返回执行下一帧捕获，不等待后续处理。
• 编码线程从队列中拉取帧，调用显卡硬件编码器（NVENC/AMF/QSV）完成视频编码，几乎不占用CPU资源，编码速度远高于60fps。
• 写入/推流线程仅负责将编码完成的帧写入磁盘或发送到网络，完全不影响前端的捕获速度。

3. 独立高精度帧率控制 #

捕获线程用系统高精度定时器QueryPerformanceCounter严格控制每帧的捕获间隔，哪怕偶尔出现系统波动导致的捕获超时，也会通过主动丢帧或补重复帧的方式保证最终输出视频的帧率稳定，不会出现耗时波动直接传递到输出视频的问题。

• 不要手写GDI捕获逻辑，直接使用封装了WGC接口的捕获库，例如mss的Windows后端，能直接拿到稳定的高帧率窗口帧。
• 将捕获逻辑和VideoWriter写入逻辑拆分为独立线程，通过队列传递帧数据，避免写入、编码操作阻塞捕获流程。
• 替换cv2默认的软件编码为硬件编码，例如使用PyNvCodec调用NVIDIA显卡的NVENC编码器，编码速度可以提升10倍以上。

内容的提问来源于stack exchange，提问作者dy.kim