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