超视频时代音视频架构建设与演进( 二 ) _英特尔

【超视频时代音视频架构建设与演进】关键在于中间一层，也就是云游戏容器集群。这一部分要实现的设计基础目标是保障 1s 至少完成 24 张游戏画面（24 帧）的计算、动态渲染和编码传输，部分高要求场景需要帧率达到 60 FPS ，同时保证时延尽可能得低。
这部分的技术挑战非常大，以至于若仅以软件为中心思考，很难做出真正突破。从相关指标的演进历史来看，仅仅在 4 年前，移动端游戏本地渲染的基础目标还是 30 FPS ，如今虽然能实现 60 FPS 甚至更高，但讨论的场景也从本地渲染切换成了云端渲染。在软件上，除非出现学术层面的突破，否则很难保证性能始终保持这样跨度的飞跃。
此外，渲染本来就是严重倚仗硬件的工作，渲染速度和质量的提升，主要依赖于 GPU 工艺、性能以及配套软件的提升。
3D 游戏渲染画面
而更为复杂的游戏性能以及整体时延的控制，则对整个处理、传输链路提出了要求。仅以时延为例，它要求在编码、计算、渲染、传输等任何一个环节的处理时间都控制在较低范围内。同样是在 3 - 4 年前，有业界专家分享，他们对 RPG 类云游戏的传输时延容忍度是 1000 ms ，但事实证明，玩家并不能忍受长达 1s 的输入延迟。反观今日，无论是通过公有云 + GA 方案，还是通过自建实时传输网络方案，即便是传输普通音视频流的 RTC 服务也只能保证延时 100ms 以内，而云游戏的计算量和带宽需求数倍于普通音视频服务。
以上仅仅是冰山一角。对于架构设计而言，除了高性能、高可用、可扩展性三类设计目标外，成本也是必须要考虑的平衡点——需要 1000 台服务器的架构，和需要 100 台服务器的架构，压根不是一个概念。2010 年前后，云游戏基本不存在 C 端商业化可能，虽然整体时延和性能指标可以满足当时的要求，但代价是一台服务器只能服务一个玩家，单个玩家服务成本上万。云游戏“元老”公司的失败，在当时非常能说明问题。
而到了 2020 年，行业硬件的整体性能提升后，一台服务器可支持 20 - 50 路并发，性能提升了几十倍。
那么，如果我们将硬件变成架构设计的核心考虑要素，会是什么样的呢？大致如下图所示（为了不让图示过于复杂，我们只保留了云游戏核心服务链路，以作代表）。

文章插图
可以看到，仅在云服务器部分，就有大量的硬件和配套软件需要参与进来，要关注的性能点也相对复杂。而这仅仅是云游戏一个应用场景下的音视频架构，当我们将场景抽象并扩展，最终覆盖到整个超视频时代的时候，以下这张来自英特尔技术团队的架构图，可能更加符合实际。英特尔将音视频体系架构在软件和硬件层面分别进行了展示：一部分叫做（基础设施层），如图一所示；另一部分则称其为（基础设施就绪），指的是基础设施就绪后，建立在其上的工作负载，如图二所示。两张图的首尾有一定重合，表示其头尾相接。
基础设施层
基础设施就绪后的工作负载