互动云渲染——云原生渲染的初步探索

LiveVideoStack 2021年12月27日

随着游戏及软件云端化运行能力的支持,大型游戏和软件可以在浏览器、轻客户端以及小程序中运行,在扩展了使用场景边界的同时,也为游戏和软件探索云原生实现提供了基础。腾讯云云渲染 PaaS 提供了基于 WebRTC 的万人级互动交互的云原生能力,包括操作权限转移管理、多人语音会话等,在本次LiveVideoStackCon 2021北京站,腾讯云专家工程师 云渲染技术负责人——王超向我们分享了互动新玩法上的技术实现。


文 | 王超

整理 | LiveVideoStack


大家好,我是来自腾讯云的王超,我2011年入职腾讯,待了将近11年,之前也一直都在从事音视频相关的工作,最早是在QQ的后台音视频,到腾讯云视频直播场景的建设等,从去年开始我的主要投入到整个行业内相对比较新的方向,包括云原生能力在内的初步技术探索,这也是我今天分享的主题——互动云渲染,主要是和大家探讨一下云原生渲染的能力,以及可能会遇到的问题。

互动云渲染——云原生渲染的初步探索


今天分享的大概内容,会从什么是云渲染开始,介绍云渲染最基础的交互层面的核心技术,主要会从编码和传输两个方面进行分析。第三块是云原生渲染和互动云渲染能力的探索,看看我们能在云渲染上做出什么内容。


1. 云渲染介绍


首先介绍一下云渲染。

互动云渲染——云原生渲染的初步探索


如果用一句话介绍,云渲染就是把我们的软件和游戏放到云端运行,通过全端的SDK支持接入,用户可以跨任何平台实现接近于本地延迟及画质的操作体验。左图呈现的是一个成功案例,它在小程序里通过云渲染平台,接入到我们整个的服务。后端运行的软件是基于UE引擎开发的,我们将深圳南头古城进行1比1的数字孪生复原,展现的场景和实地景点是一模一样的,同时还有很多交互内容,包括直接购票、评论等等,主要探索的是线上线下结合的交互体验。除此之外,我们也兼顾了手机分辨率自适应等方面。

互动云渲染——云原生渲染的初步探索


如果从更细的层次来看,云渲染是什么呢?云渲染是我们基于底层内容、资源、调度的服务。构建中间层的云端游、云手游、云应用的PaaS能力,最终以更SaaS或者解决方案的形式推出一些成品。

这里列举了三个例子,虚拟人就是云端运行的一个人物模型,可能是像真人一样的,也可能是卡通的,它的表情和动作会跟着真实人的动作实时反馈。虚拟人的应用场景非常广泛,比如在会议,不想用真人的方式显现出来,或者主播想要用虚拟的形象代替真人去呈现等等。

第二个是广告试玩,我们现在更多的是运用在各个平台的信息流,普通的广告可能就是一张图片或一段视频,用户并不能知道具体的内容是什么,而广告试玩可以帮助广告投放商,在信息流中直接打开并且体验内容。数字孪生在之前提到过,就不再展开了,整体的产品能力层次大概就是这样。


2. 云渲染核心技术


基于现在的产品能力,接下来让我们看看它是如何实现的,到底需要做些什么,又涉及哪些核心的技术。

2.1 云渲染能力概览

互动云渲染——云原生渲染的初步探索


上图是云渲染能力的概览,左边是我们整体的平台能力,底层有一些支撑的系统,包括运营系统,监控服务,这些都是非常底层的,一般用户不会关注到。第二个是一些硬件资源,比如GPU资源、网络资源、边缘节点资源等,对它们进行整体的管理和调度。基于这个能力再去构建内容平台,比如,一些客户自己有软件,可能就会涉及内容包的上传、版本管理、自动更新以及内容分发。再上一层,就是把这些硬件资源和内容管理资源结合起来做一个调度,同时也会有一些不同用户之间的配置差异管理,如果在有些场景下适用性没这么强,就还会有更通用的脚本,实现更定制化的能力支持。

右边上面是我们真正云渲染实力的体现,是云渲染交互中可能会涉及到的一些功能,比如,数据特传,分别率自适应等能力。对于不同的平台,都会提供云渲染的实例,通过SDK进行实时交互。这里使用了WebRTC,像前面也看到的小程序本身可以理解为一个网页,更多的就是Web端的呈现,所以我们希望更多的用户可以在轻便的网页上进行访问,不一定是Native App去做这样的支持。那如果我们选择私有协议就很难在Web端做扩充,只有选择一个业界公认的、标准的协议WebRTC。基于WebRTC的标准能力,我们也可以做一些深度优化,在Native端提供比Web端更深层次的优化能力。

2.2 云渲染核心流程

互动云渲染——云原生渲染的初步探索


完整来看,左边大概就是整体云渲染的层次,右边就是SDK的层次。位于底层的GPU,常见的就是英伟达的GPU,上层OS一般是Windows、安卓这种,再上面有一个设备驱动。真实用户和客户提供的软件在上层进行运行,而我们的服务就是在软件运行时,通过Capture层捕获渲染的数据,再通过编码器编码出来真实的音视频数据传递给WebRTC层,WebRTC层就通过音视频数据流发送给SDK,SDK获取数据后会解码做渲染,底层能力平台相关的东西,我们封装在SDK里,都会屏蔽掉。

因为是互动的交互过程,用户还会有一些反馈操作,比如鼠标、键盘、手机触摸屏的事件,这些事件的回馈,我们都通过数据通道Datachannel往WebRTC回传,应用层获取的操作会把这些数据往设备驱动发,设备驱动收到信息后其实是传给OS的,OS最终以某种形式传给软件、游戏,软件和游戏会对操作进行真实响应,画面就会产生相应变化。按刚刚说的整个流程,大家就都能看到画面的变化过程,这就是我们真正核心的东西。

2.3 云渲染延迟分析

互动云渲染——云原生渲染的初步探索


刚刚看来核心流程,现在从细分来看一下整体的延迟。云渲染说到底是要提供接近于本地平台原生的体验能力,是有两大非常重要的东西,一个是延迟,一个是画质。延迟和画质之间又有相互矛盾的地方,接下来就来分析一下。

上图是简化的流程图,左边通过采集端采集到画面,然后做视频画面的编码进行传输,再到终端做解码和渲染。图中占比比较大的就是编码、传输和解码,这也是真实影响延迟非常重要的因素。

从采集端来看,耗时会比较稳定,一般是2ms左右,编码耗时就和其他东西有相关性,采用的编码方式、参数、质量都会影响到耗时,而传输就包括RTT和RTT里的收发包JitterBuffer都会影响到延迟。解码端可控的会比较少,更多依赖于编码参数,但也有些场景,比如默认的硬解解码策略,并没有启用低延迟的解码策略,所以这里可能需要进行一些低延迟的参数设置,来降低解码端的延迟。

从编码质量上来看,主要是编码格式,常见的是H.264、H.265,H.265的编码在同等码率下肯定是要优于H.264,但H.265又有一些兼容性的问题,比如WebRTC并没有做对于H.265的支持。所以编码格式只是其中一个因素,编码器本身的BD-rate也会影响整体编码质量。还有码率和GOP,理论上来说,如果GOP越大,单位帧的码率就会越大,因为I帧数量越少,最理想的方式就是从头到尾没有GOP没有I帧,但这种情况一般不会出现。我们考虑的就是采用无限GOP的方式,出现丢包、花屏时,通过PLI的方式去反馈,传一个I帧,实时减少I帧在整体视频流中码率的占比,提升画面质量。

2.4 编码方式分析

互动云渲染——云原生渲染的初步探索


接下来介绍一下编码方式,软件或游戏的渲染方式是在GPU中进行的,GPU里面简单分为渲染单元和解码单元。一般来说这两单元是相互隔离的,资源都是独立的,相互之间不会有冲突。软件包括游戏都是使用渲染单元,渲染单元之后所有数据都生成在显存中,如果能在GPU显存中直接拿编码单元编码其实是最理想的,因为能看到在同一个硬解层面做这个事情,所有数据都是共享的。这个实践虽然是理想的实践,但也会有一些瓶颈,比如因为一张GPU卡只跑一路,编码肯定能跟上,但一张GPU跑多路,那编码性能整体可能就跟不上了。

所以我们也要考虑多种方式,一种方式是用内存做CPU的软编,这时数据要从显存中拷到内存中再做软编。拷的过程中,以1080P的大小来看,1帧大概是8Mib,60帧大概是 480MiB,这个传输量以目前PCIe 4.0 x4的速度大约 7.88GB/s。这么看其实还好,但实际上这是单路,占整体带宽的1/16,假设一张GPU卡跑10路,这个占比就非常高了,整体会出现比较大的冲突。这时发现用软编的方式分析,本身也会有数据拷贝和其他冲突瓶颈在其中。

另外,可以用硬件解决GPU编码能力不足的问题,比较常见的方式是ASIC。它本身并没有直接从显存中获取到数据,所以一样会有通过PCIe通道进行数据传输。这个通道理论上来说是一个理想的通道,它使用了GPUDirect的方式能实现直接通过PCIe通道往外传输。一般传输可能会通过内存,做一次中转,然后再通过PCIe到ASIC卡里做数据传输,这样会经过两次传输,你就算做到最好,也会有至少一次的数据传输。

所以,相对来说,最理想的还是GPU硬编,但GPU有各种各样的限制,那这个到底怎么选呢?小孩子才做选择,成年人全都要。各种场景都会有适用性,像GPU渲染能力非常强,编码能力不足必须要通过其他软件或硬件支持。当然,如果英伟达或者其他显卡供应商,能考虑这种情况,把编码单元加强到和渲染单元的能力匹配,那我们都可以通过GPU来实现,在现阶段只能考虑都要了。

2.5 传输优化分析

互动云渲染——云原生渲染的初步探索


在传输方面比较重要的东西,首先关于延迟影响就是RTT,那影响RTT最重要的因素是距离,我们一般通过边缘节点覆盖,就近距离调度。当然这个因素也不一定是距离,但距离在很大程度上会反应这个问题。如果遇到距离近RTT也非常高,那只能作为历史信息,保存下来,做下次调度策略的选择因素参考。

第二个是网络传输,大家可能会有常规看法,在低延迟云渲染的情况下,我们发包要尽量快,编码出来的包采集完数据要把所有包快速往外发,这其实是有些同学常规的错误理解。因为编码出来的数据量瞬时会非常大,比如以1080p 60帧来看,实际上是16ms/帧,是有间隔性的,并不是从头到尾都是均匀的数据,中间可能还会穿插着I帧,整体数据量会非常大。不应该在低延迟的情况下把Pacing去掉,Pacing策略要针对场景做特定优化,减少Pacing对整体网络拥塞的影响。如果没有Pacing,真的会引起突发的卡顿,这个体验是非常不好的,也会影响到整体带宽的评估。

第三个是带宽评估算法,带宽评估出来才能真实决定码率,码率多少又决定画质。在WebRTC里,带宽评估算法有两种,TCC和REMB,REMB在接收端,但在官方已经被放弃了,TCC在发送端,云渲染正好就是数据发送端,适合我们进行深度的优化。TCC默认的策略不一定完全适合云渲染,我们可能要做一些策略的调优,比如敏感度,当码率突然下降,要快速地调低码率,减少延迟,带宽恢复是不是要快速,这些都要做参数调优,控制预测的准确性。


3. 互动云渲染


前面介绍的都是1v1的云渲染,但我们更多的探索是多人接入云渲染。

3.1 互动云渲染是什么

互动云渲染——云原生渲染的初步探索


上图是我们互动云渲染的探索方向,左图是应用的截图,主要和直播场景结合,比如主播在玩游戏时想和粉丝进行互动,目前手段还是很有限的。如果主播是用云渲染玩游戏,那粉丝在观看直播后觉得有兴趣,可能会通过上麦接力等方式,进入云渲染环境和主播进行云互动,包括权限申请,角色变化等等。

3.2 互动云渲染难点分析

互动云渲染——云原生渲染的初步探索


整体的逻辑架构图氛围两部分,一边是云渲染示例,下面会接入N个玩家,一边是各大厂商都会有的云直播,观众一般都会在各个直播平台观看直播内容。云渲染要和直播打通的就是混音推流能力,这时候的推流不能是简单的游戏软件内的音视频画面,还要把各个玩家语音数据做混音往外推。观众观看时,就能看到游戏内容和玩家之间的对话语音,他可以选择加入游戏进入到云渲染实例中,这时他看到的画面,就和主播实时看到的一模一样了,操作权限等能力也是一样的。

用户加入后,我们会遇到两个非常重要的问题,一个是用户玩家非常多,分布环境差异大,距离非常远,链路差异也很大,我们要怎么让每个用户都低延迟呢?第二个在于每个用户的带宽不一样,给到的码率也不一样,带宽可能还会产生波动,我们要怎样支持每个用户呢?这是我们互动云渲染中必然会遇到的两个问题,接下来和大家一起探讨一下解决方案。

3.3 互动云渲染的延迟控制

互动云渲染——云原生渲染的初步探索


前面说到,希望玩家能接入到云渲染实例中,但实际上我们不可能让所有玩家接入到同一个云渲染实例,一个云渲染实例只能在某一个地方,如果实例在北京,那北京的用户没有问题,但广州的用户想接距离就非常远了。同时也受到出口带宽的限制,当有几十、上百或更多用户时,单口负载是接受不了的,就要引入SFU做数据拆分。云渲染实例通过数据到SFU,每个玩家通过边缘节点的方式就近接入。

玩家直接链接SFU或者通过边缘节点链接SFU,会有两种延迟情况出现,我们要在这两者之间选择合适的,最终选择完也会成为历史参考信息,做下次调度的依据。另一方面,当玩家距离边缘节点非常近,但延迟非常不理想时,我们就要考虑动态链路切换,可能切换到别的边缘节点或者直接链接到SFU。如果要做动态切换,必须要依靠整体上报到调度系统中的数据,调度系统会实时汇总,做策略决策。

3.4 互动云渲染的码率控制

互动云渲染——云原生渲染的初步探索


解决延迟方面的问题,就要面临码率的控制。不同用户接入的边缘节点不一样,带宽可能也不一样。有些用户带宽10Mbps,有些用户带宽20Mbps,假设最低带宽都是比较理想的情况,那没问题,我们都用10Mbps,可能会有富余,但视频场景大概率在10Mbps以上看不出有什么区别,这时没必要用更高的码率了。可是有些用户带宽真的很低,那我们在不放弃他们的前提下,有这几种解决方式。

一种是引入分档转码,但这个肯定会引入额外的延迟,我觉得最少产生一个解码和一个编码的2帧延迟,同时还会提升成本。

另一种是编码上的探索方式SVC(Scalable Video Coding),普通的编码只有一层,SVC会把视频数据编码成多层,一般分三类:帧率级别的分层,假设原始视频是60帧,它通过分层编码的方式降到15帧依然能播,中间是跳了一些帧;分辨率的分层,可能1080p是一档,720p是一档,480p是一档,不同的层次解码出来不同分别率;画质分层,分别率不变,不同层次解出的画面是有差异的,最低层次的画面比较差,所有层次一起解,画面就比较好。这个看起来是非常理想,非常适合我们互动云渲染,每个玩家如果真的按照分层解码的话,这个问题就解决了。但实际上SVC需要在编码端和解码端上支持,同时因为我们是WebRTC,在Web上要支持,在浏览器上本身也要支持。目前在WebRTC这些能力的支持还是比较受限的。

另一种是Simulcast,有点像SVC,不一样的是源端编码编了多种码流,10Mbps的码流一条流,5Mbps的码流一条流,两条流一起上传SFU,通过选路的方式,带宽高的选择码流高的,带宽低的选低的。这种会引入另一个问题,它对编码的整体要求非常高,编码能力足够强就没有问题,但编码能力不够强就会造成一定的负担。当然这也是一种可选的方式,从整体策略来看,第一种和第三种会是我们的优先选择。

3.5 多实例的互动云渲染

互动云渲染——云原生渲染的初步探索


前面说的是多个人接入同一个互动云渲染实例,如果要把多人接入多个实例是要怎么实现呢?就是在原有架构上扩展一下,整体会类似一个房间的概念,每个用户自己操控自己的云渲染实例,中间有一个软件服务器。假设这是一整个游戏,每个云渲染实例是游戏中的不同角色,你操控的这个云渲染实例是虚拟人形象,和你真人的动作表情都能映射,并且这个虚拟人是在第一人称视角,你自己不能看到这些动作表情,但其他人都能看到,就有一点电影《头号玩家》的方式。

3.6 互动云渲染之上

互动云渲染——云原生渲染的初步探索


基于云渲染本身的能力,我们实现了数字虚拟人、Cloud AR、Cloud VR。AR、VR之前没提到,我们现在的AR、VR都比较依靠于设备,用户需要频繁地更新设备,但如果把这个搬到云端,用户本地只需要做解码能力的支持,网络带宽更新换代也是非常快的,那这样就可以实现轻客户端的能力,把所有渲染都放到云端。现在整体结合看是否就在真实地探索元宇宙的雏形。

以上就是我本次分享的所有内容,谢谢。


还可输入800
全部评论
作者介绍

LiveVideoStack

音视频技术社区

文章

粉丝

视频

阅读排行
  • 2周
  • 4周
  • 16周
热门视频

用互联网发展视角看元宇宙创新

龙明康/AI工程院常务副院长

单目3D人体姿态估计的挑战和探索

宋波/人工智能高级工程师