Photo by Sean Do on Unsplash
本次演讲主要内容将包括云游戏整体方案的架构介绍、使用开Open WebRTC ToolKit (OWT)实现流和控制命令的传输，以及为实现云游戏所需的超低延迟所做的优化。
文 / 诸剑俊
整理 / LiveVideoStack
大家好，我是来自英特尔的诸剑俊，我们组主要从事有关于WebRTC的研发，并且有一个基于WebRTC的开源项目OpenWebRTC Toolkit (https://github.com/open-webrtc-toolkit)，这次演讲的主题是基于英特尔平台和WebRTC技术的云游戏解决方案。
首先介绍一下云游戏，云游戏对于一些人来说已经比较熟悉了，这个概念不是特别新，最初叫作云游戏或者远程游戏，但由于以前的网络没有现在发达，而且带宽也没现在好。随着接入带宽的增加，再加上5G的建设，云游戏近几年又流行起来了。然后我会对我们的技术方案和碰到的挑战进行讲解，以及英特尔对此所做的一些优化，也会在此与大家分享。
1. 云游戏概述
1.1 云游戏介绍
关于云游戏，它的游戏是跑的服务器上的，所以运算都是在服务器上做的，客户端其实只是收了服务端发来的一个图像或者指令，最后在客户端上呈现出来以服务用户。所以云游戏涉及两个要素：一是在服务器上操作，二是在客户端上观看。
1.2 云游戏的参与方
云游戏的产业主要有以上几个参与方，前三个相当于业界的一些提供方。第一个是云服务提供商，它主要是作为基础架构的提供方，因为搭建云游戏需要有一个较好的基础架构。
1.2.1 云服务提供商
云服务提供商在国内比如有阿里云、腾讯云，以及国外的微软公司等。由于游戏对场景有一些硬件的需求，云服务提供商可以提供以下服务：首先它拥有比较高的图像的处理能力；其次因为游戏对画面质量的要求比较高，所以需要有比较好的QoS去控制基础架构；再次整合CDN解决方案提供直播等功能；最后云游戏可能是云服务下一个利润增长点。
1.2.2 游戏服务提供商
游戏服务提供商，与游戏开发者不同，它提供的是游戏服务、游戏平台。
如果游戏跑在云端，就比较容易进行反作弊操作，因为客户端获取不了内存里的数据，所以没办法修改数据或者做像地图全开这种效果。但反作弊操作也会带来一个问题，那就是游戏做了反作弊后，不改游戏而是去直接提供云游戏，这在目前其实是做不到的，因为游戏内部一般会防止云游戏的应用程序去获取数据。
其次，游戏的服务提供商可以更方便地对游戏进行更新和升级，因为传统的游戏方案一旦升级就需要用户进行下载和安装。但是如果采用云游戏这种方案，服务端一旦更新完毕，用户就可以直接进行游戏。
最后，云游戏可以针对云游戏机房和游戏后端服务器机房间链路进行优化。因为云游戏跑在云端，游戏跑在服务器上，游戏后端的服务器也是在一个数据中心，由于在云游戏的机房和游戏后端的机房的链路比较固定，所以可以做一些优化，把云游戏的机房和游戏服务部署在同一个机房里面，这样延迟反而会更低。
1.2.3 游戏开发商
对于传统的游戏开发者来说，云游戏提供给游戏开发者一个比较好的平台，让它可以更关注对游戏本身做一些优化，对内容进行提升，以减少兼容性问题；其次云游戏跑在云上，云上的设备有固定的配置，所以可以对特定的平台做一些优化。
1.3 云游戏的质量要求
关于云游戏在质量要求的方面，如果想提供给用户玩家一个较好的游戏体验，有几点会影响到用户的体验。
第一是延迟，这是大家比较关心的，关于延迟，我们基本上调研了一下对于不同类型的游戏，它会有不同的延迟要求。FPS游戏要求比较高，如果超过100ms，大家可能就会受不了。另外，RPG游戏在500ms左右，即时战略游戏在1000ms，即一秒，还是能够接受的。
第二是视频质量，因为对云游戏玩家来说，不想在本地跑太强大的机子，以减少不必要的投入，所以云游戏要做到让玩家在不太好的机子上体验一个比较好的效果。其中一种衡量视频质量的参数是PSNR，一般来说PSNR值在30以上，视频质量会比较好，但是高于25的话也是可以接受的，这个取决于客户订阅的服务等级以及客户端的网络配置情况。
第三是刷新率，现在的大部分显示器的刷新率在60左右，最近发现有一些玩家特别是一些比较专业的游戏玩家，要求刷新率为144，因为现在一些新的硬件刷新率都已经支持到144了，而且用户觉得在144和60之间是能观察到一些差距的。
第四分辨率，现在的分辨率基本上都在1080p以上，但是对4K的要求目前还不高。我们收到的一些反馈是玩家会更关心刷新率，而不是把分辨率无限地往上升。
最后是带宽，带宽用的越少，成本就越低，所以要求带宽越低越好。
2. 现状和挑战
现阶段的一些挑战，大部分情况下主要是网络带来的一些挑战。首先云游戏带宽的使用确实有点高，音视频通话在几兆带宽的情况下，可以达到比较好的效果，但是云游戏基本上要在16Mbps以上的带宽才会呈现出比较好的效果。
其次，玩家在不同的设备上，比如iPad、手机或笔记本，连了一个WiFi网络或者4G的网络，但当网络不稳定时，整个网络参数就会全部变掉，所以这也是需要解决的一个问题。
最后是高质量和低延迟之间的平衡，因为想提供高质量的游戏效果，带宽的使用就会增加，对于服务器的性能要求也就更高，若要尽快地把服务端的图像发送到客户端，就需要在低延时与高质量之间做权衡。
2.1 实现模式
关于实现模式，目前来说采取两种方案。一种是服务端进行一些游戏上的处理，再把渲染的指令发到客户端，由客户端来进行渲染。这样的好处是渲染指令的数据量会比较小，发到客户端以后对带宽的要求会比较低，但缺点是如果是一个高质量的游戏，它的渲染指令对计算机的要求会比较高，那么对于用户来说，还是需要买一块好的显卡的。
另外一种方案是传输图像，服务端将一切准备好，游戏在服务端可以进行操作，再通过一定的方法把图像获取出来，然后发到客户端。这样发送的是一个视频流。这种方式的好处是客户端不需要太强大的CPU、显卡之类的投入，但是对带宽的要求比较高。
2.1.1 整体架构
这部分是目前我们实现云游戏解决方案里的一个高层面整体架构图，它包含了几个模块。一是捕获和编码模块，它的作用是从游戏里去获取音频、视频以及指针信息，再把音频和视频进行编码，然后把编码好的数据帧发送到传输层。
WebRTC实时音视频和数据传输为云游戏提供了很好的技术支撑，用户不用下载任何插件，在浏览器里就可以玩高端游戏，所以用WebRTC进行视频和音频的传输。传输层会把音视和视频的数据发到客户端，客户端再进行解码和播放。因为玩游戏，用户是有输入的，所以客户端还需要采集用户的鼠标、键盘、手柄等信息，这些信息通过WebRTC的data channel，发到服务器上的WebRTC的传输层，然后传输层会把指令拆出后再传到事件的重播模块，重播模块相当于把用户在客户端的指令重新应用到游戏里面去。
2.1.2 硬件方案
接下来为大家介绍一下英特尔目前的硬件方案，因为要在机房里面部署云游戏需要一些硬件，名字是叫PCFarm，它的思路是在有限的空间、有限的机房和机柜下，提供更大、更多的处理能力，可以将多达144个高性能的PC放在一个两米的标准机柜里面，并且提供多种用户的输入接口。
2.1.3 模块图
这张图是一个软件层面的模块图，从图中右下角开始，它相当于是用户的一个游戏，当有一些视频、音频需要呈现出来时，在Render模块有两种方案去获取游戏中的数据。一种方案是抓屏，通过抓整个显示器屏或者抓游戏所在区的屏。另一种方案是截取游戏的绘图指令。对绘图函数进行挂钩(hook)，当游戏有内容需要呈现的时，那么数据的输出直接就接到输入的接口。但这种方式，不是每个游戏都可以做的，需要和游戏厂商合作。因为一般游戏厂商不会直接开放接口也不会允许其它的程序进行拦截，所以我们会寻求一些合作，如果有厂商愿意合作的话，可以更方便地使用这种性能更高的方案。
通过两种方案采集到的游戏数据会被发送到编码模块，编码模块会做一些编码上的优化，再将编码后的数据打包发送到网络模块，最终发送到客户端。
2.1.4 解决方案的实现
我们解决方案的实现是基于GamingAnywhere，它是一个很早的开源项目，是基于开源项目进行运作的，并已经提供了比较多的跟远程游戏、远程应用有关的功能。我们对GamingAnywhere做了一些优化，上图是GamingAnywhere里面的一些线程和模型，它会有一个音视频的输入，音视频的输入有模块化的接口被送到下一层的音视频的编码器中。一种接口，多种实现，接口实现后可以对它进行优化。图中右边这条通路是一个控制流程，它从客户端发送数据到服务器，默认带了一个RTSP服务器。
3. 云游戏的优化
3.1 传输层的优化
在传输方面，除了原有的RTSP方式，我们也加入了WebRTC的支持。WebRTC提供低延迟、点到点的通信，很适合云游戏这种应用场景。我们测试了在弱网的环境下，WebRTC会有比较好的体验。在3%左右的丢包环境下，WebRTC会有较好的画质和更低的延迟。
3.1.1 WebRTC
WebRTC技术虽然出现很久了，但它的标准还是停留在1.0。即使如此，基于WebRTC也有一些优点：
首先，它是实时的，所以它的时延会比较低，设计延迟可能在200-300ms左右，但其实它的延迟在云游戏场景里还是不够低，云游戏需要更低的延迟。
其次，WebRTC是一套开放的标准，受到了主流浏览器的支持。并且它也是跨平台的，在各个平台都能用而且不需要插件，打开浏览器就可以用。因为WebRTC是一个开放的标准，所以其他的原生应用程序，只要实现了WebRTC标准就可以接入，这也是使用WebRTC解决方案的好处。
3.1.2 Open WebRTC Toolkit (OWT)
上图是我们基于WebRTC做的一个开源项目Open WebRTC Toolkit，目的是让大家能够更方便地使用WebRTC，并且在服务端提供的一些比较强大的媒体处理能力，包括会议、转码、媒体分析以及推流等功能。而且可用其中一个模块或者所有模块，进行分布式的部署，部署在不同的机房中有不同的接入节点，让用户进行就近接入。其次，客户端提供了一个全平台的解决方案，我们的云游戏用OWT作为其中一部分进行传输就可以享受到这些好处，比如有比较全的客户端支持等。
3.1.3 基于GA的增强
对于GamingAnywhere加上OWT就变成了图中这样的一个架构，图中不同的颜色代表了不同的模块，绿色的是GamingAnywhere中已经有的对于音视频的输入，包括对于鼠标、键盘、事件的重播等。我们做了一些自己的模块并对其进行了优化，体现在图中红色的部分，主要是对编码部分进行了优化。
另外，传输层用了OWT的P2P SDK作为其中一端，放在云服务的服务器上，另外一端是各种各样的客户端。上图右边是客户端，绿色的部分是我们要对其进行增强，主要增强的是两个部分，一部分是因为GamingAnywhere用的方案是基于视频传输的方案，可能在某些情况下我们需要用到基于指定模式的云游戏，所以我们也希望能够把视频的输入源变成绘制指令。另外一个是在传输层，除了WebRTC以外，我们也在考虑对QUIC增加支持，QUIC是一个基于UDP的传输协议，它在为HTTP设计的，提供可靠的传输通路和流的概念。目前有P2P QUIC在W3C ORTC CG中开发，提供了类似data channel的接口，WebTransport(CS QUIC)
在WICG中开发。此外QUIC还提供了非可靠的传输，这对音视频的传输比较友好。
3.1.4 GA WebRTC
上图部分我将对WebRTC的传输模块做一个更详细的解释，首先，在视频源外部进行编码器的优化，这是基于SDK做的一个编码好的视频数据，视频数据再把编码好的视频源送进WebRTC的模块，所以这里用到的是一个已经构造好的接口。其次，音频方面，目前我们是直接把GamingAnywhere抓到的音频的PCM数据直接输入，用WebRTC内置的音频编码器进行编码，最终将音频和视频全部发送到发送器，作为RTP打包后再发送出去。另一端通过客户端把鼠标、键盘等事件全部收集好，再传到datachannel的SCTP模块。通过ga-controller把客户端上JSON格式的鼠标、键盘事件转成SDL格式的事件送到SDL模块。
3.1.5 游戏加直播参考方案
这张图与刚才的内容比较类似，但是加入了一个直播模块。因为考虑到现在好多直播的应用场景，游戏主播直接通过云游戏方案玩游戏，然后直接就可以直播，因此增加了直播模块。在右下角有一个媒体服务器和一些直播客户端，通过OWT服务端的产品来实现，OWT的服务器提供比较强大的媒体处理转码以及推流功能，再把游戏服务器里的WebRTC的传输模块进行了扩展，除了游戏的客户端、P2P的WebRTC连接传数据以外，还要往媒体服务器上也推一路。这样的数据由于是从游戏服务器直接推过去的，所以它的延时很低。但是做直播的客户端是不能把他的鼠标、键盘用户输入事件给传过来的，玩游戏在这个参考方案中只支持一个人进行操作。如果要多人协同操作，需要做少量修改。
3.1.6 网络穿透
因为我们采用WebRTC方案，所以会有在网络方面的一些功能，比如网络穿透。如果把云游戏的游戏服务器部署在大型的数据机房，出现的问题会比较少。因为机房的端口会有配置进行开放，但是云游戏方案不一定运用在大型的公有云，也可能是私有云或家庭云，这种情况下，它就是一个真正的P2P连接，就会用到网络穿透的功能。网络穿透的主要原因是两端可能在路由器或者说在NAT的防火墙后面，在这种情况下它们就不能进行直接的连接，因为它的网络地址会进行转换。
像图中左边的电脑把自己的IP地址告诉右边的手机，那手机是连接不上的，它需要获得设备在互联网（公网）的地址。这里STUN Server的作用是客户端向STUN Server发一个包，然后STUN Server会回发一个包，这个包就走过了一条从内到外的链路。如果有多层路由器的话，它能通过STUN协议解出自己在每一层路由器上的IP地址和映射到端口的地址，这样它就知道了自己的所有的IP地址和映射到的端口，再把这个信息发到对端，再由对端把信息发到这一端，那么两方就可以进行连接，因为已经获取了对面的可连接的端口号以及可连接的IP地址。WebRTC还会做优先级的计算，如果两个人在同一个内网里面，虽然也会获得外网的IP地址，但是它会选择最近的那一条路径来进行连接。但是光用STUN通过探测NET转换地址的方式不能满足所有的网络环境，因为有很多NET是对称型的，它不允许外面直接发一个端口，而是需要从内部先发出去一个数据。
对于这种情况，对称型的NET或者规则比较复杂的防火墙，可能会把很多端口给禁掉，那么这种情况下光靠STUNserver是不够的，所以还需要TURN Server转发数据。有了TURN Server，连接成功的概率就会高很多，因为它可以进行转发而且又可以部署在公网，所以它就变成了两端和服务器的连接。但是缺点也显而易见的，用了TURN Server以后，流量都往服务器走，对于服务的提供商来说，这将带来比较大的成本。
3.1.7 OWT客户端
这是一张OWT客户端的图，服务端是一个集成在游戏服务器里P2P的客户端，另外一端可以是任何的OWT客户端。客户端结构的主要划分方式：首先它是基于Google的libwebrtc来作为它的底层，即图中绿色的模块，然后对整个WebRTC进行一些改正和增强。在此基础上我们提供了三组的API：一种是用于安卓的API；一种是用于Native开发的API；最后一种是提供给网页使用的JavaScript API。每一个SDK被分成两个模块，一个是P2P模块，用于点对点的连接；另一个是会议模块，用于推流，可用于直播。在Windows方面做了媒体层的增强，提供了硬件加速以及增加了优化后的Intel Media SDK的支持。
3.2 发送端优化
接下来的部分是关于发送端优化的内容，因为我们可能在运行程序时会发现延迟很大的问题，所以需要尽量减少延迟。我们观察了整个数据包在链路里面的时间，发现数据在节律发送器上面停留的时间过长，所以就修改了线程模型，把不同的线程在云游戏场景里面的优先级做了调整，是为了让数据包能够尽快发送到客户端。
造成延迟还有一个问题是带宽预测，因为WebRTC默认用的是gcc的带宽预测，所以它是基于延迟和丢包的，基于延迟的带宽预测非常敏感，可以快速降低带宽，这样不容易引起过量的数据包在网络通路上的堆积。但是这样会影响对带宽要求较高的场景的效果，于是我们对权值进行了调整。
3.3 接收端优化
在对发送端进行优化的同时我们在接收端上面也做了一些优化。接收端的优化主要在于增加了对Intel Media SDK的低延迟的解码，可以让解码端的时间降低。另外是音视频同步，我们发现有时候因为RTP上的时间戳没有打好，会导致视频已经到了，但还是要等音频。原因在于服务端是由两个线程跑的，一个取音频，一个取视频，两者并未完全同步，所以在接收端造成了额外的延迟，针对这一点我们对时间戳进行了优化。另外在某些情况下可以把音视频同步关闭，这样在云游戏场景里面的效果就会好一些。因为在云游戏场景中，大家希望能够尽快的收到数据，稍微有一点延迟造成音视频不同步的问题，对用户的影响反而不是特别大。
3.3.1 基于深度学习的超分辨率
接着介绍一下英特尔基于深度学习的超分辨率，因为某些情况下带宽实在提不上去，那就只能下调编码的质量，向客户端上传一个较低的分辨率。但是如果客户端的GPU性能很好，计算机性能很强大，就可以使用像超分辨率的技术为客户端提升视频质量。
3.4 客户端指针优化
在某些场景，比如玩家在游戏大厅聊天，这种情况下没有太多画面上的改动，但是由于用户不停地滑动鼠标，会导致整个图像被抓屏的图像有改变，所以编码器要重新工作，并将重新编好的帧发送到客户端。这就增加了编码器和带宽的消耗。针对这种问题，团队的解决方案是把鼠标和视频分开进行传输，视频如果碰到上文提到的这种情况，就不用再重新编码了，只需鼠标往客户端传一个更新的指针。有时鼠标会有样式的变动，如果有样式的变化，会把这个样式发送到客户端，由客户端在页面上面进行绘制以后再把鼠标指针对应贴到该有的位置上。
本文主要介绍技术方案，实际使用和部署中需要考虑版权和许可协议，建议咨询游戏厂商或与游戏厂商合作。
