北京华网天下

抖音直播链路各环节延迟贡献及降低延迟的方法探讨

2024-10-13

来源：网络整理

以抖音直播为例，直播链路中各环节的时延贡献如下：

从各个环节的延迟贡献来看，很容易得出一个直观的结论：端到端延迟过大主要是由播放器的防抖造成的。这种表面现象往往导致很多同学认为降低播放器延迟就会减少延迟。。这种说法是对是错，取决于解读它的角度。在论证这个结论之前，我们先拆解并详细介绍一下整个直播环节的延迟：

上图主要对流媒体服务链路进行了更详细的拆解，即CDN传输链路，分为上行链路（流接收节点和上层节点）、源站、下行链路（上层节点和上层节点）。流边缘节点）。各链路的延误归属如下：

主播终端（推流器）

主要包括编码延迟和发送缓冲区引入的延迟（大多数主播网络条件良好，发送缓冲区延迟平均只有20~30ms）。这个环节的时延没有太大的优化空间。虽然通过调整编码器参数可以有效降低编码延迟，但带来了图像质量的损失，也影响了压缩效果，所以大多着眼于优化弱网络传输（但出发点是为用户提供流畅的传输体验）观看体验，不是为了减少延迟）

收集边缘节点和中间链路

对于不需要分片的http-flv协议，每个CDN传输节点收到流数据后直接转发到下一个节点。该链路中的时延主要是由链路传输引起的，与链路长度成正相关。一般情况下不超过平均值。

如果播放端拉取转码流，那么除了网络传输延迟之外，还会有额外的转码延迟（目前各大CDN厂商的编码延迟约为~2s），包括解码延迟和转码延迟，其中对于B-free帧场景来说，解码延迟很小，主要是编码延迟。编码延迟主要受编码器缓存的帧数影响。假设FPS=15，则缓存6帧，延迟为。这部分延迟与推送编码延迟相同。转码延迟也可以通过调整转码参数来降低，但同时也会造成图像质量和压缩率的损失，所以这部分延迟需要根据实际场景综合考虑。如果延迟要求很高，可以调整。

拉动边缘节点

无论回源情况如何，该链路对延迟的影响主要是gop策略（有些CDN厂商也称之为快速启动策略或快速启动），即边缘节点缓存一个流的最新gop （一般平均媒体时长为5~7s），目的是在拉取请求建立时立即发送媒体数据，并优化首帧和滞后。这也导致玩家收到的第一帧数据是5~7s前的旧数据。，第一帧的延迟达到5到7秒（这个环节是端到端延迟过大的根本原因）。

CDN逻辑

Byte与CDN厂商沟通，约定gop先按照下限投递数据，比如下限为6s，也就是说最新的6s数据会先定位到缓存数据中，然后是旧的6s数据ago将搜索第一个关键帧并交付以确保交付。发送第一帧到最后一帧的时间间隔不小于6s：

如上图所示，如果不考虑制作端和中间环节的延迟，7.2s的长度可以近似视为播放的初始端到端延迟。在播放器正常播放且不出现卡顿的前提下，这种延迟会一直持续到退出直播间都不会改变。以下是一些初始延迟计算的通用公式：

例如，抖音秀的gop大小固定为2s。假设下限为6s，则观众合理的端到端延迟分配区间为：[6, 8]s。根据用户请求的时间点，所有观看者的延迟将被平均分配。在此范围内，不同观看者之间的延迟差异最多不超过1个gop的长度2s（这是优化设备间延迟差异的理论基础）

观众（玩家）

播放器在io模块中有分配缓存（抖音在线最大分配是20s，也就是说最多可以容纳20s的媒体数据，其实越大越好，抗网络抖动的能力越强），用于存储来自CDN边缘节点的数据。下载的流数据。播放器下载是主动下载。在可分配队列未满的前提下，io线程不断下载流媒体数据并将其存储在其中，直到没有更多可用空间。因此，当观众网络状况良好时，用户请求播放并建立链接后，CDN边缘节点的快速启动会快速下载到播放器，后续渲染链接的消耗速度远低于i/o下载速度，因此端到端延迟主要分配给播放器。但仅说明，在开始播出后，直播链路的延迟从CDN转移到了播放器上。玩家并不是延迟的根本原因。因此，降低播放器的最大缓存并不能降低延迟。如果从另一个角度理解的话，正确的说法是减少播放器中实际缓存的数据会减少延迟，比如通过倍速播放或者丢帧。

现在我们了解了全链路延迟是如何发生的，我们可以确认以下几点：

为什么要针对延迟进行优化？

传统直播技术的延迟非常大。从观众评论到主播反馈通常需要5-10秒以上的时间。几个典型的尴尬场面：

在线教育中，当学生提出问题时，老师会转到下一个知识点，然后再回来解答。

电商直播，索要宝贝信息，主播“视而不见”。

奖励结束后，我仍然听不到主人口头的感谢。

假设端到端时延为6s，在线教育和电商直播两个场景中，交互时延从面对面的0s增加到12s，如下图所示：

在奖励场景下，交互延迟从面对面的0s增加到6s，如下图所示：

当别人的喊声告诉你球已经进球时，你还在看直播吗？

该场景下的延迟体验问题并不是由于某个 Pull 的端到端延迟过高造成的。主要是不同用户之间的延迟不一致造成的，如下图：

可见，高延迟影响了直播的交互体验，阻碍了直播在某些场景下的实施，尤其是在电商直播中。直播间的评论和提问是观众与主播互动的重要手段。主播的实时互动反馈对直播间的活跃度有着重要影响。完成交易至关重要。

上述两类时延导致体验不佳的场景分别对应我们QoS指标中的平均端到端时延和时延设备差异两个指标。与延迟相关的优化也将基于这两个指标。

时延体验优化实战案例百万英雄答题直播链接

延迟需求需求分析解决方案

gop=2s，下限为5s，那么第一帧延迟分布在[5s,5+2s]内，平均延迟为(5+(5+2))/2=6s。具体措施如下：

每个CDN的快速启动策略需要设置为下限优先级，快速启动阈值为5秒。

推送参数设置需要设置gop=2s并保持稳定：保证观看同一个流的用户，时延差异在2s以内

转码配置需要保持gop=2s配置，I帧对齐：保证对于观看不同转码流的用户，时延差异在2s以内

调整gop=2s后，只能保证vv流畅播放，无卡顿，相互之间的直接延迟差在2s以内。但对于观看过程中出现卡顿的用户来说，累积延迟会增加，延迟差异会越来越大。该值越大，例如用户A卡顿4秒后恢复正常播放，A的端到端延迟就会增加4秒。如果A、B、C是朋友，组队答题，A的问题解释永远落后于B、C，这样的体验是很不好的。因此，需要对此类场景下的设备延迟差异进行优化：此时，播放器需要对帧跟踪进行微调，使A的播放速度能够赶上B、C。具体措施为如下：

追帧的原理是：当A的播放器超过6s时，就开始倍速播放，直到小于6s。这时，A将追上B和C。

帧追踪阈值为6s，帧追踪速度为1.4。这样设置的效果是，如果观看者A的延迟落后4s，那么追帧时间可以在10s内赶上B和C。实际阈值设置可以根据需要确定。原理上面就是在延迟满足需求的情况下尽量不触发追帧，保持正常速度播放。

OBS直播抖音_抖音直播obs教程手机_抖音直播obs推流码在哪里