对客户端设备进行远程渲染（通常用于视频游戏）的想法在概念上非常简单，除了交互式快节奏游戏的滞后等明显问题。
但是 - 技术上你怎么能这样做？我的理解是，流媒体视频不仅会在当前播放位置之前进行缓存，而是通过向前看多帧来压缩视频文件？
是否有库可以让您将任意“显示源”提供给服务器端视频源，以便您可以使用常规Flash / HTML5组件在客户端上播放它？避免使用自定义应用程序或定制浏览器插件将是一个重要的好处...即客户端网页不知道它不是常规视频。
我觉得它有点像网络摄像头......但我希望'相机'能够“观察”服务器上渲染的窗口的输出。
我的目标是基于Windows的服务器和C ++渲染应用。
答案 0 :(得分：7)
有趣的问题。有许多方面需要考虑，没有特别的顺序：
渲染影片的容器格式选择非常重要。我认为主要限制是渲染器被限制为顺序写入文件。原因是文件需要流式传输到客户端，因此当渲染器正在写入文件时，将会有一个Web服务器进程在距离EOF可能很近的距离处读取它。渲染器无法使用随机访问来编写影片文件，因为磁盘上已有的任何数据可能已经发送到客户端，所以写入磁盘的所有内容都必须是最终形式。
似乎F4V格式（来自Adobe的FLV的继承者）符合要求，因为它可以以流媒体友好的方式编写。这种格式得到了客户的广泛支持，您只需要安装Flash播放器插件即可。对于iPhone / iPad，您将需要另一种不涉及Flash的替代方案，因此对于iOS，您可以使用MP4。请注意，F4V来自MP4，两者都非常相似。
当然，在服务器上运行的3D引擎必须能够渲染到F4V / MP4，这可能需要为您的引擎提供自定义导出插件。
您的服务器必须能够以与预期播放帧速率相同或更快的速度渲染和编码帧。硬件加速是你的朋友。
高效的视频编码格式仅通过编码帧之间的差异来工作，因此要解码任何给定的帧，您可能需要首先解码其他帧。现代编码格式最有趣的一个方面是它们不仅编码过去帧的差异，还编码未来帧的差异。这显然会增加延迟，因为编码器需要推迟编码帧直到它再接收几帧。似乎为了减少延迟，您需要将编码的“未来”限制到非常短的数量，从而可能降低编码效率和/或质量。
如果您想避免使用自定义播放插件，这可能很难。视频播放器将流下载到通常为几秒钟的缓冲区，并且仅在缓冲区已满时才开始播放。这里的想法是一个完整的缓冲区可以帮助解决任何网络中断和减速问题。但不幸的是，大缓冲区意味着延迟增加。您需要了解客户端播放器在其播放缓冲区中需要多少秒的素材，这将决定服务器端渲染/编码过程总是需要多长时间。自定义播放插件可以减少或消除缓冲区以减少延迟，但随后它会对网络打嗝更敏感。
我不确定HTTP服务器如何流式传输文件，因为它是由另一个进程生成的。我怀疑这不是常规服务器测试或打算支持的东西。有一个称为“尾部模式FTP”的FTP的非常广为人知的扩展，它基本上使用了你想要的行为。启用尾部模式的FTP服务器知道文件正在增长，因此它不会假设大小，只是传输文件中出现的字节。如果文件发现它过快地消耗文件并达到EOF，服务器甚至会等待文件增长。您可能需要支持类似功能的自定义HTTP服务器。
专用的流媒体服务器可能是一个不错的选择。感兴趣的链接是开源Darwin Streaming Server和QuickTime Broadcaster流媒体应用程序。对于Adobe方面而言，Adobe Streaming Server是商业产品。而另一个选择来自Microsoft，IIS的Smooth Streaming服务器扩展。
你没有对此有任何说法，但我认为这项技术的良好应用将允许客户端将输入事件发送回服务器，服务器将使用它来影响电影的内容。这实际上是一个完全托管在服务器上的游戏引擎，只有客户端上运行的输入和显示组件。再一次，对于应用程序感觉响应的足够低的延迟，这将是一项挑战。此外，您现在将不得不对每个客户端流进行编码，因为每个客户端将看到不同版本的电影。这里有很多问题，可能需要渲染/编码服务器场，具体取决于需要支持的并发客户端数量。预先渲染和预编码的动画块可以组合（采用旧Dragon's Lair游戏的风格）可能是此类应用程序的一个很好的折衷解决方案。
答案 1 :(得分：1)
在软件中可能没有一个有效的解决方案来解决这个问题......但可能存在于硬件中：http://yhst-128017942510954.stores.yahoo.net/cube200-1ch-hdmi-enc2001.html
应该可以将该设备使用的H.264编码器与视频卡相结合，成本更低。
答案 2 :(得分：1)
我正在研究类似的问题，我将分享我所学到的知识。虽然我不知道如何将它们流出来，但我知道如何在服务器上生成和编码多个高清视频流。我测试了两种方法：NVIDIA CUDA Video Encode (C Library) API和In tel Performance Primitives Video Encoder。 NVIDIA链接将您带到示例中。英特尔页面没有内部锚点，因此您必须搜索“视频编码器”。
两者都将视频流编码为H.264，最高可达HD。支持其他格式，但我对H.264感兴趣。为了测试性能，我设置了YUV格式的准备好的输入视频，并尽可能快地将它送到编码器。两个编码器的输出均为1080P。
性能方面，英特尔视频编码器可以0.5X实时编码单个流，在Xeon E5520 @ 2.27GHz上负载约12.5％，即100％负载下的八个核心。较新的Xeons速度要快得多，但我不知道它们是否可以实时播放。
GTS 450上的NVIDIA编码器可以编码9-10倍的实时1080P（！），CPU负载为50％。 NVIDIA上的CPU负载似乎主要是将数据复制到GPU和来自GPU。
GPU解决方案的特别之处在于它可以将GPU渲染表面作为输入;图形在GPU上生成和编码，只留下去网络。有关使用渲染表面和输入的详细信息，请参阅CUDA by Example，这是一本关于GPU编程的优秀且直截了当的书。在那种情况下，我希望CPU负载下降大约一半。由于实时图形比实时更快没有意义，因此您可能使用足够的GPU资源从渲染表面编码8+个流，例如：两张GTS 450卡，如果分辨率低于1080P，可能会更多。