【FCon】聚焦金融行业在数智化的全面革新,一线的金融数智化实践干货 了解详情
写点什么

专访火山引擎 | 探秘抖音同款实时音视频技术,RTC 如何从优秀走向卓越

  • 2022-12-01
    北京
  • 本文字数:4863 字

    阅读完需:约 16 分钟

专访火山引擎 | 探秘抖音同款实时音视频技术,RTC如何从优秀走向卓越

6 月 17 日,极客时间《企业级 Agents 开发实战营》正式上线,10 周掌握企业级 Agents 从设计、开发到部署全流程。

社交娱乐、直播点播、在线教育办公等场景的广泛应用,催生 RTC 技术的快速发展。从曾经炙手可热的概念到如今逐步走向完善,当前 RTC 的发展已逐步进入从 90 分到 100 分的精进阶段,而越是到达这个阶段,每向前一步越是不易。


极端恶劣的环境下如何优化用户的音视频体验?全球化背景下,如何保证实时性并且进一步降低延时?在不损失用户体验的前提下,如何实现降本增效?火山引擎 RTC 经历了过亿级 DAU 的产品的持续打磨与完整检验,将其沉淀的关于音画质提升、架构设计、抗弱网、机型适配等技术成果打包成「抖音同款 RTC」产品及服务。


近期,QCon 全球软件开发大会 InfoQ 有幸采访到了火山引擎 RTC 产品负责人杨若扬,带大家探秘抖音同款实时音视频技术。


00:00 / 00:00
    1.0x
    • 3.0x
    • 2.5x
    • 2.0x
    • 1.5x
    • 1.25x
    • 1.0x
    • 0.75x
    • 0.5x
    网页全屏
    全屏
    00:00


    InfoQ:若扬老师您好,欢迎您来到 Qcon,很高兴采访到您,首先请您先做一个自我介绍并介绍一下火山引擎。

     

    杨若扬:大家好,我是杨若扬,我目前就职于字节跳动,在负责火山引擎 RTC 产品线。火山引擎它是字节跳动旗下的一个云服务的平台,火山引擎把字节跳动在它快速发展的过程中所积累下来的技术能力,技术能力增长的方法和工具开放给外部的企业,帮助企业去实现快速的增长。

     

    InfoQ:近年来 RTC 在快速地发展,您认为 RTC 目前是处于怎样的发展阶段呢?以及它面临的挑战有哪些?

     

    杨若扬:我认为 RTC 目前属于一个从 90 分到 100 分这样的一个不断精进的阶段。主要体现在我们对于两个极致方面的追求。一个是在针对恶劣环境不断地去适应。所谓的恶劣环境是指那种极端的弱网或者是极端的弱设备。我们要追求让尽量多的用户,哪怕他的网络不是很好,也能够去获得比较好的视频体验,这就需要我们不断地去打磨更强的算法。

     

    另一个是来自于业务侧不断提升的需求。比如说业务需要做云游戏,要做 K 歌合唱或者是远程的操控,这就需要更低的延时。再比如说业务需要做那种 720 度的全景视频实时传输,就是需要 4K 到 8K 分辨率,以及 30 帧到 60 帧的帧率。这就意味着它的传输的数据量会非常的庞大,这也就对我们的传输算法有了更高的挑战。

     

    InfoQ:这一阶段技术上有哪些最新的突破呢?

     

    杨若扬:技术突破在于所谓可以用的技术非常多,但是我们会关注如何去选择和应用这些技术。这里我想分享的是我们的一个方法论。就是不断地通过实验和数据观察来挑选真正能解决我们上面这些问题的技术,简单说,就是我们常说的 A/B Test。因为只有真正能够让业务实现增长的技术,我们才认为它是一个有价值的演进方向。

     

    InfoQ:了解。您刚刚也提到对于 RTC 技术来说,保证实时性是一个非常关键的技术点。尤其是全球化这个背景下,火山引擎是如何保证实时性呢?

     

    杨若扬:保证实时性主要是去解决延时的问题。我们解决延时包含两个方面,一方面我们会去搭建一个全球的实时传输网络,通过软件定义的网络以及我们分布全球的传输节点,来提升中心网络、核心网络的传输速度。另一方面,是我们所谓的最后一公里的网络,就是用户自己的网络和自己的设备上面连接到我们的边缘节点的这一段,这一段相对是不可控的,所以它只能依赖我们的传输算法。

     

    说到全球化,基于上面这个架构我认为有三个关键的突破。第一,是我们的多中心的网络架构,多中心能够让我们在全球范围内保证达到最快的访问路径。第二,是边缘下沉,我们让尽量多的计算在边缘完成,这样它就会减少全球网络同步的带来的延时的消耗。第三,我们称之为统一接入,就是我们会把信令和媒体去使用同一个网络连接。这样一个是可以大大的降低网络连接上最后 1 公里网络的损耗,同时也能够让媒体和信令达到一个更好的一个同步性。

     

    InfoQ:在全球化的这个场景下,非常典型的一个场景就是近期的世界杯,在抖音可以实现与好友一起“边看边聊世界杯”,火山引擎 RTC 为该功能也提供了支持。该功能可支持百万人同时在线,并且支持多人在麦,能结合这一场景聊聊火山引擎在多人互动架构上是怎么演进的吗?

     

    杨若扬:RTC 的多人互动其实要克服一个核心的挑战就是信令风暴。因为 RTC 的推拉流的关系非常复杂,所以我们会提供一个信令,通过信令的管理能力去降低开发的复杂度。但这样复杂度由我们来解决。这个信令风暴核心的挑战在于,一个是增加观众的人数,一个是增加开麦的人数。

     

    第一阶段我们是通过一个隐身用户架构去让观众的人数能够达到 100 万。第二阶段我们是通过我们核心的一个技术即服务端的音频选流,让开麦主播人数能够达到 1000。第三阶段,我们是在千人开麦的基础上,我们演进到了万人上麦。但是这里面开麦的人数和主播人数其实没办法两边同时都达到一个最佳的、最高的状态。因此我们第四个阶段,我们现在是把信令的管理和音视频流进行一个更深度的一个解耦。这样两边都能同时达到一个最佳的状态,观众的人数未来就可以达到没有上限。

     

    InfoQ:在抖音的业务中有大量涉及音视频的特效,在互动特效算法与音视频的结合上面,火山引擎有哪些经验可以跟大家分享一下?

     

    杨若扬:其实视频特效和 RTC。从需求侧来说是非常常见的组合,抖音上的这些特效本身也做得非常的有趣,质量也非常高。但是它带来一个很大的挑战,这两块都是性能消耗的大户。也就说会有很多的用户,如果在手机上要同时跑特效和 RTC 它的性能就会扛不住,就会达不到最好的效果。

     

    我们分析下来,其实它这两块都是音视频,所以我们认为它会有很强的融合,优化空间会非常大。因此我们研究之后,找到了至少三个方向的优化。

     

    第一,就是我们会减少音视频的拷贝的次数,这个其实是对于性能降低的最直接的优化。

     

    第二,是统一降级。RTC 会有性能降级,如果检测到这个设备的性能不够,它会去做一些降级。其实特效也会去做。但是如果说特效和 RTC 它不是采用共同的降级策略的话,它其实是没有办法达到一个最佳的效果。并且 RTC 其实是在特效之后的,所以如果是分离的话,可能 RTC 拿到的数据和它所剩下的性能已经不够他去做降级了。因此我们把它整合在一起,达到一个统一降级的策略,就可以让 RTC 和特效能够同时达到一个最佳的一个适配性。

     

    第三,我认为是共用算法。用现在很多特效里面其实都会用到一些算法,最主要的可能是个人脸的检测。RTC 也会用到一些比如说人脸的这样的算法。如果是两套算法,虽然可能都是检测人脸,但是它始终在检测上会有没有对齐的问题,就会让它效果打折。我们共用一套算法,这些效果也能够同时达到最佳的效果。

     

    InfoQ:火山引擎也是一直说要推动 RTC 从 90 分到 100 分,今年有一些什么样新的技术和新的功能上线呢?

     

    杨若扬:除了我们专题里讲的,如何帮助抖音追求极致,其实我们还为字节旗下的其他的很多业务做了很多的创新。首先我们为飞书做了屏幕共享,屏幕共享大家都了解,我们做了屏幕共享的智能编码模式。其实屏幕共享的视频画面内容会比我们平时拍脸的画面内容要复杂很多。所以我们针对它的内容去决定,实时地去调整它的分辨率和帧率。也就说根据它的内容在需要高清的时候我们会让它高清,它需要实时的时候我们会让它更流畅,这是我们在屏幕共享上的一个创新。

     

    另外我们还给 PICO 做了一个 8K FOV 的视频传输。还有我想讲一个我们针对汽车平行驾驶,我们提供了一个纯视频的一个超低延时的视频传输的一个策略。

     

    今年汽车上的 RTC 应用突然涌现出来,一方面是智能驾驶的概念现在落地了。就会要求 RTC 有几个特性,最主要是低延时,它通过低延时可以做一些远程的操控,但目前的远程操控可能主要还是集中在一些非驾驶的应用上。第二个就是它的视频的传输,你可以在汽车之外看到车载的摄像头给你传过来的视频画面。

     

    InfoQ:您认为火山引擎 RTC 和业界其他方案相比最大的优势是什么,能否总结一下?

     

    杨若扬:我总结下来,我认为是四个字,就是业务视角。业务视角可以从三个方面去体现。我觉得首先是数据驱动。我们所做的 RTC 的指标,从来不是为了去证明我们的技术有多厉害,而是说我们会把我们的指标和业务的指标进行联动。刚才我提到我们做 A/B Test,我们的目标最终还是帮业务去实现增长。我认为这是我们最大的区别,我们是从业务的角度去驱动优化方向的。

     

    第二,我认为是全链路优化。因为从业务角度来看,业务其实只会关注最终的结果,而 RTC 它的全链路其实非常长,链路上的每一个环节的好坏都会影响最终的效果。因此我们不会去放弃任何一个环节的优化,比如我们从视频采集开始,我们就对画质进行优化。

     

    第三,我认为是最佳实践。因为 RTC 目前的使用方式还是非常复杂的,有些时候你要达到一个最佳的效果,其实是需要业务的实现去解决的。但我们从来不会认为那一部分的工作完全是业务的工作,我们会去充分理解业务的需求,帮助业务去设计一套实现集成的方案,帮助他们一起去实现,并且一起去观察最终的效果。这是我认为我们最大的不同。

     

    InfoQ:了解,您刚才也提到了业务驱动这样一个关键词,业务驱动的话与用户体验是强相关的,用户体验在业界来说是不太好衡量的,你们在衡量用户体验这方面有哪些创新?

     

    杨若扬:你说的没错, RTC 衡量用户体验的指标业内还是没有形成标准。我们一般都会去用 QoS 指标,但其实 QoS 指标也没有统一。首先我们在定义 QoS 指标的时候,我们会去以用户的行为为颗粒度,这样确保我们的 QoS 不是纯粹反映我们的一些技术上的片段,它还是会去和用户的一些行为去结合。这样的指标它会比较客观。但它也会有一个问题,就是它始终无法覆盖所有的用户的体验的情况,总会有一些用户体验不好的问题,其实是落在指标定义之外的。

     

    因此我们也会去看另外一个指标,我们叫 QoE,QoE 会由很多的数据来源组成,其中很大的一部分就来源于用户的主观的评价。用户的主观评价它的特点就是真实的反映用户的体验,但是它有一个问题就是它会存在幸存者偏差。一定会有很大一部分的用户其实体验不好了,但是他不做任何的反馈。基于这样的两个特点,我们去设计了一套基于 QoS 和 QoE 的一个联动的数据分析方法。我们是通过 QoE 来去验证和打磨 QoS 的指标,让我们的 QoS 指标不断地能够去更加真实地去反映我们之前所遗漏掉的那些用户的体验。然后我们再用 QoS 指标去消除幸存者偏差的问题,这是业界独创的一套数据分析的方法。

     

    InfoQ:在保障用户体验的前提下,有没有一些降低成本的考量呢?尤其是现在的经济形势其实不是特别好。

     

    杨若扬:因为 RTC 的成本主要来源于云端的资源的应用,如果降低云端资源的成本,它就势必会带来 RTC 的体验下降。但是其实降本我们认为也是并不是没有办法的。我们充分研究之后,发现其实从 RTC 的技术架构方案上去做降本的优化,它所带来的收益远远大于我们在资源上的降低。

     

    举个例子,我们有很多的云端后处理,像云端录制和云端的截图、云端的转直播等等。这些云端的后处理很多时候往往会同时使用。我们会对这个任务进行合并,这样会大大地减少云端拉流的数量,这个减少的数量是成倍的。成倍地减少了拉流的数量,它就会成倍地去减少对资源的运用。这种类型的降本我们认为它是非常有效的。

     

    除此以外,我们还有端云一体、合流转推,还有消除静音帧、消除黑帧等等。这一类我们统称为技术方案的降本。通过实践,技术方案的降本在帮助抖音的实践过程中,在用量没有下降的情况下,我们最终帮抖音节省的 RTC 的成本大概是原来的 50%。

     

    InfoQ:面向未来 RTC 会朝什么方向发展呢?以及火山引擎在未来的发展上有什么样的规划呢?

     

    杨若扬:首先 RTC 未来的方向它一定是会朝着更低的延时、更加的高清、更加的流畅这些方向去演进。除此以外,我认为目前 RTC 行业还有一个很大的一个痛点没有解决,其实刚才也都提到过,它的使用复杂和它的指标标准问题。其实归根结底是因为目前 RTC 还没有形成标准协议。所以我认为未来的 RTC 还会往标准化去发展。

     

    因此,火山引擎 RTC 现在也在引领一个全新的 RTC 概念。就是基于标准协议的 RTC,我们推出的是 WTN 这样的一个概念,WebRTC 传输网络。它是能够使用标准的 RTC 协议,采用国际标准去适应更多的 RTC 的开发。也能够让更多的 RTC 开发者参与进来,并且未来我相信还能够实现不同厂商之间的 RTC 的互联互通,这样会形成一个众人拾柴火焰高的这样的一个行业局面,也能够让 RTC 往一个更好的方向去发展。


    2022-12-01 15:455997
    用户头像

    发布了 57 篇内容, 共 27.4 次阅读, 收获喜欢 44 次。

    关注

    评论

    发布
    暂无评论
    发现更多内容

    第一周架构方法-周总结

    潘涛

    第十一周课后练习

    晴空万里

    架构师第一周总结

    永不言弃

    架构师训练营第一周作业-学习总结

    阿德儿

    第九周 作业1

    Mr_No爱学习

    第九周-学习总结

    Mr_No爱学习

    Spring 源码学习 12:registerBeanPostProcessors

    程序员小航

    Java spring 源码

    [架构师训练营] 食堂就餐卡系统设计

    Fango

    架构师训练营 4 期

    系统安全高可用总结

    Mars

    第六周命题作业

    cc

    架构师训练营 1 期:大作业(一)

    piercebn

    架构师训练营第 1 期

    架构师训练营第 11 周课后练习

    菜青虫

    架構師訓練營 大作業一

    ilake

    分析了2020年3万多条的微博热搜,我看到了什么

    CoderW

    Python 程序人生 爬虫 后端 微博热搜

    架构师训练营第 11 周学习总结

    菜青虫

    SAML和OAuth2这两种SSO协议的区别

    程序那些事

    权限系统 OAuth2 程序那些事 SAML SSO

    Week11总结

    lggl

    物联网基础知识整理及实战

    garlic

    物联网

    上地七街

    潇潇雨歇

    北极科考:我们为什么要在北极呆上一年?

    脑极体

    甲方日常 78

    句子

    工作 随笔杂谈 日常

    系统高可用原因分析&方案

    Mars

    架构师训练营第六周课后作业

    万有引力

    架构师训练营第一周作业-命题作业

    阿德儿

    食堂就餐卡系统设计

    永不言弃

    架构

    指令重排序、内存屏障很难?看完这篇你就懂了!

    Java鱼仔

    Java 程序员 面试 JMM 指令重排序

    架构师训练营第十一周作业

    丁乐洪

    数据爬虫

    RainGod

    爬虫

    LeetCode题解:264. 丑数 II,暴力法,JavaScript,详细注释

    Lee Chen

    算法 大前端 LeetCode

    架構師訓練營 大作業二

    ilake

    第六周学习心得

    cc

    专访火山引擎 | 探秘抖音同款实时音视频技术,RTC如何从优秀走向卓越_文化 & 方法_张雅文_InfoQ精选文章