追求极致，揭秘抖音背后的RTC技术

Posted 2021-12-18 LiveVideoStack_

点击上方“LiveVideoStack”关注我们

直播、社交、在线教育等行业催生了实时音视频技术（RTC） 的兴起和发展。反过来， RTC 的发展和应用也为这些行业带来了巨大的增长。随着 RTC 对应用场景的不断渗透，业务伙伴关于场景体验的要求也越来越高，比如更低延时、更加顺畅、更高画质。LiveVideoStackCon 2021 北京站，火山引擎视频云 RTC 产品负责人 Julian，为大家分享火山引擎视频云 RTC 是怎样在抖音、西瓜、头条等产品的场景实践中，不断地追求极致的。

文 | 朱利安

整理 | LiveVideoStack

大家好，我是来自火山引擎 RTC 团队的 Julian，很高兴今天能跟大家学习交流。今天我带来的分享是抖音背后的 RTC 是如何追求极致的。

1. 简介

首先，我先简单介绍一下火山引擎 RTC 团队。

我们并不是来自抖音，我们来自火山引擎，抖音也是火山引擎服务的一个客户。我所在的团队是火山引擎的 RTC 团队，已经为抖音服务了 4 年时间。在 4 年中，抖音不断增长，拥有 6 亿 DAU，而火山引擎 RTC 团队的能力也有跨越式的提升。

我们先看一下抖音上的 RTC 应用场景。

最经典的是连麦 PK。两个抖音主播通过 RTC 进行连麦，转码生成两路音视频流，推到 CDN，分别给各自直播间的观众进行直播。在这个过程中，主播 PK，看谁收到的礼物更多。有些 PK 场景还会有主播和观众的互动：这边，主播和观众的互动也是通过 RTC 进行的。

抖音上也有一些很有意思，但是大家可能了解不是特别多的场景，比如一起看和好友私聊。

一起看就是我们在抖音上可以几个好友连线，一起看同一个视频，其中有一个人是房主，房主的视频刷到哪，其他人自动跟着刷到哪，大家还能通过语音实时交流视频内容。这里面除了语音聊天是用 RTC 实现之外，短视频的消息同步也是用 RTC 的低延时消息做的。

一起看就是几个好友连线，在抖音上同时看同一个视频。其中有一个房主，房主看到哪，其他人的视频也自动播放到哪。大家通过语音进行实时交流。这个场景下，除了语音聊天是用 RTC 实现的以外，视频播放进度的消息同步也是用 RTC 的低延时消息功能实现的。

还有一个场景是好友私聊。一些抖音重度用户知道，抖音现在也支持视频和语音通话，体验也非常不错。我自己和朋友用其他软件通话比较卡的时候，就会换抖音。经常换了抖音就不卡了，大家有兴趣也可以试一下。抖音上的视频通话还自带美颜，因此视频通话相对语音通话的比例会更高一点。

抖音上的通话效果好是有指标支持的。经过长期的合作，我们打磨出了一套指标体系。这个图中摘录了部分核心指标。左边是 RTC 的技术指标，包括卡顿率、端到端延迟、首帧时长、清晰度。右边是与 RTC 质量相关的抖音业务指标，包括用户反馈率、用户渗透率、用户使用时长以及业务营收。RTC 的优化都是在数据指标指导下进行的。优化过程中，我们做了很多 AB 实验和归因分析，通过优化技术指标，来优化业务指标。全量上线的标准是能够达成最优的业务指标。

2. 面临的挑战

下面说说我们的挑战是什么。

如果对 RTC 的核心指标进行归总的话，可以划分成清晰、流程、实时三个核心要求。但对 RTC 熟悉的同学都知道：这三个核心要求之间，有时是无法得兼的。网络好的时候没什么问题，网络比较差的时候，就要牺牲其中一个或两个指标。

举个简单的例子，当网络不好，视频有卡顿时，增加缓冲延时是最简单的优化手段。缓冲延时太高，会引起两个人抢话，严重影响通话体验。如果同时需要流畅和实时，那只能降低清晰度。抖音上有很多颜值主播，让主播的脸能被看清楚，又是一件优先级挺高的事情。

业务面对这样的选择题时，通常可以接受一点指标上的妥协，但总是会提出持续优化的要求。换句话说，就是“我全都要”。业务的需求都是合理的。接下来我们就来讲一下我们是如何应对这样的挑战的。

3. 最佳实践

3.1 流畅度

首先，讲一下流畅度。流畅度对应的指标是卡顿率。卡顿其实对于交流的影响是最大的，即使只卡掉一个字，你也会明显感觉到交流不畅。

卡顿是因为弱网。那弱网又是什么引起的呢？

我们建立一个最简单的 RTC 传输模型，终端 A 到终端 B，中间是 RTC 的云端传输网络。其实云端传输网络的传输质量现在已经非常好了。我们会监控 QoS 指标。

监控结果可以发现：云端丢包基本上是不存在的。国内云端传输延迟基本在 50ms 以内，全球范围基本都在 250ms 以内。

主要的弱网其实是在接入网，也是我们常说的 FirstMile 和 LastMile，也就是用户自己的客户端接入 RTC 网络的这一段。数据统计后发现，大概 30% 的用户会碰到弱网的情况，其中 26.8% 是轻度弱网，中度和重度都在4%左右。

这边弱网用户等级，是按瞬时网络指标进行区分的，分为好、轻度、中度和严重4个等级。

这边我们找了一个极端的线上 case，看看 RTC 能力的极限如何。

这是一个丢包率和延时参数的示意图，我们看到，最初比较平稳；突然发生弱网，持续了一段时间，丢包率最高达到了 49%。随着抗丢包策略的接入，延迟从 88ms 升到 700ms。经过优化，抗丢包策略的卡顿时长基本都控制在 1.2 秒以内。

要适应突发的极端弱网情况，我们的算法也会实时自动调节。

针对不同的场景，其实会适用不同的算法。比如 1v1 通信时，除了根据发送端的上下行网络调整发送策略外，也要关注接收端的下行网络情况。接收端下行网络不佳时，发送高规格的音视频数据并不会带来什么收益。多人通信时，我们会采用大小流（Simulcast）的方法。应用大小流时，大家常常会关注接收端。但其实发送端上行可能也会有压力，上行如果出现弱网的时候，也要考虑发大小流是否合适。

这些场景都在我们的算法考虑范围内。我们会通过对用户 QoS 数据的洞察，针对不同场景，自动下发对应的策略。算法的训练数据来自线上海量的真实用户网络环境。上面举的例子是抗丢包。真实的线上弱网环境非常复杂，纯丢包的场景几乎是不存在的，一定会叠加抖动、延时等网络问题。我们把线上用户真实的情况不断的加到训练库里，不断优化算法的应对。

另外，应对网络从好到差的过程要敏感，但恢复的过程要有一定的弛豫。有时候网络波动发生，消失的过程很快。多等待 3、4 秒，确定网络真的平稳了，算法才会把用户的码率恢复上去。

我们准备了一段视频进行弱网对抗的演示。是团队成员自己录制的，不涉及用户隐私。

演示中模拟了弱网情况，并且限制了最高可用带宽，分别降到三个弱网等级。网络从好的状态到轻度弱网的情况，码率和帧率有所下降；中度弱网时，网络丢包比较严重，分辨率也有所下降；重度弱网时，码率 500fps 都不到了。极差的情况下引入了一个 1 秒的卡顿，然后网络有所恢复，突然又到了极差的情况，最后恢复。

可以看到在极差的情况下，虽然有1秒的卡顿，但并没有漏字，在适应弱网之后，会把之前漏掉的音频用比较小的倍速去追上进度，不会影响内容。

3.2 实时性

实时性有两个指标，端到端延迟和首帧渲染速度。对通话场景来说，端到端延迟控制在 400ms 以内，用户体验都是没问题的。当然，也有对延迟要求更高的场景，比如云游戏，它对延迟要求极高，从用户触发指令开始，到收到首帧响应，来回需要在 100ms 以内。本次分享时间有限，就不展开了。

我们主要分享首帧渲染速度。

我们可以思考一下。为什么 CDN 的延时比 RTC 大很多，反而首帧响应又快更稳定？其实，CDN 会在边缘节点把命中率高的视频加入缓存，用户在拉流的时候可以从边缘节点直接拉，这样就比较快。因为业务特性的原因，RTC 不可能去做这样的缓存策略。但我们会去借鉴这样的思路。多人场景下，比如刚开始是两个人通话，后来第三个人进来，之前两个人的通话就已经在边缘节点上了。火山引擎 RTC 有一种策略是把最近 1 个 GOP 的音视频流缓存到边缘，加快新的音视频通话参与者打开首帧的速度。

GOP 是两个视频关键帧之间的时间间隔。大家对视频处理比较熟悉，就知道这个概念。业内 GOP 采用 1s、2s 的都有。

我们无法预测码流的请求什么时候来。如果没有缓存，只要不是落在 GOP 刚开始的时候，请求者就必须等到下一个 I 帧时，才能拉到首帧。很显然，这个等待时间根据 GOP 的大小有一个预期分布。而应用缓存策略之后，不管请求什么时候到，都可以即时获取到首帧。

这里录了个Demo，主要看的是每进一个房，3个流的加载速度。可以像抖音一样做上滑下滑的切换房间，最后是一个上麦的速度，这种情况下都是需要更快的首帧。这个 Demo 里面打开首帧的时长都在100ms 到 200ms 之间。，我们也检测了线上首帧的速度，基本都在700ms以内，有的业务形态好的，会控制在400ms以内，我们管这个叫瞬开。

3.3 清晰度

第三个优化方向是清晰度，清晰度提升的是用户体验的上限。前面的优化，用户感知起来是非常直接的，而清晰度的感知是潜移默化的。视频没有那么清晰，你一开始并不会有很明显的感觉，但看的时间长了以后，就可能不想继续看了。所以这个指标最后会影响用户使用时长。

清晰度是没有上限的。RTC 需要解决的问题是如何在有限的带宽下，让实时传输的视频质量更高。

• BVC1 - 字节跳动自研编码算法

这个视频里面显示的是自研的 BVC1 编码器，和主流的 H.264 和 H.265 在编码效率的对比。右侧的 RD-plot 曲线图里显示 BVC1 编码器能比主流的 H.265 编码器再提升 0.6dB。一般我们评价一个 Codec 算法好不好，会看它节省了多少带宽。但具体到 RTC 中，用户的带宽是平稳的，分辨率也是业务上所决定的，不需要把带宽用足，把分辨率变得更高。所以火山引擎 RTC 选择在带宽和分辨率不变的情况下，把编码效率用到画质提升上。

重点可以看背景上的粉色条。

• ROI（感兴趣区域）编码

ROI（感兴趣区域）编码我们也在广泛地使用，基本上连麦场景下都会使用。用白话讲，就是针对中间的人脸进行编码。在同样的帧率和码率之下，经过 ROI 编码后的效果，在脸部细节上更清晰。正好前面有同学问到，我们怎么去评测 ROI 的效果。ISO 提供了一种通过盲测得票比率映射 JND 的方式评测画质。我们通过内测邀请了 100+ 同学对比评测，得到了 2.3 分。这是一个比较高的分数了。

• 超分辨率 Super Resolution

最后我们也用到了超分算法。

可以看一下头发丝的细节。超分提升分辨率。这边把原本 360P 的视频超分到 720P。这边盲测的评分就更高一些，是 2.55 分。

不同场景下的优化策略

有了硬核的算法能力之后。我们也会针对每个场景适配最合适的优化策略。

比如在 PK 场景，运用的是最佳分辨率策略。

先简单介绍一下这个策略。PK 时，RTC 画面会占据画面的四分之一（长、宽各一半）。现在随着用户的手机越来越好，有些手机能支持 1080P 的音视频通话，有些只能支持 540P 等等。比如你作为一个主播，拿着 1080P 的收集和 720P 的主播进行 PK 连麦的话，其实你看到的，对面主播发过来的视频也就是 540P。对面主播采集 720P 的视频也没什么用；反过来也是一样的。最佳分辨率策略就是说，RTC 会自动根据对面主播的设备分辨率情况，来选择最合适的分辨率，而不是无脑用最高清的分辨率。

我们接收另外一个在 PK 连麦场景上应用的转推 CDN 的策略。大部分 RTC 都是在云端做转码，然后转推 CDN 的。这其实会引入多一次的编解码和传输。PK 场景是两个人，对端视频流一定是从远端过来的，这个没办法。但其实主播自己的画面转推 CDN 时，经过服务端转推的二次编解码，它的画质一定会有点受损，所以我们会碰到很多业务方提出要用客户端转码的方案。

但客户端转码也会来其他的问题：虽然减少了一次编解码传输，但是会带来设备性能消耗的提升。我们提出了端云一体转推 CDN 的方案。如果这个主播的设备，其性能和网络足够在客户端做转码，我们就在客户端做；如果不足，就降级到服务端进行。这样，设备性能高时，能享受到更好的清晰度；设备性能低，我们能保证正常使用。目前这个策略应用于线上超过 60% 的用户。

这就涉及了怎么去判断用户设备的性能的问题。

火山引擎 RTC 在后台维护了一个很大的机型数据库，设备总数达到 2w+，并且不断增加中。这边是部分截图。我们会保证每一款机型在对应场景下，都有经过打磨验证的推荐参数和推荐策略。

3.4 美颜特效

最后单独提一下 RTC 和美颜特效的结合。美颜特效其实对于 CPU 和内存的消耗是更大的，有这么大的一个模型在那边跑，对于 RTC 自适应算法带来了新的挑战。

我们在测试过程中碰到过美颜特效影响编码算法效率的事情。所以我们思考，怎么尽可能避免这样的影响？

先看一下现在主流的做法，RTC 和 CV 是分开的，开发者需要先自己采集，送到美颜特效的 SDK 处理，拿到处理后的视频流，再在本地回显，并送到 RTC SDK 做编码，然后传输。这个逻辑很顺，但缺点在于， RTC 编码时会考虑弱网和设备性能的降级，如果因为弱网或设备性能不够，RTC 编码是会降级的。你想编码时候编的是一个 360P 的视频，采集和美颜用 1080P 就没什么意义，一点都不低碳。如果 RTC 的降级能够影响到采集和美颜，整体的性能消耗会更优。

火山引擎 RTC 就把美颜特效的 SDK 和 RTC 统一调度了。采集就用的 RTC SDK 的能力，再通过 RTC SDK 调 CV 相关的接口。这样，采集和提交到美颜 SDK 的视频分辨率都是一个分辨率。再也不会出现采集、美颜 1080P，传输 360P 的情况了。

总结

虽然今天介绍的是我们为抖音做的优化，但这实际上是一套针对场景特点优化的方法论，不局限于抖音。

目前我们除了服务抖音以外，还服务着字节内外部的其他客户。现在月均通话分钟数已经超过了 150亿。庞大的基数带来的巨大的数据，也是我们优化的着力点。

我们的态度是追求极致，我们的目标是成就合作伙伴。大家有兴趣的话可以做进一步的交流。

感谢大家！

---

讲师招募

LiveVideoStackCon 2022 音视频技术大会 上海站，正在面向社会公开招募讲师，无论你所处的公司大小，title高低，老鸟还是菜鸟，只要你的内容对技术人有帮助，其他都是次要的。欢迎通过 [e-mail] 提交个人资料及议题描述，我们将会在24小时内给予反馈。

喜欢我们的内容就点个“在看”吧！