Video streaming 使用3D引擎输出作为流式视频的输入

将远程渲染（通常用于视频游戏）流式传输到客户端设备的想法在概念上非常简单，除非存在明显的问题，如交互式快节奏游戏的延迟

但是，从技术上讲，你怎么能做到呢？我的理解是，流式视频不仅缓存在当前播放位置之前，而且视频文件通过向前看许多帧进行压缩

是否有库可以让您将任意“显示提要”馈送到服务器端视频源，以便您可以使用常规Flash/HTML5组件在客户端上播放它？避免使用自定义应用程序或定制浏览器插件将是一个显著的好处。。。i、 客户端网页不知道它不是一个普通的视频

我想这有点像网络摄像机。。。但我希望“摄影机”能够“监视”服务器上渲染到的窗口的输出

---

我的目标是基于Windows的服务器和C++渲染应用程序。有许多方面需要考虑，没有特别的顺序：

同时编码和流媒体 渲染电影的容器格式的选择非常重要。我认为主要的限制是渲染器必须按顺序写入文件。原因是需要将文件流式传输到客户端，因此在渲染器写入文件时，将有一个web服务器进程在与EOF可能很近的距离处读取该文件。渲染器无法使用随机访问来写入电影文件，因为磁盘上已有的任何数据都可能已发送到客户端，因此显然，写入磁盘的所有内容都必须是最终形式

F4V格式（Adobe FLV的继承者）似乎符合这一要求，因为它可以以流媒体友好的方式编写。这种格式受到客户端的广泛支持，您只需安装Flash player插件即可。对于iPhone/iPad，您需要另一种不涉及Flash的替代方案，因此对于iOS，您可以使用MP4。请注意，F4V源于MP4，两者极为相似

当然，服务器上运行的3D引擎必须能够渲染到F4V/MP4，这可能需要为引擎提供自定义导出插件

演出 服务器必须能够以与预期播放帧速率相同或更快的速度渲染和编码帧。硬件加速是你的朋友

延迟 高效的视频编码格式只对帧之间的差异进行编码，因此要解码任何给定帧，可能需要先解码一些其他帧。现代编码格式最有趣的一个方面是，它们不仅编码过去帧的差异，而且编码未来帧的差异。这明显增加了延迟，因为编码器需要延迟编码一个帧，直到收到更多的帧。似乎为了减少延迟，您需要将编码的“未来”端限制在非常短的数量，从而可能降低编码效率和/或质量

客户端缓冲 如果您想避免使用自定义播放插件，这可能是一个困难的问题。视频播放器将流下载到缓冲区，缓冲区通常长达几秒钟，只有在缓冲区已满时才开始播放。这里的想法是，一个完整的缓冲区有助于抵御任何网络中断和减速。但不幸的是，大缓冲区意味着延迟的增加。您需要了解客户端播放器希望在其播放缓冲区中保留多少秒的材质，这将决定服务器端渲染/编码过程始终需要提前多少秒。自定义播放插件可以减少或消除缓冲区以减少延迟，但它对网络故障更加敏感

HTTP服务器支持 我不确定HTTP服务器在另一个进程生成文件时会如何流式处理该文件。我怀疑这不是常规服务器测试或打算支持的。FTP有一个不太为人所知的扩展名为“尾部模式FTP”，它基本上使用了您想要的行为。启用尾部模式的FTP服务器知道文件正在增长，因此它不假设大小，只传输文件中显示的字节。如果发现文件消耗速度过快并达到EOF，服务器甚至会等待文件增长。您可能需要一个支持类似功能的自定义HTTP服务器

在这里，专用流媒体服务器可能是一个不错的选择。感兴趣的链接是开源和流媒体应用程序。在Adobe方面，有一种商业产品。还有微软的另一个选择，IIS的服务器扩展

互动性

---

你没有提到这一点，但我认为这项技术的良好应用将允许客户端将输入事件发送回服务器，然后服务器将使用该事件影响电影的内容。这实际上是一个完全托管在服务器上的游戏引擎，只有输入和显示组件在客户端上运行。再一次，这将是一个挑战，因为要使应用程序感到响应的延迟足够低。此外，您现在必须对每个客户端的流进行编码，因为每个客户端将看到不同版本的电影。这里有很多问题，根据需要支持的同时客户端的数量，可能需要渲染/编码场。对于这种类型的应用程序，预先渲染和预先编码的动画块可以组合（以旧游戏的风格）可能是一个很好的折衷解决方案。

在软件中可能没有有效的解决方案。。。但硬件方面可能存在以下问题：

应该可以以更低的成本将该设备使用的H.264编码器与视频卡结合起来。

流编码视频 方法 我在做一个比喻