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

如果说，在以音视频为载体传输信息、进行交互的技术领域，始终飘着一朵“乌云” ，那么这朵“乌云”的名字，很可能既不是低延时，也不是高可靠，而是不断变化的应用场景。
从 Web 2.0 到移动端基础设施全面建成，我们完成了文字信息的全面数字化；而从 2016 “直播元年”至今，图像、语音信息的全面数字化则仍在推进中。最简单的例证是，对于早期的流媒体直播而言， 1080P 是完全可接受的高清直播；但对于今天的流媒体而言，在冬奥会这样的直播场景下， 8k 可能是个刚性需求，相比于 1080P ，像素数量增长 16 倍。
而且，今天的流媒体业务，对视频流的要求不仅停留在分辨率上，也表现在帧率上。以阿里文娱 2019 年底推出的“帧享”解决方案为例，它将画面帧率推至 120 FPS ，同时对动态渲染的要求也很高。过往人们总说，帧率超过 24 FPS ，人眼就无法识别，因此高帧率没有实际意义。但高帧率是否能提升观看效果，与每帧信息量密切相关，近几年游戏开发技术的进步，以及以李安为代表的一众电影导演，已经彻底打破这一误解。
对于 RTC 来说，问题情境和对应的软件架构又截然不同。早期大家看赛事直播， 20s 的延迟完全可以接受。但在 RTC 场景下，人与人的即时互动让使用者对延迟的忍耐度急剧降低，从方案到自研传输协议，相关尝试从未停止。
当我们以为，所谓的场景问题，终于可以被抽象为有限的几个技术问题，并将延迟压入 100ms 以内，可靠性提升至 99.99% ，新的场景又出现了。全景直播、VR 全球直播，云游戏……其中又以云游戏最为典型——云游戏简直是过去那些音视频场景性能要求的集大成者：有的游戏要求延时低至 50ms 以内；有的要求 FPS 60 以上；分辨率不消说，肯定是越高越好。同时云游戏场景夹杂着大量的动态渲染任务，无一不在消耗着服务器资源，增大着全链路的传输延时。
那么，如果从云游戏场景的性能要求出发，进而扩展至整个超视频时代的架构体系，该以怎样的思路来进行架构设计呢？只关注软件，可能不太行的通；硬件成为必须纳入考虑的一环。
以软件为中心并非最佳选择
要解释这个问题，必须重新回顾下常规的云游戏技术架构。下图主要参考自英特尔音视频白皮书、华为云游戏白皮书，并做了相应调整，基本与当前环境下，大部分云游戏架构的设计相符。
在这一架构内，至云游戏终端前，所有服务都在云端、公共网络上完成，保证用户无需下载游戏或是为了玩游戏购置高性能终端。游戏玩家的终端，主要负责对网络包进行处理、对渲染后的游戏画面进行解码、显示，并相应地输入指令，回传给服务器。
而在服务器端，链路相对复杂。云游戏管理平台是服务的起点，上下两条链路，都是云游戏的周边技术服务，与业务场景强相关，包括云游戏的直播录制、游戏日志 / 记录存储等。前者对时延忍耐度较高，可以走正常的流媒体服务体系，使用 CDN 分发音视频内容；后者属于正常的游戏服务器设计范畴，正常提供服务即可。