第一种是实时性
游戏的整体延迟包括游戏的逻辑操作时间、声音和图片的呈现时间，以及编码、网络传输、客户端解码和客户端向服务器发送控制信息的延迟。云游戏的实时性能应该达到玩家可以接受的水平。这个技术挑战是对的，也是错的。当然，很高的带宽也取决于硬件和网络本身的性能，如果没有足够的带宽就无法实现。
其次是虚拟化技术
虚拟化在服务器端非常成熟。我们有虚拟机技术和各种容器技术，但在桌面上还不成熟。普通的虚拟桌面不支持gpu虚拟化，而游戏在很大程度上依赖于gpu渲染。没有gpu虚拟化，云游戏无法实现，虚拟化是一个很大的技术瓶颈。
第三，经济性
每个并发用户的服务器硬件成本与模型能否成功商业化有关。如果成本超出用户可接受的范围，就无法实现盈利。
最后，运维管理
云游戏运维管理不同于传统的服务器运维管理，因为使用的服务器硬件不同，硬件负载也很高，给运维管理带来了新的挑战，因此有必要对云游戏运维管理进行改进。从技术上解决这些问题。
平台选择
游戏有很多不同的平台，但只有windows平台更适合。尽管linux平台是开放的，但它没有任何游戏支持。其他主机游戏平台基本上都是封闭技术。微软和索尼都在自己的主机上开发云游戏，所以我们不能这么做。
Android平台也非常适合云游戏。服务器运行android游戏然后将其传输到android设备的概念似乎很奇怪，但事实上iptv运营商非常喜欢这个概念，因为机顶盒不允许安装第三方应用程序，而且监控也很严格，所以我们可以绕过这个限制。通过云计算，这对机顶盒非常有帮助。帮助，所以Android平台也是我们需要考虑的。但今天我们主要介绍windows平台游戏的虚拟化。android使用硬件解决方案，所以我们不介绍它。
windows游戏的虚拟化主要有两种途径。一是虚拟机方案，但主要问题是gpu虚拟化技术还不成熟，可能需要一些专业的显卡支持。成本很高，性能损失很大。每个游戏都运行一个非常浪费内存的来宾操作系统。所以我们拒绝了这个计划。同时，windows上缺乏可用的容器级技术。我们只能使用api钩子手动实现虚拟化。我们称之为沙箱计划。
沙盒解决方案是挂接游戏中使用的所有系统api，让游戏认为它在正常操作系统上运行，但实际上它是我们接管的操作系统。这样做的好处是性能损失很小，基本上没有额外的损失，但是适应每一个api越痛苦，需要适应每一个游戏，而且游戏通常不是开源的，游戏开发者通常不配合你修改代码，需要一些黑客技术。为每一个游戏做逻辑。适应。
技术实施细则
图像和声音采集
图形api包括directx 9、10、11、12和opengl。接管这些api之后，我们可以将图片重定向到视频编码器，并将其输出到屏幕上。音频相对简单，只需接管windows音频会话api。
输入操作的虚拟化
句柄更麻烦，因为句柄支持的api接口更加多样化，例如directinput、xinput、rawinput，还有一些游戏直接读取usb设备。实现这些api的接管很简单。
存储虚拟化
一是游戏的资源部分，如执行程序、图片、声音等。这些资源文件都是只读的，需要共享存储来存放这些文件，因为这些文件比较大，通常一个游戏需要几十个G的容量，如果全部放在本地节点上，节点的存储容量非常大，后期更新和维护很困难。所以我们使用NAS来共享这些文件。网络I/O开销将非常高。稍后我将演示如何优化此部分。第二种是可变数据，如用户配置和存档数据，这些数据需要集中存储，并且可能在整个计算机室都有访问要求。用户离机房越近，延迟越小。因此，有必要在不同的地方部署服务器，以允许玩家在世界各地漫游以访问您的服务。这就要求能够在整个机房共享文件。
其他需要改编的内容
例如，游戏通常是单实例的，我们需要绕过游戏的多启动机制。有些游戏不能在后台窗口运行。我们需要使用api钩子使游戏认为它处于正常状态。最好的适应方式是通过sdk，让cp来适应你的云游戏平台，但目前还不实用，因为云游戏的商业化还没有完全落地，需要技术来放缓。
音视频编码技术
视频流采用H.264编码，主要是720p/1080p@30fps。1080p@60fps对网络和硬件的要求太高，暂时做不到。aac用于音频编码。由于标准的封装格式不包含控制流，不能传输用户的操作数据，我们定义了一种封装格式，它简单地封装了H.264和AAC的裸流，并将其传输到客户端。
目前，使用软件编码器基本上是不可行的。视频编码将消耗CPU核心资源。如果你运行三到四条路径，你将耗尽CPU资源，游戏将无法运行。幸运的是，英特尔、amd和nvidia都推出了自己的硬件编码器。英特尔的CPU有自己的硬件编码器，支持20+通道的实时720p编码。nvidia的硬件编码性能更高。它可以直接编码gpu的帧缓冲区并将其传输到cpu。它节省了大量的内存拷贝，性能最好。
视频编码的参数整定
首先，避免使用b帧来减少延迟；大gop设置来减少i帧的比例，以确保每个帧消耗的比特率在最大可控范围内；0延迟设置来确保每个输入帧编码器立即输出该fr的编码数据。AME，避免了编码器缓冲帧数据；固定比特率算法不适合，因为游戏中经常有一段时间静态画面，当比特率很低时，大量的比特会被分配到下一个帧编码器的变化中进行编码，这会导致该帧数据的丢失。ata特别巨大，导致额外的网络数据传输延迟。因此，我们采用自适应算法，在保证每帧所消耗的比特率在最大可控范围内的同时，保证每帧的数据传输延迟在最大可控范围内。
终端视频解码优化
H 264解码是一个让人头疼的问题，因为Android平台的适应性更为痛苦，尤其是它的硬件解码坑非常多。如果直接使用mediacodec中封装的硬件解码器，则延迟非常高，几乎没有用处。一些芯片厂商会提供后门让你关闭缓冲区，直接输出图片，但这需要对接特定的芯片厂商，这不能通用，只适合一些机顶盒产品。因此，仍然需要软件解码来支持零延迟输出。android设备性能参差不齐，早期低端芯片的性能不满足于实时解码。GPU需要做一些加速。
