编者按：从2019年开始，云游戏的热度迅速上升，云游戏平台如雨后春笋般出现。然而，目前还未出现一个影响力大的标志性平台，并且大家对云游戏的预期与云游戏的真实现状有出入。那么，如何才能为玩家提供高画质、超流畅和低时延的游戏体验呢？今天LiveVideoStack邀请到了智杰融兴的吴振永老师，为我们介绍云游戏音视频体验和优化实践。
文/吴振永
整理/LiveVideoStack
大家好！我是吴振永，来自智杰融兴科技有限公司，很高兴能跟大家做一次分享。我和我的团队从2019年开始做云游戏里的技术研发和平台的运营。今天，我分享的主题是：云游戏音视频体验优化实践。
今天，我分享的内容主要分为四个部分。首先，介绍一下我们团队当前的工作。然后，介绍云游戏的现状。接着，介绍一些技术架构。最后，和大家分享我们在实践过程中遇到的一些“坑”和应对方法。
01 自我介绍
首先，介绍一下我的公司。
智杰融兴主要提供实时互动视频云技术服务，为客户提供相应的技术能力。实时互动视频云技术可以应用于很多场景，比如在线教育、视频会议等。目前，我们团队主要专注于三个方向：云游戏、云电脑和云手机。从2019年开始，云游戏、云应用的热度迅速上升，许多做游戏开发、游戏发行、游戏平台的合作伙伴都想参与其中。然而，实时互动视频云技术涉及的技术环节较多，而合作伙伴更希望专注于自身的业务。因此，我们把自己定义为技术服务提供商，帮助合作伙伴快速使用相关的技术服务。左下图是我们做的云电脑，主要供做设计的合作伙伴使用。右图展示了我们为做游戏平台的合作伙伴提供的服务。
02 云游戏现状
接下来，介绍云游戏的现状。
从2019年底开始，受到谷歌的影响，云游戏的热度迅速上升。当时，谷歌推出了Stadia，整个行业都沸腾了，不管是行业参与者还是媒体都对其非常关注，聚集了很多参与者。于是，从2019年开始，云游戏平台如雨后春笋般出现。从图中可以看到，有技术、有流量、有内容、有资金的各方都开始布局云游戏。图中还列出了目前行业里做云游戏较好的App。现在打开应用商店，搜索云游戏或云电脑，会出现一百多个相关App。虽然在2019年云游戏的热度非常高，但现在云游戏的热度已经有所降低，大家转而开始关注元宇宙。
目前，云游戏平台越来越多，参与者越来越多，但还未出现一个影响力大的标志性平台。当前，大家对云游戏的预期与云游戏的真实现状有出入。在云游戏中，除了游戏内容的吸引力和运营手段外，玩家更关注画质、流畅度和时延。随着电子游戏的发展，画质也变得越来越好，可到达2K、4K，甚至8K的水平。这是因为玩家对画质的要求越来越高。此外，玩家对流畅度也有一定要求。流畅度可以映射为帧率，30fps和60fps已经成为了标配。对于有电竞级要求的玩家来说，帧率需要达到120fps（达到144fps则更好）。除了对流畅度有要求外，玩家对时延也有要求。云游戏包含了音视频的技术，但与点播、直播不同的是，云游戏对时延的要求非常高。对于视频点播和直播数据传输（音视频技术的传统应用场景），可以将其吞吐做得很大，或使用各种加速技术将管道充满。但在云游戏中，画面是实时生成的，因此要保证持续性的低时延可控传输。此时若只是单纯增大物理带宽会无法完全满足玩家对时延的诉求。
玩家对云游戏有高画质、超流畅和低时延的要求，希望有类似于本地化游戏的体验。然而，现实中会出现网络丢包、延迟抖动的情况，并且我们还要考虑到运营中的成本控制的问题。因此，面对玩家对业务的诉求或预期与网络的现实情况有出入的情况，我们要寻求合适的解决方法。目前，行业里的伙伴一直在探索如何在当前的网络情况下，提供更好的游戏体验。
03 技术架构
接下来，介绍一下整体的技术架构。
图中展示了整体的技术框架。从底层来看，我们实现了算力和存储的接入（包括自有的算力和第三方的算力）。然后，在底层的上一层中我们搭建了游戏的服务。接着，在服务层的上一层中实现平台的调度的管理，为客户提供SDK实现快速接入和业务的快速对接。在其上一层，我们可以支撑各类型的应用，比如云游戏、云桌面、云应用和云联运等，实现不同的业务。其中，与音视频直接相关的是各端SDK与GS服务间的流化传输。
目前在音视频的处理中，主要是基于RTC框架来运行。当游戏接入服务端后，通过游戏并行渲染和虚拟设备将游戏的音频、视频、操控和存储进行分离，做到单系统环境下多游戏并行运行的软件隔离，然后实现相应的编码、封包、ICE和拥塞，最后实现与客户端的跨平台互通。音视频是云游戏重要的核心技术之一，未来游戏的形态和音视频的界限会越来越模糊。目前，行业里已经出现比如游戏直播、围观、打赏等比较火热的场景方案。其中，云游戏的游戏过程是实时流，目前我们默认同时支持四路实时流的接入，即允许四个玩家同时接入平台进行实时地交互。对于进行游戏围观的观众，他们看的是直播流，所以在服务端中会同时推五路流。其中，有四路流是实时流，需要各自进行编码、封包、拥塞控制等处理。还有一路流专门作为直播的推流。在一个大的游戏的氛围建设中，会提高其曝光度，并增强其互动性、趣味性。因此，多人实时的互动游戏有很大的魅力。
04 优化实践
接下来，介绍我们在实践过程中遇到的问题和采取的解决策略（重点介绍我们自己采取的部分策略）。
我们先来看视频压缩。提到视频压缩，首先想到的是H.264、H.265、H.266或AV1，但在云游戏中我们要考虑更多的因素。比如在考虑编码效率和解码效率时，我们要从两个角度来考虑，分别是时延和消耗。这是因为服务端的计算资源有限，若编码的时延很大，则不适用于我们的场景。当前从编码效率和终端接入的情况来看，在短时间内还无法普遍地应用AV1。这是因为不仅要考虑整体的时延，还要考虑计算资源的消耗，其中包含了服务端的编码和播放端的解码。在压缩率方面，我们主要关注相同画质情况下的码率，在运行时以H.265为主，以H.264为辅，这样的选择与兼容性有关，目前还是存在小部分机型和芯片在解码265的时候存在大缓冲或者不稳定的问题，特别是一些旧手机和ott设备，所以都需要针对性地进行兼容处理。
之前提到，云游戏对时延非常敏感，那么我们要考虑如何最大程度地降低处理时延。在程序设计中，不同的模块间有缓冲机制、轮询机制，这是正常且合理的。但对于游戏业务或强实时业务来说，虽然每个环节只增加了几毫秒的时延，但所有环节的时延加起来就有几十毫秒，玩家在操作时就会有不舒服的感觉。因此，在流线化的处理中，我们要快速地传递数据，即在画面渲染后，要快速地进行转换和编码。需要特别注意的是画面的渲染和处理，需要避免 在GPU和CPU间进行拷贝，这个会导致较大的时延和系统开销，所以要把处理和编码都放在GPU中进行。这样在GPU内，可以快速处理渲染后的画面，并快速地进行数据封包和发送。
缓冲区是另一个需要特别注意的设计。因为有缓冲区存在，就会导致时延的累加。当然，由于网络中存在丢包现象，所以需要缓存发送的数据，但整个的处理流程中尽量避免缓冲区。其中，在视频解码和渲染显示之间，需要进行必要的缓冲。这是因为在前面的过程中网络会抖动，处理就会有快有慢。此时玩家观看导出的画面时，发现画面可能会突然出现一个慢动作或快动作，这是因为帧的间隔不稳定。因此在这个环节中，需要进行缓冲处理来保证帧的间隔稳定。所以，在整个处理流程中，要取消缓冲、缓存、定时器机制，采用流化处理快速驱动。
接下来，介绍必要缓冲策略。在数据的整个传输过程中（包括解包和最后的处理），会出现波动。如图所示，蓝色的线是一条正常波动的曲线。在正常情况下，波动的曲线是稳定的，但同时也会有突发的情况。
按照常规算法来看，呈现出的应该是橙色曲线的情况。在网络稳定的情况下，可以降低缓冲的时延。相对地，在网络出现问题时，可以提高缓冲的时延。最终的波动情况就如橙色曲线那样。橙色曲线是较平滑和较稳定的，但对于需要快速降低时延的场景来说，还需要进行进一步地优化。
灰色曲线是优化后的结果。当网络较稳定时，要快速地降低时延。降低时延的程度与抖动的范围相关。当网络出现大幅度地抖动时，要快速提高缓冲的时延。此时，玩家会感觉画面突然跳了一下。画面出现跳动后，会马上恢复正常状态。随着时间的推移，网络恢复稳定，如灰色曲线中以更平缓的方式下降。如果连续出现几次跳变，最后会让曲线更加平缓。因为根据数据的累积可以发现，网络的情况比较糟糕。当然，在网络情况良好的情况下，时延会非常低，基本接近端到端的时延。在网络情况糟糕的情况下，经过几次循环后，若还是判定网络情况糟糕，后续会以更平缓的方式运行。总之，这个策略采用了快降，但当出现波动时，会调整斜率来达到平衡稳定。这样，在网络情况良好时，时延较低，在网络情况糟糕时，也可以恢复到比较平衡稳定的状态。
接下来，介绍在传输的序列中，实现的预丢包快速重传。蓝色曲线表示正常网络传输中RTT的曲线。在这条曲线中，通过计算获得两条虚线，两条虚线构成了一个震荡区间。震荡区间是随着时间推移形成的曲线点。在网络出现抖动时，我们会关注最高点。当最高点的值超过300毫秒、400毫秒甚至更大的值或包出现乱序时，会将其判定为丢包，需要进行数据的快速重传。但可以看到，此时已经经过了一定的时间，所以对此我们要进行相应地处理。
首先，我们划定一个震荡区。震荡区表示了一个合理的范围。当网络出现抖动或接收端没有接收到预期的数据时，会进行预请求，要求重发一次数据。当真正出现丢包、包发生乱序或包延迟到达时，由于已经进行了预请求来要求重发数据，因此服务端若有这个数据就会快速重传该数据。此时，可能有2-3个包在传输过程中，只要接收到一个包就能还原数据，能将时间线往下推进。
通过预丢包快速重传的方式，首先判定其丢包或网络出现问题，不用等待而是要求提前获取数据。这样的方式取得了一定的效果。目前在运行时，在整个区间的判定上，将带宽增加了5%-10%，这会明显地提高平滑度。需要特别注意的是，重传（预判）的点位非常重要，这一点若处理不好会导致一直传输大量的数据，这就会消耗大量带宽。
最后，介绍一下多路保活。玩家在实际玩游戏的过程中，手机连接的可能是场地的WiFi，同时还有4G的网络。当玩家在场地走动时，WiFi的信号可能会变弱或离开了WiFi的服务区，因此切换到了4G网络。此时，对于玩家而言，在游戏过程中会感觉发生了网络断开。断开后，会启动重连或重试机制，这会造成几秒或十几秒的卡壳。玩家的直观感受就是画面静止，然后意识到网络在重连。再过几秒钟，会重新连接到网络。可以看出，客户端的网络是不可控的。在实际运行过程中，手机端的用户在游戏过程中出现连接、断开的情况接近5%左右，这是正常的现象。这是因为如刚才所说，玩家最开始连接WiFi来玩游戏，当玩家在场地走动导致WiFi信号变弱或离开了服务区，或者玩家在游戏过程中接了电话，都会导致游戏的中断。总之，对于客户端来说，已经建立连接的网络发生断开是正常的现象。
对于服务端来说，情况也是一样的。在游戏中，玩家可能有开房、跨区和玩家互动的诉求。因此，在节点我们会做多线接入或多端口接入，比如电信、联通、移动等。在接入过程中，某一个网络可能会出现问题或抖动，这是正常的。当然，在骨干网上，某一个路由出现拥塞也是正常的。当出现拥塞时，直观的现象是延迟会发生抖动，丢包也会发生变化。可以看到，客户端和服务端的网络都是不可控的。若网络断开则需要重连或恢复，这需要几秒钟的时间。此时，玩家会感觉游戏卡壳。
为了优化这个问题，我们设计了多路保活的机制。在客户端，4G和WiFi会和服务端的多个通道同时建立连接以保持连接状态，并以一个较高的频率探测整个路径的存活状态。其中，我们引入了中转方的角色。当出现客户端和服务端之间的连接被运营商拦截或网络中断的情况时，会有第三方作为中转方进行线路的支撑。如图所示，我们假设客户端有两条线路。一条线路是4G，另一条线路是WiFi。我们假设服务端也有两条线路（实际有三条线路）。中转方与客户端和服务端间也有路径。其中，有多条路径处于活跃的状态。当某条路径发生丢包或延迟超出允许的区间范围时，在服务端会马上通过另一个通道将数据发送出去。在服务端和客户端，会保证几条路径同时都是活跃的，并且持续计算其延迟和丢包。这样当网络出现问题时，可以快速选择另一条路径。对于客户端和服务端而言，基本没有增加消耗。真正增加消耗的是中转方。这是因为大量设备需要和中转方建立连接。中转方在平时不用做事情，但其会维持大量的端口和探测，以此保证路径是活跃的，从而在发生问题时，能快速接管并保证画面的流畅度和完整度在预期以内。这在实际运行中，效果还是非常明显的。从数据统计中可以看到，在单通道的情况下（WiFi或4G），延迟和丢包的比例非常高。在多通道的情况下，链路可以得到快速恢复。因此从最终结果来看，玩家获取的时延和丢包的比例都有所减小。
以上内容介绍了我们遇到的问题和处理的策略。介绍了在复杂的网络环境下，如何尽最大努力为玩家提供低时延、高画质的游戏体验。
以上就是本次分享的主要内容，谢谢大家！
