本文由InfoQ授权。如果说在以音视频为载体的信息传递和交互的技术领域中总漂浮着一朵“乌云”，那么这朵“乌云”的名字很可能既不是低延迟也不是高可靠，而是它不断变化的应用场景。从Web2.0到移动基础设施的全面建成，我们已经完成了文本信息的全面数字化；而自2016年“直播元年”以来，图像和语音信息的全面数字化仍在进行中。最简单的例子，对于早期的直播流媒体来说，1080P是完全可以接受的高清直播；但对于如今的流媒体来说，在冬奥等直播场景下，8k可能是硬性要求，相对于1080P，像素数增加了16倍。而且，在当今的流媒体业务中，对视频流的要求不仅仅停留在分辨率上，更重要的是帧率。以阿里文娱在2019年底推出的“分帧”方案为例。它将画面的帧率推到了120FPS，对动态渲染也有很高的要求。过去，人们总说帧率超过24FPS，人眼就无法识别，所以高帧率没有实际意义。但高帧率能否提升观看效果，与每一帧的信息量密切相关。近年来，游戏开发技术的进步，以及以李安为代表的一批电影导演，彻底打破了这个误区。对于RTC，问题情况和对应的软件架构有很大的不同。前期大家都看比赛直播，20s的延迟完全可以接受。然而，在RTC场景下，人与人之间的实时交互大大降低了用户对延迟的容忍度。从WebRTC方案到自研传输协议，相关尝试从未停止。当我们以为所谓的场景问题终于可以抽象成有限的技术问题，将时延压在100ms以内，可靠性提升到99.99%时，又出现了一个新的场景。全景直播、VR全球直播、云游戏……其中以云游戏最为典型——云游戏简直就是以往对音视频场景性能要求的集大成者：有些游戏要求时延低至为50毫秒；有的要求FPS大于60；不用说，分辨率越高越好。同时，云游戏场景中夹杂着大量的动态渲染任务，这些任务都会消耗服务器资源，增加整个链路的传输延迟。那么，如果我们从云游戏场景的性能需求出发，再扩展到整个超视频时代的架构体系，架构设计应该用什么样的思维呢？只关注软件可能行不通；必须考虑硬件。以软件为中心并非最佳选择要解释这个问题，我们必须重新审视传统的云游戏技术架构。下图主要基于Intel音视频白皮书和华为云游戏白皮书，并做了相应调整。与当前环境下大部分云游戏架构的设计基本一致。InfoQ的版权在这个架构中。直至云游戏终端，所有服务均在云端和公网上完成，确保用户无需下载游戏，无需购买高性能终端玩游戏。游戏玩家终端主要负责处理网络数据包，解码并显示渲染的游戏画面，相应地输入命令，并发送回服务器。在服务器端，链接相对复杂。云游戏管理平台是服务的起点。上下两个环节是云游戏的周边技术服务，与业务场景强相关，包括云游戏直播、游戏日志/记录存储等。前者对延迟的容忍度更高，可以跟随正常的流媒体服务系统，使用CDN分发音视频内容；后者属于正常的游戏服务器设计范畴，只需要正常提供服务即可。关键在中间层，也就是云游戏容器集群。这部分要达到的基本设计目标是保证1秒内至少24个游戏画面（24帧）的计算、动态渲染和编码传输。一些高要求的场景需要60FPS的帧率，同时确保延迟尽可能低。这部分的技术挑战非常大，如果只着眼于软件，很难有真正的突破。从相关指标的演化历程来看，仅仅在4年前，手游本地渲染的基本目标还是30FPS。虽然今天可以做到60FPS甚至更高，但是讨论的场景也从本地渲染切换到了云端渲染。.在软件方面，除非在学术层面有所突破，否则很难保证性能一直保持这样的飞跃。此外，渲染是一项非常依赖硬件的工作。渲染速度和质量的提升主要依赖于GPU技术、性能和配套软件的提升。更复杂的游戏性能和对3D游戏渲染整体时延的控制，对整个处理和传输环节提出了要求。仅以时延为例，它要求编码、计算、渲染、传输等任何一个环节的处理时间都控制在一个比较低的范围内。同样在3-4年前，有业内专家分享过他们对RPG云游戏的传输延迟容忍度是1000ms，结果玩家无法容忍1s的输入延迟。反观今天，无论是通过公有云+GA方案，还是通过自建实时传输网络方案，即便是传输普通音视频流的RTC服务，也只能保证100ms以内的时延，而云游戏的计算量和带宽需求是普通音视频服务的两倍。以上只是冰山一角。对于架构设计，除了高性能、高可用、可扩展这三个设计目标外，成本也是一个必须要考虑的平衡点——需要1000台服务器的架构和需要100台服务器的架构在同一时间是不一样的全部。概念。2010年前后，云游戏C端商业化的可能性基本没有。虽然当时整体延迟和性能指标都可以满足要求，但是成本是一台服务器只能服务一个玩家，单个玩家的服务成本就上万。云游戏“老大”Onlive的失败，在当时就很能说明问题。到2020年，行业硬??件整体性能提升后，一台服务器可支持20-50路并发，性能提升数十倍。那么，如果我们将硬件作为架构设计的核心考虑因素，会是什么样子呢？大致如下图所示（为了图解过于复杂，我们只保留云游戏核心服务链接作为代表）。InfoQCopyrightAllRightsReserved可见仅在云服务器部分，需要涉及到大量的硬件和配套软件，需要关注的性能点也比较复杂。而这只是云游戏一个应用场景中的音视频架构。当我们对场景进行抽象和扩展，最终覆盖整个超视频时代时，英特尔技术团队的以下架构图可能更符合实际。Intel在软硬件层面展示了音视频架构：一部分称为Infrastructure（基础设施层），如图1；另一部分叫做InfrastructureReadiness（基础设施就绪），指的是基础设施就绪后，在上面构建工作负载，如图2所示。两张图的开头和结尾有一定程度的重合，说明他们的目的是相连的。图1：基础设施层图2：基础设施就绪后的工作负载可以看到，基础设施层主要包括硬件、支撑云服务、云原生中间件、各种开源基础软件。在工作负载层面，有大量的软件工作，包括核心框架、SDK、开源软件贡献（UpStream）。这就是为什么英特尔以硬件着称，却保有超过万人的软件研发团队。拆解软硬件一体化音视频架构方案的基础设施层在基础设施层，我们主要关注的是硬件，尤其是音视频业务，硬件升级给业务带来的收益是相当直接的。但是，与十年前相比，现在的硬件产品家族的复杂性和丰富性直线上升。核心原因无非是场景的变化带来了新的计算需求。一去不复返。以上图Intel硬件矩阵为例。在音视频场景，我们主要关注CPU、GPU、IPU。限于文章篇幅，网卡等其他硬件不在重点讨论范围内。CPU方面，英特尔更新了Xeon?第三代可扩展处理器，与第二代相比，内存带宽增加了1.60倍，内存容量增加了2.66倍。在PCIeGen4中，PCIExpress通道的数量最多增加了1.33倍。其中，Intel?Xeon?Platinum8380处理器可达8通道、40核，主频2.30GHz。Intel在支持冬奥8k转播时，CPU端的主要方案是Platinum8380，这里有详细的参数表供大家参考（https://www.intel.cn/content/www/cn/zh/products/sku/212287/intel-xeon-platinum-8380-processor-60m-cache-2-30-ghz/specifications.html)：IntelCPU的另一个值得注意的特点是它的支持软件级别，主要是AVX-512指令放。AVX-512指令集于2013年发布，是一个扩展指令集。旧的指令集只支持一条指令操作一个数据，但随着场景需求的变化，单指令多数据操作成为必然，AVX系列逐渐成为主流。目前AVX-512指令集的主要用途是使程序能够同时进行32个双精度、64个单精度浮点运算，或运算8个64位整数和16个32位整数。理论上浮点性能可以提升一倍，整数计算性能可以提升33%左右，目前只有Skylake、IceLake等三代CPU上支持，所以也是独一无二的。在视频编解码、转码等过程中，由于应用需要进行大规模的整数和浮点数计算，AVX-512指令集的使用也相当关键。GPU方案通常在云游戏场景中更受瞩目。英特尔?服务器GPU是第一个基于英特尔Xe架构的数据中心独立图形处理单元。英特尔?服务器GPU基于23W独立片上系统(SoC)设计，具有96个独立执行单元、128位宽流水线和8G低功耗内存。所谓片上系统SoC，英文全称SystemonChip，即系统级芯片，SoC包括但不限于CPU、GPU。就在今年，前Mac系统架构团队负责人、苹果M1芯片的“功臣”JeffWilcox宣布离开苹果，出任IntelFellow、DesignEngineeringGroupCTO，并负责客户端SoC的架构设计也引起了业界的广泛关注。当然，仅有GPU硬件是不够的，Intel?MediaSDK几乎是GPU必备。英特尔?媒体SDK提供高性能软件开发工具、库和基础设施，用于在基于英特尔?架构的硬件基础设施上创建、开发、调试、测试和部署企业级媒体解决方案。它的构成可以参考下图：IPU是为分担CPU工作量而生的专用芯片。2021年6月，英特尔数据平台事业部首席技术官GuidoAppenzeller表示：“IPU是一个全新的技术类别，是英特尔云战略的重要支柱之一。它扩展了我们的智能网卡，旨在应对当前复杂的数据中心并提高效率。”具体在音视频场景中，IPU负责处理编码后的音视频流的传输，从而让CPU有更多精力关注业务逻辑。所以，CPU+GPU+IPU的组合，不仅要关注不同场景下的需求满足，还要关注架构的成本。工作负载层从基础设施过渡到工作负载。其实有一张架构图更详细的展示了相关技术栈的组成：在这张架构图中，横向是从源码流输入到分发的整个过程，包括编码和编码等处理动作显示分析；而垂直方向则是服务于这个音视频处理过程所需要配套的硬件和软件系统。OneAPI作为异构算力编程模型，是桥接基础设施和上层负载的关键层，这一点不言而喻。说到加载层，软件分为蓝色和紫色两个色块。蓝色代表直接开源软件，紫色代表经过英特尔深度优化后反馈（Upstream）到开源社区的开源软件。在蓝色部分，OpenVino是一个非常有趣的工具套件。围绕深度学习推理做了很多性能优化，兼容TensorFlow、Caffe、MXNet、Kaldi等深度学习模型训练框架。当音视频系统需要加入AI技术栈来服务超分辨率等关键需求时，OpenVino将发挥关键作用。紫色的x.264/x.265就是一个典型的例子。作为音视频行业最主流的编码标准，英特尔将其作为开源的主要贡献者，AVX-512指令集也围绕x.264/x.265进行了优化和性能测试。另一个值得关注的核心是编码器，它横跨蓝色区域和紫色区域。既有业界通用的ffmpeg，也有英特尔自研的SVT，两者同样备受瞩目。关于编解码器选型的思考在流媒体时代，大名鼎鼎的开源多媒体框架ffmpeg在做编解码处理时是业界绝对的参考对象。说白了，很多编解码器都是ffmpeg的深度定制版。在RTC时代，由于实时交互要求更加苛刻，自研编解码难度较大，但在研发能力强的企业中也形成了趋势。归根结底，在推进上述工作时，软件始终是思维的出发点，从业者多少忽略了硬件的适配。SVT的全称是ScalableVideoTechnology。它是开源项目OpenVisualCloud的重要组成部分。针对Intel的多CPU进行了高度优化，因此在Intel的硬件系统上有着突出的表现。SVT设计的最简单的初衷是为了提高现代CPU多核的利用率，比如依靠硬件上的多核设计并行处理多帧，或者将一幅图像分成块然后分块处理。并行，这大大加快了进程。处理速度，避免多核CPU空转。比较知名的可能是后来的开源项目，叫做SVT-AV1（GitHub地址：https://github.com/AOMediaCodec/SVT-AV1），AV1开源视频编码，由英特尔、谷歌、亚马逊、思科、苹果、微软等联合研发，目的是提供比H.265更高效的压缩率，降低数据存储和网络传输的成本。而就在今年上半年，英特尔发布了其面向CPU的开源编解码器SVT-AV1的1.0版本，相比0.8版本有了巨大的性能提升。结语归根结底，虽然“摩尔定律”仍在延续，但靠吃“硬件红利”解决新应用场景的“甜蜜期”如今已经过去。今天，我们需要了解的是以CPU、GPU、加速器、FPGA等硬件为核心的复合架构，也就是所谓的由标量、向量、矩阵、空间组成的SVMS架构。这一概念由英特尔率先提出，并迅速成为业界最具统治力的硬件架构策略。同样的趋势也存在于位于硬件之上的开发者工具中，Intel的oneAPI就是一个典型的作品。只是对于开发者工具来说，目前最重要的工作不是性能提升，而是生态和集成。从硬件到基础软件，再到开发者工具，整个基础设施层呈现高度复杂的架构演进趋势，这不仅对架构师的工作提出了严峻的挑战，也给了所有架构师更大的发挥空间。对于架构师来说，如何为自己的企业算好成本，在追求高性能和高可用的同时，兼顾硬件并高度重视，才是最重要的。点击【阅读原文】前往英特尔官网获取白皮书《英特尔互联网行业音视频创新实践》！活动推荐《架构师成长计划》是英特尔与国际学术期刊《科学》（Science/AAAS）联合推出的公益学习计划。我们提供学习资源和公益培训，让建筑师系统地学习、拓展和创新，获得深入和持续的学习和成长。第一期课程重点讲解音视频架构搭建，扫码免费听课：
