下面是对我们产品的介绍。我们单台服务器可以支持 20-50 路的并发游戏数量，也就是单台服务器可以同时为 50 个玩家提供服务，单个并发用户的整体服务器硬件成本在500元左右，可以说是一个非常有竞争力的成本。当年 OnLive 失败的主要原因是因为他的硬件成本非常高，他的一台服务器仅能服务一个用户，单个并发用户的成本可能就要上万，在这样的成本水平上要实现商业上的成功是非常困难的。目前这个项目已经在小范围的内测，他们主要是 toB 的业务，为宽带运营商提供增值游戏服务。
云游戏的技术挑战
第一个是实时性
游戏的整体延迟包括了游戏逻辑运算时间、音画渲染的时间，加上编码的延时、网路传输的延时、客户端解码的延时、客户端向服务端发送控制信息的延时，云游戏的实时性要达到一个可令玩家接受的程度，这个技术挑战是非常高的，当然也要依靠硬件和网络本身的性能，如果没有足够的带宽也不可能做到。
第二是虚拟化技术
虚拟化在服务端已经非常成熟，我们有虚拟机技术以及各种容器技术，但是在桌面上就不是那么成熟，普通的虚拟桌面不支持 GPU 的虚拟化，而游戏非常依赖 GPU 渲染，若没有 GPU 的虚拟化就没办法实现云游戏了，所以虚拟化是一个很大的技术瓶颈。
第三是经济性
每个并发用户的服务器硬件成本关系到这个模式能否成功商业化，如果成本超出了用户可接受的范围，那就没有办法实现盈利。
最后是运维管理
云游戏的运维管理跟传统的服务器运维管理不一样，因为用到的服务器硬件不一样，同时硬件负载又很高，这对运维管理提出了新的挑战，所以在技术上就要解决这些问题。
平台选择
游戏的运行平台非常多，各种各样，但是比较适合的只有windows平台。Linux 平台虽然开放，但是它没有什么游戏支持，其他的主机游戏平台基本都属于封闭技术，微软和索尼自己都在研发主机上的云游戏，那我们是没有办法去做的。
android平台也是非常适合做云游戏。服务器跑个android游戏再传到android设备上这个概念看上去比较怪异，但实际上IPTV运营商非常喜欢这个概念，因为机顶盒不允许安装第三方的应用，监控比较严，那我们通过云端化来绕过这种限制，这对机顶盒这种产品非常有帮助，所以android平台也是我们要考虑的。但今天主要是介绍 windows 平台游戏的虚拟化，android上是用硬件方案跑的，所以就不介绍了。
windows游戏的虚拟化技术主要是两条路线。一个是虚拟机方案，但主要问题是 GPU 虚拟化技术不成熟，可能需要一些专业级的显卡支持，成本非常高、性能损耗非常大，每一个游戏都跑一个 Guest OS 非常浪费内存，所以这条方案就被我们否掉了。同时windows 上也缺少可用的容器级技术，我们只能采取 API Hook 方式手工实现虚拟化，我们称之为 Sandbox 方案。
Sandbox方案就是把游戏所用到的系统 API 全部hook接管，让游戏认为自己运行在一个正常的 OS 上面，但实际上是我们接管的一个 OS。这样做的好处是性能损耗很小，基本上没有额外的损耗，但是比较痛苦的要针对每个 API 做适配，需要对每个游戏进行适配，而且游戏通常不开源，游戏开发商通常也不会配合你去修改代码，需要一些 hack 技术来针对每个游戏做适配。
技术实现细节
图像和声音的采集
图形API有 DirectX 9,10,11,12还有OpenGL，接管这些API后我们就可以把画面重定向到视频编码器，不不在屏幕上输出了。音频比较简单，只要接管Windows Audio Session API就可以了。
输入操作的虚拟化
手柄比较麻烦，因为手柄支持的API接口比较多样化，比如 DirectInput, XInput, RawInput，还有些游戏直接读 USB 设备，实现这些API的接管工作是比较琐碎的。
存储的虚拟化分
一是游戏的资源部分，比如执行程序、图片、声音等等。这些资源文件都是只读的，需要一个共享存储来放这些文件，因为这些文件体积比较大，通常一个游戏需要几十个G的容量，如果全部都放在本地节点上的话，对节点的存储容量要求很大，而且以后更新维护起来也比较困难。所以我们用 NAS 来共享这些文件，这么做的网络 I/O 开销会非常大，后面我会介绍如何来优化这一块。第二是用户配置和存档数据等等可变数据，这些数据需要集中化存储，同时可能存在跨机房的访问需求。用户离机房越近延迟越小，所以需要多地、异地部署服务器，让玩家在全球漫游访问你的服务，这需要有跨机房文件共享的能力。
其他需要适配的内容
比如游戏一般都是单实例，我们需要绕过游戏的防多启动机制。还有些游戏无法后台窗口运行，我们需要通过 API Hook 的方式，让游戏认为它处于一个正常的状态。最理想的适配方式是通过 SDK，让 CP 来适配你的云游戏平台，但目前来说还不实际，因为云游戏的商业化还没有完全的落地，需要技术去慢慢的推进。
音视频编码技术
视频流采用的是 H.264 编码，主要是 720P/1080P@30fps，1080P@60fps 对网络和硬件的要求过高，暂时还做不到。音频编码使用AAC。因为标准的封装格式不含控制流，不能传输用户的操作数据，所以我们自己定义了一种封装格式，简单的把 H.264 和 AAC 的裸流封装起来传送给客户端。
目前用软件编码器基本不可行，一路视频编码就要消耗掉一个CPU核的资源，跑个三四路就把 CPU 资源吃光了，游戏就没办法运行了。幸运的是三大硬件厂商 Intel、AMD 和 NVIDIA 都推出了自己的硬件编码器，Intel的CPU自带硬件编码器，支持20+路的720P实时编码没有问题。NVIDIA 的硬件编码性能更高，可以直接对GPU的 FrameBuffer 做编码并传到 CPU 上，节省了很多内存的拷贝，性能是最好的。
视频编码的参数调优
首先避免使用 B 帧以减小延迟;较大的 GOP 设置来减少 I 帧的比例，保证每一帧消耗的码率都在一个最大可控的范围内;0 延迟设置，保证每输入一帧数据编码器都立刻输出这帧的编码数据，避免编码器缓冲帧数据;bitrate控制，使用固定比特率的算法是不适合的，因为游戏中经常会存在一段时间的静止画面，此时比特率很低，对接下来的变化帧编码器就会分配大量的比特来编码，这就会造成这一帧数据特别巨大，从而带来了额外的网络数据传输延迟。所以我们采用了自适应算法，在保证比特率总体在最大范围内的同时，保证每一帧消耗的码率都在一个最大可控的范围内，确保每帧的数据传输延迟可控。
终端的视频解码优化
H264 的解码是比较头疼的，因为android平台适配起来比较痛苦，尤其是它的硬件解码坑非常多。如果直接使用mediacodec封装的硬件解码器，那个延迟非常高，基本没有办法用。有一些芯片厂商会提供一个后门，让你把缓冲关掉直接输出画面，但是这需要对接具体的芯片厂商，无法做到通用，只适合一些机顶盒类的产品。所以还是需要用软件解码的方式来支持 0 延迟的输出。android设备的性能参差不齐，早期的低端芯片性能不满足实时解码 ，需要利用 GPU 做一些加速。
网络传输的优化
用UDP传输的话，因为H264 本身不支持容错，一旦丢包就会出现花屏，在下一个I帧到来前都无法恢复，通常要持续好几秒，严重影响用户体验，无法接受;而TCP 丢包的话只是出现几百毫秒的卡顿，实测还是可以接受的，所以我们放弃了 UDP 协议传输，利用TCP在网络层做一些调优使延迟降低。实测下来，现在的宽带网络延迟基本没有问题，主要问题反而是在用户侧的 WiFi 上，一旦出现无线信号干扰，网络抖动会比较厉害。
服务器和客户端的同步算法
我们的云游戏把所有环节的缓冲都关掉了，全部是零延迟自出，原来缓冲设计的目的就是为了抵抗颠簸，比如网络的颠簸、或某一个编解码环节出现了抖动，通过缓冲把这个抖动抹平，现在把缓冲都关掉后对同步会造成很大的影响。有很多因素会造成颠簸，比如服务器发送数据过快，客户端来不及消费，造成的结果就是延迟非常大。所以我们自己设计了一套算法来解决这个同步的问题。具体的做法就是让客户端在完成一帧画面的显示后向服务器反馈一个消息，服务端根据客户端反馈的消息就知道客户端消费到了第几帧，跟服务器现在编码的帧数做比较，在一定的阈值内就继续传输下一帧，否则等待客户端的确认消息，直到客户端赶上来。这样做的结果就是当颠簸发生时服务器能及时感知并停止发送数据，等颠簸消除后再继续发送最新的游戏画面，实测下来获得了比较理想的同步效果。
存储的优化。只读资源数据是放在 NAS 上的，几百个游戏共享一个 NAS，加载游戏时的网络 I/O 开销非常大，所以我们做了一个优化来本地缓存这些共享文件，利用dokan实现了一个虚拟磁盘来访问资源文件，再把虚拟磁盘重定向到NAS上，同时利用节点的本地 SSD 硬盘来缓存热点文件，从而降低了网络 I/O 的开销。
更多的云游戏玩法
旁观模式，一个玩家玩的时候其他玩家可以接入这个视频流，看他怎么玩;对战模式，其他玩家可以切到这个游戏流里面两个人在一起对战;还有直播模式，把视频流封装为 HLS，推送到 CDN 上进行直播，这是非常流行的主播模式，https://www.hkt4.com/云游戏都可以支持。
