有没有人致力于将屏幕捕获到视频流（存储在本地文件或发送到网络）？
我了解它是如何完成的，并且有几个测试解决方案可以工作——但我们很难实现良好的性能。我们需要在 CPU 已经被大量使用的计算机上捕获大约 4 兆像素的不断变化的文本和矢量图形屏幕空间。
通过将未压缩的 BMP 帧发送到网络可以实现可接受的（尽管远非预期）性能，但由于许多原因，至少一些现场压缩很重要。
关于如何使用尽可能少的处理能力进行编码的任何建议：可能是一个非常快的编解码器？或者一些避免在内存中复制图像的技巧？使用 DirectX 捕获屏幕（大部分屏幕都在 WPF 中）值得吗？
好的……这是一个疯狂的猜测，因为我从未尝试过……但这似乎是合理的。我认为你应该使用 Nvidia CUDA。例如：
我在想你可以从图像（在内存中）创建纹理，然后再压缩它。在 CUDA SDK 中有一个DirectX Texture Compressor (DXTC) 示例：
使用 CUDA 的高质量 DXT 压缩。这个例子展示了如何在 GPU 上并行实现现有的计算密集型 CPU 压缩算法，并获得数量级的性能提升。
您可以在内存中存储多个纹理（取决于视频内存的数量）并将它们写入另一个线程上的磁盘/套接字。
这只是一个建议......我认为最好的方法是使用 CUDA 实现编码算法（参见TMPGEnc）将负载从 CPU 转移到 GPU，但这很棘手，需要大量工作。
我在搜索 CUDA 和屏幕截图时遇到了这个问题，并认为我应该添加我的经验。我过去使用 VNC 和 FFMPEG 创建了一个解决方案。如果您查看 VNC 协议，您会发现它基于具有新图像的增量窗口进行传输。基本上，上一个屏幕 + 更改 = 新屏幕。唯一需要传输的是更改。您会发现许多技巧来最小化传输成本和许多不同的有效负载扩展来传输数据，即使您决定利用所获得的知识自行开发，它也是一个很好的资源。一旦我们使用 VNC 移动像素数据，我们发现原始像素数据对我们的 cpu 来说比 jpeg 数据更昂贵，因为缓冲区副本比压缩更昂贵。
许多软件使用 xvidcap 或 camstudio 之类的图形界面来做到这一点，但 ffmpeg 可能对你有一个很好的解决方案......
对我来说，使用 ffmpeg+directshow 屏幕捕获设备+ huffyyuv 使用的 CPU 很少。但是大量的磁盘/带宽:)