【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

专访火山引擎 | 探秘抖音同款实时音视频技术,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:455918
    用户头像

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

    关注

    评论

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

    DDD领域驱动设计实战(一)-领域模型、子域、核心域、通用域和支撑域等基本概念

    JavaEdge

    12月日更

    Vuepress 2.X + Element-Plus 的基本使用

    AR7

    typescript Vue3 vuepress Element Plus Vuepress2.X

    Flink 实践教程-进阶(4):TOP-N

    腾讯云大数据

    flink 流计算 Oceanus

    阿里云(腾讯云)服务器使用宝塔,搭建Python环境,运行 django 程序

    梦想橡皮擦

    12月日更

    Dart 条件语句

    坚果

    flutter dart 28天写作 12月日更

    如何在Linux系统中安装Docker?

    Ethereal

    Docker

    比较PostgreSQL与MySQL两大开源关系数据库管理系统

    Ethereal

    MySQL 数据库 postgresql

    百度搜索中台海量数据管理的云原生和智能化实践

    lecury

    云原生 数据架构 架构演进 技术创新 百度搜索

    模块七作业:王者荣耀商城异地多活架构设计

    dean

    架构实战营

    架构实战营-模块七作业

    随风King

    「架构实战营」

    21《重学JAVA》-- 集合 (三)

    杨鹏Geek

    Java25周年 28天写作 12月日更

    实用机器学习笔记二十一:集成学习之Bagging

    打工人!

    人工智能 机器学习 学习笔记 集成学习 12月日更

    架构实战营

    ren

    读《思辨与立场》-07-02指导原则

    wood

    28天写作 批判性思维 思辨与立场

    MySQL从入门到入魔(03)

    海拥(haiyong.site)

    MySQL 数据库 28天写作 12月日更

    【CSS 学习总结】第一篇 - HTML 的语义化

    Brave

    CSS 12月日更

    妙解RIP协议和OSPF协议的优缺点,建议收藏!

    Ethereal

    网络协议 OSPF 网络技术 网络技术联盟站 rip

    [Pulsar] TopicPolicy的同步过程

    Zike Yang

    Apache Pulsar 12月日更

    Prometheus Exporter (三十三)BIND Exporter

    耳东@Erdong

    Prometheus 28天写作 bind exporter 12月日更

    Flink 实践教程-进阶(3):窗口操作

    腾讯云大数据

    flink 流计算 Oceanus

    一年一度绩效考核

    搬砖的周狮傅

    绩效管理

    混沌工程之 ChaoBlade 的实现原理

    zuozewei

    混沌工程 ChaosBlade 12月日更

    百度智能云以知识智能化驱动产业智能化升级

    百度大脑

    基于流计算 Oceanus 和 Elasticsearch Service 构建百亿级实时监控系统

    腾讯云大数据

    流计算 Oceanus Elastic Search

    为什么 SASE 很重要?

    devpoint

    SD-WAN sase 12月日更

    语音输入还是打字输入

    将军-技术演讲力教练

    感情是麻烦出来的(21/28)

    赵新龙

    28天写作

    【大咖直播】Elastic 企业搜索实战工作坊(第二期)

    腾讯云大数据

    Elastic Search

    为Amazon DMS数据库迁移任务建立自动化监控机制

    亚马逊云科技 (Amazon Web Services)

    Data

    身兼数职的Amazon DocumentDB,还有什么不为人知的功能?

    亚马逊云科技 (Amazon Web Services)

    Data

    科技助力新冠防疫——构建 COVID-19 知识图谱

    亚马逊云科技 (Amazon Web Services)

    Data

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