W3C

Web 中文兴趣组会议

2022年9月6日

基于RTC的互动直播实践、优化和思考

饶明佺(中国移动咪咕公司)[演示文稿]

现场纪要

饶明佺:

各位现场的同学,大家下午好!我是中国移动咪咕公司的饶明佺,主要是负责音视频直播互动研发,很高兴和大家做交流。

今天分享主要分为三部分,第一部分是简单过一下我们的应用场景,引出互动直播整体架构,我们做了哪些优化,最后是对下一步的思考。

第一个就是典型应用,跨时空的互动。在这里面分类主要是真人对真人,在现实中用互动直播的技术做交流,[多媒体演示]这是相关的场景。

多个线下的朋友约在一块儿看一场球或者是看一场电影,可以是在APP里看场球赛,也可能是在VR的视频里,在虚拟的观影厅看电影,这涉及互动直播,典型会议联线,再加上推流的传输。云观众,主要是有一些创新的设计,在看比赛的时候,观众图像可以上到观众墙,大家可以看到,可以满足个人的需求。

云打call,比如联线进来的人员,为支持的球队加油,可以根据声量的大小,可以打分,这就打破了在家里干巴巴看比赛的场景,可以更多的参与、更多的互动。游戏直播也是一样,典型的游戏主播的直播,以及开黑对战,几个朋友约在一起,可以在线上一起玩游戏,这就打破了原来的空间或者时间,特别是在疫情情况下,是有很多限制,这种应用就可以打破限制,这是更现实的场景互动。

第二个是面向虚实融合的互动,现在比较火的元宇宙相关的,这也是三个场景。第一个是虚拟演播,这是咪咕在冬奥会期间做的谷爱凌虚拟人,提前做好了超写实的数字人,并且是通过动捕驱动数智人和主持人互动,就形成一个效果,实际上谷爱凌还在比赛,演播间又出现了超写实的数字人,在演播间里,向赛场上的谷爱凌加油打call,也是非常有意思的场景。

第二个场景,业界很多人在做虚拟会议,主要还是3D构建的场景,去构建会议会场、会议室,还有就是个人的形象,是3D形象或者是虚拟数字人的形象,也涉及到音视频的互动,也涉及到空间的内容。

第三个是云上博物馆,业界这个技术也比较成熟,各个政府也在做云上政府,构建了虚拟的云上场馆,不需要到现场就可以参观博物馆,而且有虚拟导游,虚拟导游可能是真人,通过远程联线的虚拟人接入进去做导览,这也涉及到互动直播的事情。

这里的应用案例,一个是现实世界,一个是虚实互动的场景。

在这几个场景里都会用到互动直播的能力,在这里,不同的厂商实现的时候可能有一些细微的差别,整体上差不多是这样的意思。从右往左看,调度非常明确,所有要参与互动的人,要接入调度到哪个互动直播的边缘节点, SFU或者是MCU的节点,接入之后就可以做互动,接入过程中也有涉及SFU的模式,所有人都可以互相听到所有人,去拉所有的流。

还有一种模式是MCU,也就是参与者5(见PPT)的模式,上行一路,下行是合并的流,主要是面向弱网环境下或者是不需要做实时互动下,参与或者听就行,总之不需要那么强参与,可以通过这种方式。

或者对其他人的流不需要这么强控制的情况下,可以把其他人音视频的流合成一路下行下来,这是典型音视频的互动场景。在这样的互动场景里,刚才提到的云包厢或者云游戏里,就涉及到需要把一个外部三方视频流或者是电影的流,或者是游戏流,推到互动的session里,所有人都可以看到电影的场景,可以基于这个做互动,或者把一个MV推到session,大家都可以看到,这是第五步。

在这里都是参与互动的,还有一种是需要对整个互动画面拉取出来,通过节目制作或者是导播之后,给不是session(会话)的互联网用户看,这样可以通过节目导播,通过CDN做互联网分发,就形成了互动直播的整体架构。

从架构里可以看到涉及的点非常多,包括调度、互动、推流、节目制作、分发,还涉及到SDK,我们看看会涉及哪些方面的技术栈。

互动直播里涉及的技术图谱,这里只列了一部分,涉及音视频,音视频的采集、播放,采集之后先编码,编码之后处理,处理之后传输,然后再拉出来解码、渲染,包括网络传输,在这里面都包括了。还涉及到虚实融合的数字人、全息影像、VR、AR、4K、8K等技术,加上这些才能达到比较好的效果。

前面的采集以及处理每个领域基本上要深入下去,都是一个非常专的垂直领域,都需要比较多的积累才能达成比较好的效果,像编解码,可能通过编解码业务就可以上市了。音视频的处理涉及到AI的处理,也是非常专的领域。网络传输会涉及到拥塞控制等等,也是非常专的领域。在终端上,手机端通过App或者H5就能够满足,但是对互动直播,因为它还包括了传统产业的设备,包括IoT设备、VR、AR设备都会涉及,所以设备的兼容性是很大的工作。

还有大数据技术,如果这一套系统需要很好的稳定可靠的运行,数据分析少不了,会涉及完整的大数据技术,像ETL、数据分析、可视化等等。

还涉及云原生的技术,没有分布式的架构做根本不可行,或者做完之后可维护性或者后面升级迭代上线有很大的瓶颈和障碍。

人工智能方面领域也非常专,像语音识别、人脸、智能审核、视频超分、背景抠图、降噪、智能编码等等。

平台开发技术还好,可能分布式平台都可以做,除了CDN比较专。

其实,从这里可以看到涉及的技术栈非常多,要做得非常深入非常难,对公司的要求非常高。前面提到了WebRTC,出现了WebRTC之后,上层前五个方面基本上都覆盖了,而且WebRTC从最新的版本出来之后,整体的采集效果、编码、传输的控制等等,从通用的层面来说,它的效果做得很不错,一般场景里基本上都能应付、满足,但是对于刚才提到的兼容性以及特定条件下要做优化可能没有考虑,但是对通用基本面的东西,基本上都具备了,能够提供很好的支持。

所以,今天讲的系统是基于WebRTC的技术,做的一个互动直播的系统平台。这里简单介绍一下做了哪些方面的优化。

分为两部分:一部分是对WebRTC,另一方面是对系统层面。

在WebRTC,我们是从WebRTC全链路做简单的介绍。Web RTC涉及的七个环节基本面上的东西都有了,但它要组成面向现实场景的解决方案,或者满足具体的业务要求,还有一些需要优化的,这里简单介绍一下,对于采集,WebRTC也涉及到buffer的采集,怎么通过纹理的方式做句柄的移交就可以做处理,可以保证采集利用。

图像的采集,像相机参数的调节,为了更丰富的应用,可以对这方面进行扩展支持。

在分辨率对齐,也涉及到设备的兼容性,比如安卓,都是16字节去对齐基数,如果不是按照这个对齐,就可能会出现花屏。对于主流的机器都可以,但不主流就会出现问题,这些都需要积累数据去应对,包括多采样率、文件采集支持。

刚才提到的云包厢,需要把电影、云游戏的视频流放到WebRTC的session里,这就涉及到需要通过文件的方式把文件解码,把它处理成裸流,传递给WebRTC,以便满足更丰富的业务需要,不然就会变成简单通过摄像头采集的方式才能做互动。

前处理上,这些手段也比较常见,常见的美颜、滤镜、视觉识别以及背景替换等等,都是这个范畴。像3A优化,耳机的时候可以把3A关掉,还有前处理的支持。

编码上,对WebRTC本身来说提供了比较好的编解码算法,端侧很难区分效果。所以,需要对编解码做扩展,现在我们做的主要是两种:一种是根据黑白名单的方式,对于已知的一些硬件,比如正常的硬件会更好,但是有些设备的支持上有问题,这时候就要设置黑白名单,确保不能因为设备本身不支持,导致一些灾难性的问题存在。

还有一种方式就是对WebRTC进行扩展,引入一个打分系统,这样就更智能化的方式,对目前还没有识别出来的不支持硬件,可以做相应的优化。

还有一些是编码参数,同样也涉及在不同使用场景里,对画质要求不一样,在面向直播和会议的场景下是完全不一样的,如果对于会议的场景,比如在编码过程中GOP可以设置得很长,或者对编码要求不高,对直播来说要考虑稳定、画质,那就不能GOP设置过长的处理。

上面也提到了兼容性,有些手机硬编上可能会有问题,这是从兼容性考虑。

说到这里,有一个很深的感触,最常见的就是手机或者浏览器,主要是手机,其实不同的硬件差别也非常大,包括是不是支持硬编,非常期望有一个业界的公共数据库,不同的手机硬编或者是硬解支持到什么程度、有没有兼容性的问题,我感觉现在业界的厂商都把这些厂商从头到尾、从零开始做了一遍,积累一套自己的数据库,这是对编码。

在传输上,对互动直播或者WebRTC本身是重中之重,也要做相应的优化,像PLI和FIR,需要控制转发频率,对频率进行控制。

不然本身就是弱网的情况,还不停请求重传,那就卡“死”了。

对JitterBuffer和NetEQ是通过渲染拉长,让Buffer有更多的数据,保证视频播放的连续性。NetEQ也是一样,调整音频播放算法,这样基本上也是一样的,能够在用户没有感知到的情况下去降低播放的速度,把播放的时间拉长,在缓存里能有更多的缓存数据,这样整体会更流畅。

还有就是SimuCast、SVC,视频推流上去要求是很高画质的流,对拉流端取决于网络,拉低码率的流,这就需要SVC达到比较好的效果,包括推流的码率自适应,也是非常典型的,做这一块都会做这方面的事情。

后面也是类似,解码、后处理、渲染,考虑网络的情况,考虑设备的兼容性情况,怎么样更高效,怎么节省C端的资源,特别是渲染,像现在元宇宙虚拟会议这些场景,很多对机器资源占用比较多,我们要考虑当前资源情况,考虑当前是由CPU或者GPU的方式做处理、做渲染,保证用户端的体验是最好的。这个体验一个互动的流畅性,还有一块是所看到画面的画质,基本上这里只列了一部分,还有更多更细致没有列在这里,这是对WebRTC本身的优化点。

还有系统层面,除了典型的就近之外,还要可用性、质量情况,还有三网,移动的网络,移动Wi-Fi和手机连通的网络效果更好,都会做接入优化。

还有媒体、混流转推、服务高可用,QoS、QoE也是互动直播链路里必不可少的,这一个提前发现问题,一个是发现问题之后可以快速定位,还有就是这方面的数据可以获得调度接入的用户互动情况,获得视频质量的情况影响实时调度,这就是对系统层面的优化。

优化主要讲这两个方面,想表达的是WebRTC提供的公共系统本身非常强大,要真正达到规模化可用、工程化解决方案级的系统,还需要做一些比较多的优化,才能满足实际的业务需要。

最后一部分是对互动直播的趋势思考。

现在又出现了VR、AR、数字人,包括3D的数据、全息的数据,数据密度越来越大,本质上就是从低维往高维转变,这就会涉及到体积视频、空间音频,就涉及更大码率,一块是应用要做优化,还有就是对开源或者标准化,要相应的支持对应的更高码率或者更高维度的信息。

第二个是全感官,原来只是视听,现在又出现了触觉、嗅觉、体感设备,还有下一步马斯克搞的脑机接口,这涉及到算法和数据量会更多,这涉及到传感设备、融合算法,就需要支持更通用的数据类型。在传输上,要更流畅的传输。

比如对视频、音频或者文本,对它的时延忍受程度完全不一样,在文本时代,1秒钟都能忍受,但是对于视频来说,视频有一点点延迟就会感受到,相对来说音频的忍受程度更低,前面有同学提到远程一起K歌或者远程表演弹钢琴,这方面的延迟要求会更低,但是,涉及体感设备,触觉、味觉的时延程度更低。体感设备有一些卡顿,数据没有传过来,身体的感觉更明显。

元宇宙主要是说一切新的视频相关的类型和相关处理,像超写实的数字人或者是AR、VR、全息,涉及渲染引擎、虚拟演播技术,还有刚才提到的WebRTC,全流程都有,新的类型要在这里面比较好的支持,就有一些更个性化的扩展,确保它有更好的支持。

在现在的实际过程中,稍微高一点的码率,只要涉及更大码率的格式支持,就需要做一些比较大的手术,才能确保现在的系统能够很好的支持,或者业界专门提供PaaS服务的,基本上是基于一个私有协议,包括传输,都是通过私有协议完成。通过WebRTC一整套,或者像前面提到的WebCodecs、Web Transport、WebAssembly等等,现在还属于相对小众前沿的东西,再往后可能会成为标配的东西。我认为标配的东西是需要标准,开源的东西要能够支持的。

还有是全场景,从目前来看,一开始互联网视频非常常见,现在随着2019年开始,整个从泛娱乐、协同办公、媒体上扩展到全领域的数字化场景,这就有更多需要考虑的点。

简单的像场景化的封装,或者工业使用场景里对延时、可靠,要求会更高。现在是否已支持这种场景,因为我认为大部分是通用支持,要考虑哪些方面的迭代、优化,才能更好的支持,这就涉及到标准化以及规范化,才能确保更稳定可靠、更好效果。

这些都是我们在实际中碰到的问题,以及对互动直播技术业界发展、后面趋势我们的想法和思考。

以上就是我的分享,非常感谢大家!


返回[会议总结页面]获取其他话题的会议纪要。

若您对上述内容有任何疑问或需进一步协助,请联系:讲者饶明佺 <raomingquan@migu.cn> 或会议主办方 W3C 北航总部 <team-beihang-events@w3.org>。