不要迷失有用的信息

背景

随着互联网技术和网络基础设施的快速发展和普及，视频直播已经成为一种越来越普遍的娱乐和社交方式。无论是个人还是企业，都可以利用视频直播平台直播活动，向观众展示自己的才艺。同时，视频直播已经成为一种新型的社交媒体，让人们可以在虚拟空间中进行互动和交流。

RTM（Real Time，低延迟直播）是近来逐渐兴起的一种直播解决方案，目标是提升客户互动体验，其特点是相比传统直播解决方案，端到端延迟更小，达到1秒级别，卡顿现象没有明显负面趋势，并且RTM的网络传输层基于技术（RTP/RTCP协议）。

相较于传统RTMP推流，RTM推流在网络变化响应灵敏度、抗弱网能力、带宽利用率等方面优势明显，在抖音AB实验中，主播平均观看时长/关注度/收视评论显著正向，推流音频/视频卡顿-22.2%/-7.8%，端到端延迟-1.6%，目前RTM推流在抖音秀场中已经实现常规量级10%左右。

技术架构CDN技术架构

目前CDN厂商对RTM的支持主要有两种技术架构，一种是基于传统的RTMP/FLV架构，在推拉流的边缘节点增加对RTM接入协议的支持，在CDN集群内部复用传统架构；另一种是CDN内部集群也采用RTP/RTCP协议和架构。CDN的技术架构如下图所示：

客户端技术架构

在流媒体客户端，RTM 流媒体网络传输层采用了 自研 RTC SDK（）。在设计之初，为了支撑无缝业务接入，最大程度复用已有能力，避免重复造轮子，RTM 流媒体在客户端采用了（ 自研直播 SDK）编码音视频+传输的技术架构，如下图所示：

主要包括三部分：

技术优化、功能完善、稳定性打磨

由于RTM是近几年才逐渐兴起的直播解决方案，无论是CDN服务端还是客户端SDK都处于早期发展阶段，功能上还存在很多不足。例如最初只有两家CDN支持RTM推流，音视频编码格式不同，兼容性也存在不足，前期联调阶段不支持HE AAC、H.265及视频B帧，稳定性有待提升，在联调和灰度发布过程中多次遇到屏幕闪烁问题。

关于功能性和稳定性，这里分享两个案例：支持视频B帧和解决画面扭曲问题。

支持视频B帧

标准本身并不支持视频 B 帧，因为其原本是针对实时通话（RTC）场景设计的，在视频编码中启用 B 帧会引入额外延迟，影响通话体验。但在直播场景中，对延迟的要求比 RTC 要宽松得多，而且开启 B 帧可以提高视频压缩效率、改善画质或节省带宽成本，因此在直播场景中开启 B 帧是常见的做法。

以下是互动娱乐评测实验室针对B帧进行画质测评的结论：

【互动娱乐-评测实验室】抖音直播软件编辑器开启B帧率降低画质评测报告

结合主客观表现，设置软剪辑+B帧后，硬剪辑之间静态清晰度没有明显差异，但马赛克明显增多，劣化较大，软剪辑各个码率降低点之间马赛克差别不大（0.9，0.88，0.85，0.82）

主观图像质量：

客观图像质量：

评测发现，虽然软剪辑与硬剪辑在主客观清晰度上存在明显差异，但是在软剪辑（开启B帧）的情况下，降低编码码率时，主客观清晰度并没有出现明显差异。

为了支持B帧，我们需要扩展SDP标准进行媒体能力协商，以下是《超低延迟直播技术白皮书》(#%E8%A7%86%E9%A2%91-b-%E5%B8%A7%E6%94%AF%E6%8C%81)中视频B帧支持相关的扩展定义：

SDP 视频 B 帧协商

客户端需要在SDP中添加B帧相关信息，实现B帧的非单调递增处理逻辑，后端需要实现相应的B帧封装逻辑。SDP B帧协商示例如下所示。

...
a=rtpmap:96 H264/90000
a=fmtp:96 BFrame-enabled=1;level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
...

SDP 中的 - 表示客户端是否支持解码 B 帧。它不表示服务器是否支持发送 B 帧。

-=0，如果源流包含B帧，服务器会将源流中的B帧去掉，再转发给客户端。

=0，源流不携带B帧，服务端直接将源流转发给客户端。

-=1，源流携带B帧，服务端直接将源流转发给客户端。

-=1，源流不携带B帧，服务器直接将源流转发给客户端。

视频B帧时间戳计算

计算视频B帧时间戳的方法有两种。

...
a=rtpmap:96 H264/90000
a=fmtp:96 BFrame-enabled=1;
a=extmap:7 rtp-hrdext:video:CompistionTime
...

RTM 推流项目启动之初，缺少对推流视频 B 帧的支持，我们也向代码仓库提交了修改后的 MR，并推动 CDN 服务器的开发和联调，最终灰度发布。验证了功能性和稳定性问题，完成了对视频 B 帧的支持。

解决屏幕杂音问题

画面失真的可能原因有很多，从主播端到观众端的整个链路中，任何一个环节都可能出现问题而导致画面失真，以下是典型的视频全链路中涉及到的环节：

用户会看到画面扭曲现象有两个环节：主播的预览和观众的渲染，但问题可能并不出在这两个环节，具体来说，当观众看到画面扭曲时，可能是编码器有 Bug、推流过程中视频参考帧丢失、CDN 发送给观众的数据有误、解码器有 Bug，或者渲染模块有 Bug。

解决画面失真问题最常见且有效的方法是保存一些关键环节的视频码流数据，使用可信赖的程序（如）验证该环节数据是否正常。将服务器输出的数据写入本地、抓取发送的数据包或在服务器上抓包。

除了直接使用播放观察画面是否扭曲（或者控制台是否打印错误日志）之外，我们还可以使用以下命令将视频的每一帧导出为图像：

ffmpeg -i test.flv frames/$filenamed.bmp

例如，我们在排查屏幕失真问题时，发现屏幕失真从第 30 帧开始出现：

这个flv文件是QA同学测试的时候使用wget命令保存的推流URL的数据，推流端抓包播放没有出现画面失真的情况，所以肯定是CDN的问题。

在RTM推流联调灰度发布过程中，多次遇到画面扭曲的问题，每次问题出现在不同的阶段，可以说基本把坑都踩过了，这里就不一一介绍了，有兴趣的同学欢迎线下交流。

卡顿优化

在解决功能性和稳定性问题后，我们使用公司内部的弱网模拟工具进行线下测试，发现RTM 推流在弱网下表现非常差（测试基于iOS系统，视频编码格式为H.265，分辨率为720p，码率自适应范围为~）：

在5%丢包RTT的情况下，RTM推流已经卡住，无法播放（表格中的“--”表示视频基本无法播放，无法统计数据）。

经过与各CDN服务器的联合分析，我们发现了几个问题：

在技​​术架构上，火山引擎直播CDN采用的是上面介绍的第一种技术架构，即边缘接收节点会将RTP包分帧，转换成RTMP/FLV流推流到源站，这里我们就来详细介绍一下。火山引擎直播CDN在分帧环节做了两点优化。

分帧：针对抖动、乱序、丢包和重传的场景，如果CDN接收分帧设置过小，会造成丢帧、丢失GOP，从而影响用户观看直播的流畅度，造成卡顿感。如果接收分帧设置过大，分帧设置引入的延迟会很大，降低直播的互动性。针对这个问题，我们参考推送侧的网络抖动设置，引入网络自适应的接收帧大小。对于大多数网络好的推流，分帧引入的延迟微乎其微；对于存在抖动、乱序、丢包和重传的推流，可以在保证流畅的同时，尽可能少引入延迟。

帧交织：UDP数据包不保证到达的顺序，视频帧抖动等因素会造成转换后的RTMP/FLV流中的音视频不严格交织，出现部分视频3~4秒无音频（或反之）的情况，当推流端到端延时低至2-3秒时，由于音视频同步机制，播放端可能会出现卡顿，影响用户的观看体验，结合音视频时长，我们对音视频进行交织，保证音视频帧数尽量均匀，DTS差距不能太大，经过上线验证，因非交织导致的播放卡顿已经明显减少。

以上问题全部解决之后，再次进行了模拟弱网测试，结果得到了很大的改善：

可以看到，当丢包率为10%时，推流依然维持在最高自适应码率，拉流也没有任何卡顿的情况，但是当丢包率上升到15%甚至20%的时候，RTM的推流效果基本不佳，但是我们分析线上数据发现丢包率超过10%的比例非常小，所以就没有继续优化。

最后我们请视频云团队音视频实验室对抖音的RTM和RTMP推流进行了权威评测，评测结果如下：

” 直播” RTM vs RTMP 评测报告

算法优化

经过以上一系列的工程优化，我们终于开始了线上AB实验，与基线算法RTMP对比，结果不如预期：QoE在播放次数上无明显趋势，播放时长稳中偏负，播放观看指数无明显趋势，QoS音频渲染百秒时长/卡顿次数为-3.641%/-4.649%，视频渲染百秒时长/卡顿次数为-2.926%/-8.044%。

直观的问题是：为什么 QoS 延迟有好处，而对 QoE 没有好处，甚至会产生负面的 QoE？

为了找出原因，更好地进行下一步的迭代优化，我们开始深入研究RTM算法。

问题分析黑箱评估分析

基于抖音APP测试推流，使用拉流demo进行拉流效果测试

在网络无丢包、直播内容相同的场景下，测试发现RTM的目标码率相比RTMP更为保守。

RTM (TCC 开启) RTMP (TCP)

（）

网络丢失情况下，RTM带宽利用率仅为50%，对推流端影响严重，例如

有网络丢失时（左）和无网络丢失时（右）使用 RTM（启用 TCC）的图像质量

这意味着 RTM 在某些情况下会牺牲图像质量来换取延迟优势。

基于在线大规模数据分析

基于抖音数据集，我们分析了以下三个关键问题：

1. BWE周期振荡问题

红线BWE的波动很有可能会造成黄线目标码率的波动；BWE的波动并不是因为丢包率高，RTT也在很小的绝对值范围内（在内）波动。

2. 目标比特率的周期性振荡

目标比特率自身波动，不受bwe影响（bwe为稳定状态）

3.传输容量足够，但固定码表限制了画质的提升

bwe 与上述一样高，而 max 仅在左右

我们还量化了数据集中已识别的问题类型的重要性：

白盒测试重复出现的问题及根本原因分析

我们选取典型的非稳态网络场景进行实验，复现上述问题，并分析算法内部原理。我们发现：

在非弱网场景下，例如当RTT抖动仅在较小范围内（小于150）时，TCC带宽估计算法对时延信号过于敏感，经常对弱网产生误判，导致估计带宽值周期性下调，从而降低带宽利用率。

具体分析过程如下：

首先我们来看下问题的复现场景，这里举两个例子来说明问题，带宽+时延波动场景（左图）的实验表现和之前上线跟踪点的波动现象（5秒级别）一致，在5秒范围内，本次测试场景复现了线上bwe波动的问题场景；在带宽泊松波动场景（右图）下，周期性波动问题更加明显。

其次定位问题根源，bwe波动的根源是算法频繁重置（左图）降低预估带宽，判断逻辑在部分（基于趋势线的时延估计器）。这里将时延误判为弱网络（注：误判是指实际的RTT和丢包情况没有表现出弱网络的特征，比如右图中子图4、5）。

解决方案带宽估计算法

1.优化现有BWE算法模型参数

无需编写代码或等待发布周期，尽快解决问题

我们把代码逻辑和BWE算法参数都梳理了一遍，优点是直接通过在线配置就可以很方便的修改和实验，缺点是参数太多，调整起来太费力而且收益很可能非常有限（理论上参数的默认值应该是一个推荐的最优值）。最终我们决定根据经验选取几个关键参数作为第一阶段方案优化，在线下验证了参数调整的收益后，针对第一阶段方案进行了在线AB实验。这样我们就有相对充裕的时间去做后期优化。

2. BWE算法用于在线问题模式检测和BWE模型校正

在实现解决问题的目标的同时，尽量减少对代码/bwe算法模型的侵入性修改

我们在BWE算法上引入周期性震荡场景识别与平滑策略，提高带宽估计的准确性，提高带宽利用率，从而提高视频质量。

代码控制算法

1. 解耦码控算法与带宽估计算法

在原有的RTM 架构中，并没有单独的码率控制算法，码率控制的上下界由码表决定，码率如何在上下界之间变化完全由BWE算法决定。

上述架构存在以下两个问题：

A. BWE算法问题会直接体现在代码控制层面，比如上一类问题（BWE波动几乎必然会引起码率波动，进而导致画质问题，比如业务方反馈的推流码率突然下降，画面模糊的问题）

B.码控算法很好的利用了弱网感知优势，却忘记利用强网感知优势，比如当带宽预估超过码表速率上限时，还可以超过码表速率上限，进一步提高码率（非中国地区的码表上限比中国地区的低很多），从而提高画质。

因此我们将传输层的BWE算法与应用层的代码控制算法进行解耦，通过在RTM SDK层面设计和实现单独的代码控制算法，可以更加灵活地根据业务场景/需求设计代码控制策略。

2. 目标码率波动在线识别及平滑策略

类似于BWE算法的振荡波动识别与平滑的思想，设计一个在线检测算法来识别码率的周期性波动，并平滑码率，码控算法不一定要遵循BWE算法，因为BWE算法也可能出现误判，另外，非实时通信的直播场景中，当存在秒级端到端延时且同时推拉流时，并不需要立即响应带宽波动，码控算法可以选择性地在清晰度和流畅度（卡顿）之间取得平衡，并根据线上实验的用户体验偏好进行迭代。

算法优化离线效果评估

在有限的测试场景中

两者并不冲突，当带宽波动较大时，可以将两者结合起来，达到带宽利用率的效益。

综上所述，在有限的测试场景下，BWE波动识别平滑方案在RTT场景下码率效益更加明显，而码率波动识别平滑方案在BWE场景下画质效益明显，所有场景下均有较好的码率效益。

优化结果

目前我们的RTM解决方案已在抖音上落地并规模化，在抖音上主要指标收益为主播平均观看时长/关注度/评论数显著正向提升，直播间音频/视频卡顿-22.2%/-7.8%，端到端时延-1.6%。

未来展望

目前，RTM推流在抖音秀场已实现10%左右的常规量增长，但RTM推流的效果还远未达到最佳，还有大量的优化工作有待推进。

从工程优化角度，下一步需考虑以下几个方面：

从算法优化和创新的角度，我们考虑以下几点：

加入我们

字节跳动视频架构是字节跳动的视频中台部门，支撑字节跳动产品点播、直播、实时通讯、图片、多媒体业务的开展，旨在成为行业多媒体解决方案的领导者，构建极致的视频技术/产品服务体验。

扫描下方二维码或点击文末阅读原文、投递简历，加入我们，让我们一起成为多媒体领域的领军人物吧！

直播研发工程师-视频架构师（北京/上海/深圳开放）