OBS框架流程和源码分析七一视频流捕获机制

所谓视频流，实际上是由一张张图像组成，由于人体眼睛的捕获频率，以及视觉暂留机制，在图像连续播放时，会让大脑以为产生连贯性的动画效果。常见的电影帧率是24帧/秒（24fps），而游戏一般要到60fps（高清）才不会觉得明显卡顿（这个讨论见https://www.zhihu.com/question/21081976/answer/34748080）。也就是，对于电影或者一般游戏而言，按照某个帧率播放，只要按照这个帧率捕获数据，基本可以采集到每一帧完整的数据。 再来一个直观的感受：

为了取得窗口图像帧，首先得清楚窗口图像帧原理。

大概的原理： Windows为了提升显示性能，图形相关的操作，都在内核层（win32k.sys），在这里，设计上有两条线：

应用层使用的基本方式，就是创建消息循环，创建窗口及绑定窗口过程函数，通过消息循环派发消息事件给过程函数，去执行不同动作。渲染线最后是通过WM_PAINT消息驱动，去刷新每个窗口自身的显示区，最终触发屏幕对应的FrontBuffer数据展示。这里的每个窗口自身的显示区，windows中用DC来关联，每一个窗口都有一个DC以及一段buffer，实际的操作，都是通过DC来处理这段buffer。我们可以通过DC来获取到窗口内的数据。

窗口管理器负责管理了各个窗口的显示资源buffer地址，应用程序的渲染过程负责对窗口显示buffer资源进行修改。那么获取图像帧，只需要拿到最终修改完成的buffer即可，可通过DC操作来拿。

核心是创建内存兼容DC，关联一个bitmap资源，然后BitBlt调用可以从显存dc拷贝到内存兼容dc，因为内存兼容dc与bitmap关联，数据就都到bitmap中去了，直接进行存储即可。

被测试对象：

测试窗口代码如下：

被测试对象：

dx9

整个截图围绕着DC来操作，让我不禁思考，DC到底是什么？我们可以通过GetWindowDC以及GetDC获取窗口的两种不同设备上下文，但是当我对这个API重复调用时，发现返回的对象并不一样，如下调试结果： 为啥返回值不一样？难道DC不是窗口的一个固定的数据缓存么？

这里微软给出来解释：https://docs.microsoft.com/en-us/windows/win32/gdi/display-device-contexts 本质上，DC是一个系统内存中的结构体，这个结构体中，包含有：绘图所用的对象集合（例如：画笔pen、画刷brush、位图bitmap、调色板palette、字体font等）以及相关属性的集合，而显示位图bitmap信息，就是窗口的显示数据信息。

DC也分为好多类别，我们这里的DC指的是Display DC，而Display DC也分为好几类：

这其中，Private DC对窗口DC中绘图对象的修改，会直接修改到模板，下一次GetDC时，会拿修改后的模板值填充新DC，直到窗口销毁（即使被主动ReleaseDC，修改也不会消失）；而其他的DC，在Get到之后，通过SelectObject修改DC中的绘图对象，当ReleaseDC时，所有的修改都会丢弃，下一次GetDC依旧使用默认值填充绘图对象。

简单测试一下，使用CS_OWNDC之后的效果如下： 这里会发现，Private DC只作用于客户区DC，对于非客户区DC，不起作用。

为啥连续调用返回值不一样呢？这里就解释了，因为每次都是新生成一个DC资源，然后从老资源中拷贝到新资源中来，只不过Private DC有点特殊。微软还解释了，DC资源是非常宝贵的资源，系统内是有限的，如果我们存在DC泄漏，很可能造成系统GDI绘图异常，也就是导致系统内其他绘图程序下一次调用GetDC会失败。那既然DC是存在于内存中的，为啥数量还要设限制呢？

另外，在分析DX时，发现DX的surface接口中有个GetDC接口，是一个有限使用的功能接口，为了可以供GDI函数相互作用。那么，是否可以理解为，DX底层和GDI底层，都关联DC，DC也都关联窗口整个显示区，所以无论是DX窗口还是GDI窗口，都能通过DC去操作。这里又有个问题，DC在内存中，到底是显存映射的内存，还是非显存映射的系统内存？既然系统要限制使用数量，而且DX的Surface接口还与之关联（测试所使用的surface对象在显存中），并且通过DC截图可以捕获到无论是GDI渲染还是DX渲染的数据内容，那么是否可以理解成DC本质就是存储在显存中，只不过被映射到了系统内存（如果不是，那么我们能通过窗口的DC捕获到，只能说明，DX绘制的时候，会在系统内存拷贝一份镜像，而我们每次通过窗口DC去获取数据，都是从这个镜像中获取的，但是很明显，DX没有这么做，因为我们在渲染三角形时，使用了D3DPOOL_DEFAULT，它的资源只会放置在显存中，不会在系统内存中镜像一份。）

由此分析，得出的结论是，我们在GetDC时，应该是在系统内存中，映射出窗口的显存buffer，当我们使用BitBlt，应该是从映射内存拷贝输出到系统内存。

从上述GDI窗口的捕获结果，以及DX应用窗口的捕获结果来看，关联窗口的DC是整个窗口渲染的最终过程，也就是说，无论使用DX引擎如何渲染，最终展示效果，都是可以通过DC来捕获，那么GDI和DX他们的关系，应该是如下：

显示器显示一张图，原始尺寸大小，可以这么计算：分辨率颜色位。颜色位现在一般是32位（再高就没有太大意义，人眼无法分辨），这样计算的话，如果分辨率在1366768，那么一张图的大小将是：136676832/8=4MB，也就是，一张全屏的图片，没有任何压缩，就需要4MB存储空间，甚至包括一些比屏幕更大的窗口，占用空间就更大了，比如高清屏33602100分辨率，全屏窗口将占用空间：33602100*32/8=26.9MB，这个数据量还是相当大的，如果同时监控2个这样的窗口，就到达50MB。

无论是DX渲染的窗口，还是GDI渲染的窗口，最终输出的显示缓存，都可以由DC来获取。而获取的方式，主要是调用BitBlt来将显示数据不断拷贝到创建的内存。根据内存占用分析，每次BitBlt要拷贝这么大数据量，考虑效率的话，如果窗口展示的动画，显示很快(60fps)，以上述高清屏为例（26.9MB），那么相当于1s需要拷贝26.9*60=1614MB，已经1.5GB的数据量了。那么，再考虑BitBlt传输速率，我们就可以得到一个拷贝帧数极限数值。

遗留问题：BitBlt的性能测试

BitBlt本质是将显示数据，从显存拷贝到内存。这里占用的系统资源，除了前面分析的存储空间之外，还有显存到内存到传输带宽。硬件连接上，显存是作为外设，介入到CPU系统中，一般通过PCIe总线连接。CPU如果想让内存和显存进行通信，所采用到机制，是MMIO，即内存映射IO，也就是将显存映射为系统的一段内存，进而CPU就可以操作显存资源了。但本质上，硬件连接还是分离的，数据拷贝操作，还得通过类似DMA直接存储机制，这里拷贝数据，还占用了这个带宽。当拷贝占用带宽导致PCIe总线忙时，也会影响其他渲染操作。

此外，BitBlt拷贝数据，还需要考虑是否有锁的问题，因为它是针对目标窗口的图像帧拷贝数据，而针对DC的操作，是否带锁？如果不带锁，对DC的操作则必须是单线程，否则容易导致数据混乱，多进程操作时，本质就是多线程在操作DC资源；如果带锁，那么只要使用它，应该就会对捕获目标造成影响。猜测的话，因为这个东西最终是需要占用PCIe总线的，至少在总线这里是独占的，可以理解为有锁，GDI操作自身是否有锁，这个有待逆向分析。

遗留问题：BitBlt逆向分析是否有锁？？

由于我们是从进程外去拷贝窗口图像帧数据，所以是无法区分dirty空间大小，也就无法区分具体每次拷贝的大小，而每次都拷贝完整的全屏数据，这里很明显存在可以优化的空间。如果利用窗口捕获方式，可以注入到目标进程，在渲染时，获取到脏数据的位置，来拿到增量渲染数据，这样可以在采集时，降低DMA带宽的使用量。

由于我们在进程外获取窗口数据帧，我们实际上是不知道渲染何时触发，例如静态的窗口，可能一只不渲染，但是我们是很难区分开的，所以为了采集窗口数据帧，我们需要做的，是定时去做窗口数据采样。这样导致的问题，就是可能采样到一堆无用数据，对于我们无论是存储，还是网络传输，都是不利的（当然，对于网络传输，我们也可以分析图像差异来计算是否重复，但是这样只会导致消耗更多计算性能）。

如果我们注入到系统进程内，通过Hook绘制操作，那么便可以尽可能减少这种无效数据。

对于直播而言，游戏是一个重要分支，对于游戏自身而言，都是为了尽可能争取到高性能的渲染，而基本上采用DirectX、OpenGL、VulKan等与显卡紧密结合的渲染SDK进行游戏画面的渲染，游戏的帧率，也普遍非常之高。高清高速高性能的追求，对于数据采集而言，本就是一个挑战，如果采样前述的窗口捕获的方式，对于DMA带宽占用，本身就会影响当下游戏性能，而且游戏帧率随着场景变化，对于我们设置的采样间隔，会造成极大的浪费。所以，游戏这种捕获，OBS采用了独立功能和产品模块来实现捕获，以获取最佳性能。

为了能掌控渲染帧数的变化，实时获取图像帧数据，基本方式是：注入 + 绘制函数Hook。

首先，不考虑注入，直接在测试窗口进程中，模拟注入场景，测试DX是如何捕获图像帧。

关键流程：

关键流程：

关键流程：

关键流程，同DX10

DX12是DX11的进阶版，完全适应现代GPU架构。其关键流程，也是继承了DX11，捕获技术，基本是利用了11On12技术。

关键流程：

参考文章： https://www.notion.so/willarun365/OBS-814f392623c0446fabacbe8deea02a61