有没有人致力于捕获屏幕到视频流(存储在本地文件中或发送到网络)?
我理解如何做到这一点,并有几个测试解决方案工作-但我们很难实现像样的性能。在CPU使用率已经很高的计算机上,我们需要捕获大约400万像素的变化文本和矢量图形的屏幕空间。
通过将未压缩的BMP帧发送到网络来实现可接受的(尽管远非所需的)性能,但是出于许多原因,至少在现场进行一些压缩是重要的。
对如何使用尽可能少的处理能力进行编码有什么建议:可能是一个非常快的编解码器?或者避免在内存中复制图像的一些技巧?用DirectX (大部分屏幕都是用WPF)来抓取屏幕值得吗?
发布于 2009-09-01 12:00:07
好的..。这是一个大胆的猜测,因为我从来没有尝试过。但这似乎是有道理的。我认为你应该使用Nvidia CUDA。例如:
我在想,你可以从图像(在内存中)创建纹理,然后压缩它。在CUDA SDK中有一个sample for DirectX Texture Compressor (DXTC):
高质量DXT压缩使用CUDA.此示例展示了如何在GPU上并行实现现有的计算密集型CPU压缩算法,并获得数量级的性能提升。
您可以在内存中存储多个纹理(取决于视频内存的大小),并将它们写入另一个线程上的磁盘/套接字。
这只是一个建议。我认为最好的方法是使用CUDA实现一个编码算法(参见TMPGEnc),将负载从中央处理器转移到图形处理器,但这是棘手的,需要大量的工作。
发布于 2010-02-28 14:20:55
我只是在搜索CUDA和屏幕截图时遇到了这个问题,我想我应该添加我的经验。我在过去使用VNC和FFMPEG创建了一个解决方案。如果你看一看VNC协议,你会发现它的传输是基于增量窗口和一个新的镜像。基本上,前一个屏幕+更改=新屏幕。唯一需要传输的就是更改。你会发现许多技巧来最小化传输成本和许多不同的有效载荷扩展来传输数据,这是一个很好的资源,即使你决定使用自己获得的知识。一旦我们使用VNC来移动像素数据,我们发现对于我们的cpu来说,原始像素数据比jpeg数据更昂贵,因为缓冲拷贝比压缩更昂贵。
发布于 2009-09-01 08:18:12
许多软件都是通过xvidcap或camstudio这样的图形界面来做到这一点的,但是ffmpeg可能是一个很好的解决方案……
https://stackoverflow.com/questions/1361187
复制相似问题