RTC技术|弹幕互动玩法方案&低延时传输引擎的体验优化

#1

抖音创新玩法背后的RTC技术应用

——弹幕互动玩法方案实践

编者按

随着互联网技术的不断发展，直播不再只是主播的独角戏，而是一个充满实时互动的娱乐生态系统，其中直播弹幕互动玩法作为一种创新的方式正风靡直播平台。火山引擎融合云游戏服务的强大算力和RTC的先进音视频能力，助力抖音快速增量并拓展直播创新玩法。LiveVideoStackCon 2023 深圳站邀请了火山引擎的郭健，为大家分享弹幕互动玩法背后的探索和实践历程。

文/郭健

整理/LiveVideoStack

大家下午好，我是火山引擎RTC商业化解决方案团队的负责人郭健，我今天分享的主题是抖音创新玩法背后的RTC技术应用。

本次分享分为三部分：首先向大家介绍抖音当前的RTC创新场景和趋势，随后重点讲述其中热度较高的弹幕互动玩法的方案演进，最后说明其在业务应用中的挑战与实践。

01

抖音上的RTC创新场景和趋势

互动PK、聊天室、在线KTV、一起看系列是抖音直播热门的四大RTC互动场景。

互动PK是最经典的直播互动场景，也是迭代最频繁的业务之一。随着业务层从双人、多人到团战、跨房团战，场景越加复杂，参与用户越来越多，我们及时进行了网络传输、性能和流管理的相关优化，以提供更好的体验；

聊天室是直播间多人互动场景，启用时屏幕布局支持九宫格、焦点放大等不同的布局。针对该场景我们采用了依据连麦人数调整推流分辨率的动态方案，优化用户的观看体验。

在线K歌的热度目前正持续走高，已从初期单人独唱发展到支持多人视频大合唱。该场景下声伴同步、超低延时、多端对齐、音质优化是重点优化方向。

一起看是个比较有意思的场景，在使用时支持与好友连线共同观看趣味短视频，或世界杯期间的球赛直播或是一些爆火的短剧，还原线下边看边聊的体验。我们针对该场景中回声消除和远端人声响度不足等问题进行了音频托管、音频闪避等优化，提升用户体验。

后续我们也将持续优化音视频体验、持续探索新的玩法，实现进一步的业务增长。

在开发以上场景的过程中，我们对互动社交的发展趋势进行了总结。

首先，我们看到场景玩法互动性越来越强，连麦互动人数越来越多，普通观众的参与感、互动性随之水涨船高。

其次是内容消费形式变得更丰富、更多元。像音乐、综艺、甚至是热门短剧、赛事直播等内容都可以被融入到互动中，直播互动场景的丰富更好地支撑内容生态和营收生态持续发展。

接下来介绍目前直播里最热门的弹幕互动玩法。其主要玩法依托直播间（直播连麦、语聊房等互娱核心场景），通过将观众发送的特定弹幕信息、点赞、礼物转化为指令以参与、操作主播/房主所投屏的互动内容，支持即开即玩、多人互动，兼具观众互动性强、直播内容游戏化趣味化等特点。该玩法对用户观看人数、时长和营收等核心指标都带来了良好增益。

02

弹幕互动方案的演进

弹幕互动的实现方案历经“PC端开播”→“云游戏”→“云游戏+RTC”三个阶段。

在PC端开播方案下，开播前需主播提前在PC端安装程序和开播工具，开播后互动玩法在主播PC上运行和渲染，由直播工具（如OBS）对渲染画面和主播直播画面混流，再推流到直播间，观众进入直播间发送弹幕或者礼物参与互动。

初期将互动玩法限制在PC端主要是由于互动程序都是exe程序，手机无法直接运行，且直播中发生的大量渲染和计算对本地设备的性能要求很高。

这对业务的展开造成了一些不利影响。限制开播设备降低了玩法在平台的覆盖度，同时如果主播的设备条件较差，在直播中容易出现卡顿，观众体验不好，最终影响起播量、观众参与的人数和意愿。

因此第二阶段针对设备限制问题，我们选择在业务层直播/语聊的基础上引入云游戏。

具体流程如上图所示。在主播A进入连麦房间推拉RTC流时，也将同步进入云游戏房间拉取游戏音视频流。在与主播B发生PK时，由云游戏房间和引擎保障A与B间的正常互动，其中主播A的音频通过RTC引擎采集，并由业务层经云游戏引擎推送至B侧。

业务层会将云游戏画面和自A侧采集的摄像头流在云端合流后，推入RTC房间。游戏服务器会把游戏音频作为公共流推出，最终RTC房间拉取各路音视频，并将其合流转推到 CDN。

该方案解放了开播平台和设备限制，但也存在一些方案接入和体验问题。首先是方案接入相对复杂麻烦。同时在嘉宾和观众侧体验上会发生解说和互动画面不同步、画面延迟大和外放有回声等问题。

为了简化接入方案、优化用户体验，火山RTC+云游戏在服务侧和引擎侧进行了深度协同优化。

首先在服务侧我们优化了调度方案，保证用户连接的云游戏Pod+火山RTC媒体服务器在同一个机房；同时云游戏音视频流通过跨房间推流直接送入RTC房间。在引擎侧，我们的云游戏引擎直接依赖宿主侧的火山RTC引擎，同时会剪裁场景无关功能。

开播流程也发生了变化。在开播时，主播通过云游戏SDK启动游戏，云游戏启动Pod并创建火山RTC房间。Pod集成云游戏引擎和RTC引擎向云游戏RTC房间推送音视频流。云游戏房间跨房转推音视频流到两个直播/语聊房间。嘉宾和观众再通过RTC直接拉取直播流和云游戏流。在该方案下，两侧直播的观众只需单次拉取所在房间的音视频流。

由于云游戏和 RTC 内部深度协作缩短了数据流转链路。因此在接入直播/语聊的基础上，直播/语聊用户仅需两步即可完成场景“升级”：

1.集成veGameSDK 启动弹幕互动程序；

2.业务端通过 OpenAPI 同步弹幕/礼物数据到程序服务器。

上图列出了阶段二和阶段三方案在流程上的对比。其中用黄色标识出的流程是阶段二方案需额外完成的工作，如对接云游戏引擎，采集游戏、摄像头画面并合流传入RTC引擎、拉取游戏音频公共流等等。可以看到，阶段三方案有效降低了工作量，缩短了工作周期。

在优化前的云游戏方案下，观众发送弹幕后，由于传统 RTMP 直播流延迟较大，观众侧观看云游戏会有3~5秒延时，并且会有轻微的画面、解说不同步，体验较差。例如直播期间，主播发动嘉宾和观众发送弹幕、点赞、礼物，由于延时的原因3~5秒后才能看到反馈。同理，嘉宾、观众发送弹幕、点赞、礼物，3~5秒后才能收到主播和画面侧的反馈。

由于弹幕互动场景目前对延迟的要求较高，因此我们使用了纯 RTC 方案，游戏在云端渲染后直接推流至RTC，参与互动的主播和观众只需按需拉取RTC房间的对应音视频流即可，主播讲解和内容画面实时同步，整体通话延时低于400ms。

直播出现回声一般是由于远端用户的声音在历经网络传输、解码、降噪和增益处理后传输至本地扬声器播放，扬声器播放的声音会被麦克风重复采集。如果重复采集的声音在回声消除时缺少对应的参考信号，就会通过网络回馈到对端。

在未经优化的云游戏方案下，由于云游戏和RTC独立运行，云游戏音频无法给到 RTC 引擎，缺乏声音参考信号从而造成回声问题。

优化后，云游戏音频将直接跨房转推到 RTC 房间，场景内音频统一通过RTC引擎播放，有参考信号，可以有效消除回声。

03

弹幕互动方案业务应用中的挑战与实践

最后介绍弹幕互动方案上线后我们遇到的一些挑战和实践。

首先，弹幕互动玩法的一大挑战是对画质的要求较高，直播视频一般为1080P 30fps 8Mbps高清高码率流。由于大部分主播和观众选择移动端设备随时开播/参与，用户网络环境复杂不稳定，容易导致直播画面卡顿劣化。

为了提升画面质量，首先我们将H.264编解码器升级为自研的BVC1，升级后画面的PSNR在优于原方案2dB的同时节约了10%的码率。

其次，我们采用了智能升降级策略避免卡顿问题。我们自研的智能流控（VISC）&订阅&按需发布方案可以兼顾每个订阅端的差异化订阅需求，向用户提供丰富且适配的分辨率档位，协商发送一路或多路游戏视频流，每档位最多协商出一路，如果一个档位没有分辨率帧率被选中，则不发送。如果用户侧网络环境发生波动，档位可依据网络状况实时调整。

云游戏在所有的云计算相关应用中对延时要求最为苛刻，因此我们特别进行了针对性的全链路延时优化。

在阶段一（边缘机房阶段），我们保证用户连接的云游戏Pod和 RTC服务器调度到同一个机房，使用更高效传输方式优化，可降低约30ms延时；在编码前我们会注意减少格式转换和数据拷贝次数，使用 OpenGL 转换替换 libyuv 转换，降低了约15ms延时。

在阶段二（级联服务器阶段），我们通过减少级联服务器，优化信令传输，降低了约20ms延时。

在阶段三（订阅用户到边缘服务器阶段），我们针对云游戏下行音视频调整jitter buffer 大小，降低延时约200ms；解码时针对不同的硬解码器设置适配参数，平均降低延迟20ms，最高可达到90ms；通过推荐用户使用RTC内部渲染以减少数据拷贝，可降低延迟约5ms。

综合以上优化策略，经测试，边缘服务端到端低延时低于 70ms。

在语聊房跨房PK+弹幕互动玩法场景中，每个语聊房最高可达9人，两个房间发生PK 时，单个用户最高需拉取18路音频流和云游戏音视频流，对用户设备的性能压力较大，容易造成设备发热，拉高了准入机型门槛。

为了降低对用户设备的性能消耗，我们采用了RTC公共流方案。首先为了保证用户在本房间内的体验一致，保持本房间内拉流方式不变，同时将对方PK房间的音频流合流公共流后推出，与优化前相比，单个用户只需多拉一路音频流和一路云游戏流。

假设两个直播间发生PK时，每个房间有1位主播，8位嘉宾和100位观众，据此估算，单房间可减少约 872 路流，单用户减少可减少 8 路流，有效优化了用户拉流性能。

我们的公共流单流最高支持100万并发量，且低端机用户可以降级为只拉公共流，进一步降低性能损耗和设备准入门槛。

一般情况下，独立集成云游戏SDK后APP包体增量约9M，这对用户来说是不可接受的。在抖音弹幕互动方案中，针对云游戏我们选择直接复用火山引擎的RTC SDK传输能力，同时对云游戏 SDK 进行裁剪，去除与弹幕互动无关的部分，精简包给整体APP带来的包体增量仅 610 KB。

我今天的分享就到这里，谢谢大家！

#2

实时低延时传输引擎的

体验优化演进与未来

编者按

音视频应用的用户体验取决于清晰度、流畅性和延迟之间的平衡。不同的场景对这三个因素的要求也不尽相同。LiveVideoStackCon 2023 深圳站邀请到火山引擎的流媒体网络传输团队负责人杨威，结合支持抖音音视频的创新玩法和不同场景下的体验优化实际，探讨传输引擎如何自适应各种弱网环境，在带宽利用率、传输可靠性和延迟之间找到一个平衡点，提供最佳的用户体验。

文/杨威

整理/LiveVideoStack

大家下午好，我是来自火山引擎流媒体技术网络传输团队的杨威，我本次分享的主题是实时低延时传输引擎的体验优化演进与未来。

本次分享分为四部分：一是差异化场景和创新玩法带来的传输挑战；二是传输框架、协议和算法的演进；三是全面打磨、数据驱动；四是未来展望。

01

差异化场景和创新玩法带来的传输挑战

音视频应用的用户体验取决于清晰度、流畅性和延迟之间的平衡，从上图中我们可以看出，不同的应用场景对这三要素的要求不尽相同。因此对应的网络传输也需选择适合的算法和参数，在带宽利用率、传输可靠性和延迟之间找到一个平衡点，以提供最佳的用户体验。

接下来以几个实例说明创新玩法对传输框架和传输协议引发的变化。

首先以弹幕互动为例。在火山引擎的“RTC+云游戏”方案中，无论是主播、嘉宾还是观众都需要支持同时发送、接收多路音视频流。其中游戏的音视频流需要维持低延时以保证最佳体验，而主播和嘉宾间的音视频流为了保证交互的流畅性，在弱网情况下能够容忍一些延时。

因此我们需要针对不同类型的音视频流提供不同的传输策略，以满足不同的可靠性和延时要求。

实时合唱玩法和弹幕互动类似，除了需要支持同时发送、接收多路音频流，主唱的歌声和伴奏需要满足不同的传输策略外，在嘉宾和后处理上还需支持多路不同的音频流同步，以保证嘉宾和观众听到的主唱、互唱和伴奏的声音同步。

6v6 多人PK场景与普通1v1场景相比，由于不同主播所处网络环境、设备性能和布局不一致，对发布端要求的差异较大，因此无法简单通过下行带宽的反馈满足主播差异性的需求。

02

传输框架、协议和算法的演进

接下来介绍我们如何以传输框架、协议和算法的演进应对前面提到的挑战。

首先，WebRTC的框架专注于支持点对点实时通信，在多人场景下可靠性和稳定性难以达到预期，也无法满足不同应用场景的差异化需求。

因此我们将WebRTC框架改造为传输框架2.0，将传输功能进行了组件化，支持灵活组装；实现了弱网控制和数据收发的分离，在当前主流的无损网络环境下可以做到性能开销与纯数据收发对齐；同时还实现了应用控制层、协议适配层、传输处理层和网络连接层的解耦。从而快速高效，满足各种创新玩法对传输的差异性需求。

2.0框架支持创建一个或多个Connection Pipeline，在每个Pipeline上可以同时创建一个或多个RTP Send/Recv Pipeline，以此来支持在一/多条连接上同时发送和接收一/多路音视频流。

同时，针对不同的Connection Pipeline和RTP Send/Recv Pipeline可以选择不同的传输策略和算法，从而满足弹幕互动、实时合唱等创新玩法的需求。

多人场景中常用的大小流+SVC通过下行网络转化不同规格的视频流和空域层级来满足不同的用户需求，但在应对布局、网络条件和终端性能的变化上灵活性不足。

相比之下，我们的智能流控协议VISC（Volcano Intelligent Stream Control Protocol）能兼顾通话中每个订阅端差异化的需求，用户可以个性化选择视图布局，每种布局可对应最多十级分辨率档位，并且支持动态弱网降级和性能降级，实时调整发布端发出的音视频流参数。上图展示了两种方案在特定应用场景下的收益对比。

我们的自适应智能拥塞控制算法VICC（Volcano Intelligent Congestion Control）旨在满足全球不同网络环境下不同应用场景对带宽利用率和延时的差异化需求。它结合了传统算法BBR和GCC的优点，能针对不同应用场景的延时偏好和码率特征进行自适应调整，从而大大提高各种复杂网络环境下的带宽利用率和带宽评估稳定性。

经过测试，与传统算法BBR和GCC相比，智能拥塞算法VICC的抗抖动、抗丢包能力更强。

同时，VICC的拥塞响应及收敛速度、带宽探测平稳度也优于传统算法。它的自适应Padding策略可以在保证带宽评估准确性的基础上尽量节省Padding码率，降低流量成本。

出现网络丢包时，恢复数据包一般有两种方式：被动冗余和前向冗余。被动冗余依据接收端的反馈将丢失的数据包重新发送到接收端，前向冗余是基于其他收到的冗余包，在接收端将该包恢复出来。两种冗余策略各有优缺点，被动冗余的优点是按需发送，占用带宽较少，缺点是在高延时场景效果会急剧下滑。前向冗余的优点是不需要交互，在高延时环境下更加适用，缺点是带宽占用过多。

如上图所示，我们的延时自适应冗余算法可综合考虑两种策略的优劣，结合当前网络的RTT计算出满足特定丢包恢复率和延迟条件下两种冗余的最适比例。在保证传输效率的同时尽量减小总体冗余率，实现降本增效。

上图展示了我们的自适应智能拥塞控制算法和延时自适应冗余策略在实验室评测和线上收益方面的表现。

可以看到，相同丢包率下，我们产品的冗余率与同类产品相比更低。新算法上线后，在卡顿率和延时获得收益的同时，还能显著降低Padding码率和冗余码率，这也证明了算法优化可以兼顾体验与成本。

在弹幕互动玩法中，我们可以基于传输框架2.0开启智能流控协议，根据不同的场景需要，协商发送一路或多路游戏视频流，主播和观众根据自身网络和设备性能接收不同规格的流。

同时，针对游戏和主播音视频流可以设置不同的传输策略，例如对游戏流选择低延时，对主播流则容忍一定的延时，使弹幕互动低卡顿、更流畅。

03

 全面打磨、数据驱动

接下来让我们看看如何通过全面打磨、数据驱动将传输体验优化到最佳。抖音是一款有着亿级DAU的产品，通过对其支持我们可以全面了解线上的各种弱网环境类型，全面打磨我们的传输算法。

上图展示了依据抖音集团真实用户的负反馈数据得出的音视频卡顿归因分布。可以看到，下行小缓存拥塞是其中的主要问题。优先解决拥塞控制算法在小缓存网络下的带宽评估准确性收益最大。

我们完成算法优化并上线实验后，卡顿率和对应的归因占比均有明显下降，数据驱动优化完成了闭环。这套归因模型和优化思路同样能应用于To B场景，帮助To B客户快速提升传输体验。

传输功能和算法在优化后需要通过实验室的专项质量评估验收，但实验室的评估结果往往只能证明算法的优化是否符合设计预期，上线后能否实际获益还需借助以数据驱动的精细化运营。

上表完整展示了VICC算法从实验室评估到实际上线前的测试过程。可以看到在实验室评估阶段，测试结果显示VICC在全场景下优于传统算法。但第一次线上A/B实验结果显示音频卡顿率、延时等指标不降反升。

我们结合第一次的实验结果，通过大数据分析驱动算法参数的二次优化打磨，最终在二次实验中获得了全面的正反馈结果。

传输算法在优化到一定程度后，更进一步往往需在不同指标间做权衡。举个常见的例子，延迟的下降同时也意味着卡顿率的上升。因此我们需要通过上图中的音质、画质、卡顿率、延时、传输算法的抗丢包能力、抗抖动能力等等指标综合评估算法优化的效果。

目前通过数据驱动的优化和不断打磨，我们的算法在互娱、会议和教育场景下，可以做到优于或对齐同类产品。

04

未来展望

最后做一些未来展望。音视频应用对传输的要求随着玩法的多样化将越来越高。以PK连麦客户端合流场景为例，目前在该场景下我们需要同时传输基于RTP的PK流和基于RTMP的直播流，与此之上可能还需要传输一些信令和数据。

因此我们希望通过一套通用的数据传输引擎实现对各种主流传输协议的兼容。同时借助我们提供的统一弱网控制算法，在保证互联互通的前提下，于弱网场景就可以合理利用不同数据对传输可靠性和延迟的差异化需求，按照用户设定的优先级对各类数据尽可能提供最佳的传输体验。

我们所处的网络环境正随着全球化趋势的发展变得越加复杂。从上表中不难看出，不同区域的丢包率和延迟存在明显差异。

差异的网络环境会导致我们对通用算法的投入产出比很低。因此我们希望通过智能识别典型弱网场景以驱动全链路差异化优化。

同时我们也将对现有传统算法全面进行人工智能化升级，提供面向差异性网络环境的自适应能力。

我今天的分享就到这里，谢谢大家！