Mr.*_*Boy 12 3d video-streaming
进行流式传输到客户端设备的远程渲染(通常用于视频游戏)的想法在概念上非常简单,除了明显的问题,例如交互式快节奏游戏的延迟.
但是 - 技术上你怎么能这样做？我的理解是,流媒体视频不仅会在当前播放位置之前缓存,而且视频文件会通过向前看多帧进行压缩？
是否有库可以让您将任意"显示源"提供给服务器端视频源,以便您可以使用常规Flash/HTML5组件在客户端上播放它？避免对自定义应用程序或定制浏览器插件的需求将是一个重要的好处...即客户端网页不知道它不是常规视频.
它有点像我认为的网络摄像头......但我希望"摄像头"能够"观察"在服务器上渲染的窗口的输出.
我的目标是基于Windows的服务器和C++渲染应用程序.
有趣的问题.有许多方面需要考虑,没有特别的顺序:
为渲染的电影选择容器格式非常重要.我认为主要限制是渲染器被限制为顺序写入文件.原因是文件需要流式传输到客户端,因此当渲染器正在写入文件时,将会有一个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游戏的风格)可能是这种类型的应用程序的良好折衷解决方案.