NVIDIA 初创加速计划,免费加速您的创业启动 了解详情
写点什么

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

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

    阅读完需:约 16 分钟

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

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


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


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


00:00 / 00:00
    1.0x
    • 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:455923
    用户头像

    发布了 56 篇内容, 共 26.2 次阅读, 收获喜欢 43 次。

    关注

    评论

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

    架构师训练营第二期 Week 13 作业

    bigxiang

    架构师训练营第2期

    Elasticsearch的基础分布式架构

    escray

    elasticsearch elastic 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

    好书推荐--大数据日知录(深入理解大数据的必备书籍)附电子版下载

    五分钟学大数据

    大数据

    第一周作业

    Geek_ce1551

    Java 程序经验小结:性能优化手段之避免创建不必要的对象

    后台技术汇

    28天写作

    架构师训练营第三周作业

    跳蚤

    十三周-作业

    水浴清风

    有关单例模式的总结

    跳蚤

    没有源码调试!生产环境如何排除和优化 JVM?

    码农架构

    Java 架构 并发编程 JVM

    架构师入门感悟之十三

    笑春风

    开创我国区块链定制化制造新时代

    CECBC

    区块链

    Week13作业

    lggl

    数据应用总结二

    Mars

    第八周 性能优化(二) 作业 「架构师训练营 3 期」

    胡云飞

    产品经理训练营笔记-认识产品经理(下)

    .nil?

    产品经理训练营

    CentOS安装和使用FFmpeg

    王坤祥

    ffmpeg 视频处理

    Week13 总结笔记

    lggl

    Google 搜索引擎是如何对搜索结果进行排序

    Mars

    中台 | 中台到底是什么?

    xcbeyond

    中台 中台架构 中台的由来 28天写作

    区块链世界的中心应该是什么?

    CECBC

    区块链 区块链数字经济

    第一周作业

    大熊猫

    第八周 课后作业

    简简单单

    产品经理JD调研备忘录

    学习高手song轻松

    产品

    Soul网关源码阅读(五)请求类型探索

    Java 源码分析 网关

    架构师训练营第二期 Week 13 总结

    bigxiang

    架构师训练营第2期

    又见拉布拉猪

    Justin

    28天写作 灌水 减压

    今天听课想到的小事

    Nydia

    第八周 学习总结

    简简单单

    重学JS | Proxy与Object.defineProperty的用法与区别

    梁龙先森

    大前端 编程语言 28天写作

    极客大学·产品经理训练营·第一章作业

    二大爷

    产品经理 产品经理训练营

    从炒作到风口,谁在引领中国区块链浪潮?

    CECBC

    比特币 区块链

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