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