作者|张东辉延迟是怎么来的？传统直播方案（http-flv、RTMP等）的架构和时延水平如下图所示：以抖音直播为例，直播链路各环节的时延贡献为如下：推流端——网络平均延迟20~30ms，编码延迟取决于编码参数设置。流媒体服务——流式转码场景下，会引入额外的300ms~2s转码延迟（大小与转码参数有关）。如果直接播放源码流，会出现没有转码的Code延迟播放端——网络延迟大约100ms~200ms，主要是链路分发节点之间的传输延迟；防抖缓冲-5~8s从各个环节的延迟贡献，很容易得出一个直观的结论：端到端端到端延迟过大，主要是播放器的防抖缓冲造成的。这种表面现象往往导致很多同学认为减少播放器的缓冲就可以减少延迟。这句话是真是假取决于从哪个角度来解释它。在争论这个结论之前，我们先拆解一下，详细介绍下直播整个链路的延迟：上图主要是比较详细的拆解了流媒体服务链路，也就是CDN传输链路，拆解成上行（流接收节点和上层节点），源站，下行链路（上层节点和拉流边缘节点）。各链路延迟归因如下：主播端（streamer）主要包括编码延迟和发送缓存引入的延迟（大部分主播网络较好，发送缓存延迟平均只有20-30ms），而且这个环节的延迟优化空间不大，虽然通过调整编码器参数可以有效降低编码延迟，但是带来了画质的损失，也影响了压缩效果，所以大部分重点优化弱网传输（但出发点是为了给用户提供流畅的观看体验，而不是为了降低延迟）收流边缘节点&中间链接对于不需要分片的http-flv协议，每个节点CDN传输的节点收到流数据后，会直接将流数据转发给下一个节点。该链路中的主要延迟是由链路传输引起的，它与链路长度正相关，一般平均不超过200ms。如果播放端拉转码流，那么在网络传输延迟的基础上，会额外增加一个转码延迟（目前各大CDN厂商的编码延迟在300ms到2s左右），包括解码延迟和转码延迟。B帧场景下，解码延迟较小，主要是编码延迟。编码延迟主要受编码器缓存的帧数影响。假设FPS=15，则缓存6帧，延时400ms。这部分延迟与流式编码延迟相同。也可以通过调整转码参数来降低转码延迟，但是也会造成画质和压缩率的损失，所以这部分延迟需要根据实际场景综合考虑。如果延迟要求很高，可以调整。拉边节点不考虑回源的情况。这个环节的主要作用是gop缓存策略（有的CDN厂商也称其为quickstartbufferstrategy或quickstartcache），即边缘节点缓存一个流的最新gop（一般平均媒体时长为5-7秒）。目的是在流媒体请求建立时实时发送媒体数据，并对首帧进行优化和卡顿，导致播放器收到的首帧数据为5-7s前的旧数据，第一帧延迟达到5-7s（这个环节是端到端延迟过大的根本原因）。CDNgopCache的逻辑字节与CDN厂商沟通，约定gopcache先按照下限下发数据。例如下限为6s，表示先在缓存数据中定位到最新的6s数据，然后在第一个关键帧中查找6s之前的旧数据发送，保证第一帧和第一个帧之间的时间latestframeisnotlessthan6s：如上图所示，如果不考虑生产端和中间环节之间的延迟，那么7.2s的缓冲长度可以近似认为是从起始端到结束playback在播放器正常播放，没有卡顿的前提下，这个延迟会一直持续到你退出直播间，不会改变。这里给出一些初始延迟计算的通用公式：延迟分配区间[M,M+gop]s，平均延迟为M+gop/2，其中M为gopCache策略的下限，gop为固定大小编码gop的值。例如抖音showgopsize固定为2s，假设gopCache下限为6s，则观众合理的端到端延迟分配区间为：[6,8]s，根据用户的时间点request，所有viewer的时延会统一分布在这个区间内，所以不同viewer之间的时延差异不会超过一个gop的长度最多2s（这是优化设备间时延差异的理论基础）。viewer(player)播放器在io模块中有一个allocatedbuffer（抖音Onlineallocationbufferisupto20s，即最多可以容纳20s的媒体数据。其实buffer越大越好，抗网络抖动能力越强），用于存储从CDN边缘节点下载的流媒体数据。播放器下载是主动下载。在可分配缓冲区队列未满的前提下，io线程会不断下载流媒体数据并存储到缓冲区中，直到没有空闲缓冲区可用。因此，当观看者的网络状况良好时，用户请求播放并建立链接后，CDN边缘节点的快速启动缓冲区会很快下载到播放器的缓冲区中，消耗速度后续渲染环节远低于i/o下载速度，这样端到端的延迟主要分布到播放器的缓冲区。但也只是说明，直播开始后，直播链接的延迟是从CDN的gopCache转移到播放器上的，播放器缓存不是延迟的根本原因。因此，降低播放器的最大缓存缓冲区并不能降低延迟。如果换个角度理解，减少播放器缓冲区中实际缓存的数据会减少延迟是正确的，比如通过倍速播放或丢帧。了解了全链路延迟是如何产生的，我们可以确认以下几点：initialdelay的大小已经确定了，这个延迟对应我们的QoS指标——第一帧延迟影响延迟。主要有两个因素：CDN边缘节点gop缓存策略（5~7s延迟）和videostreamgopsize（会造成gop延迟diff的大小）clientbuffersize和延迟大小没有因果关系。缓冲区的大小只会影响延迟在整个链路的分布，而减小播放器的缓冲区大小只会降低抗抖能力，加剧卡顿。降低延迟和降低延迟的有效手段包括：减少CDN的gopCache，这是提高缓存中视频数据消耗速度的根本手段，也可以有效降低延迟，比如倍速播放或者直接丢弃媒体数据。在gopCache不变的前提下，减小gop也可以降低平均端到端延迟。例如，将gop=4s调整为2s，平均端到端延迟减少1s。为什么要优化延迟？传统直播技术的时延非常大，从观众评论到看到主播反馈一般需要5-10秒以上。几个典型的尴尬场景：单个用户延迟大，导致在线教育体验差，学生提问，老师已经覆盖了下一个知识点，然后返回回答。电商直播，索取宝贝信息，主播“视而不见”捐出打赏后，久久听不到主人口头的感谢。假设端到端延迟为6s，那么在在线教育和电商直播两个场景下，交互延迟从面对面的0s增加到12s，如下图所示：rewarding场景，交互延迟从面对面的0s增加到6s，如下图所示：不同的用户延迟差异较大，导致体验不佳。当球被别人的喊声打进时，你还看直播吗？该场景下的延迟体验问题并不是一个推流请求的端到端延迟高导致的，主要是不同用户之间的延迟不一致，如下图所示：延迟影响直播互动体验，阻碍直播对于一些场景的落地，尤其是在电商直播中，直播间的评论和提问是观众与主播互动的重要手段。主播的实时互动反馈对于直播间的活跃度和交易的达成至关重要。以上两种延迟体验差的场景分别对应我们QoS指标中的平均端到端延迟和延迟设备差异，延迟相关的优化也会基于这两个指标。时延体验优化实践案例百万大侠答疑直播流链路时延要求所有观众端到端时延均在6s以内——对应不同观众间直播时的首帧时延和平均端到端时延指标A,B,CLatencyin2stoavoidout-of-syncanswer—对应设备时延差异指标需求分析。终端延迟不是优化的重点，只要满足6s的要求即可。用户场景多为面对面或实时语音群答题，对彼此之间延迟不一致的现象非常敏感。因此，保证设备间延迟差异尽可能小是核心需求点解决方案方案满足延迟在6s以内——调整gopCache和gop大小gop=2s，gopCache下限为5s，则第一帧延迟在[5s,5+2s]内分布，平均延迟为(5+(5+2))/2=6s，具体措施如下：每个CDN的快速启动策略需要设置为较低先limit，快速启动缓冲阈值为5s。推流参数设置需要设置为gop=2s，并且要保持稳定：保证用户观看同一个流，timedelaydiff2s内转码的配置需要保持gop=2s的配置，以及I帧对齐：保证用户观看不同的转码流，delaydiff在2s内的延迟差异只有在2s内调整gop=2s后才能保证vv已经流畅播放不卡顿，直接在各个之间的delaydiff其他在2秒内。但是，对于在观看过程中出现卡顿的用户来说，累积延迟会增加，延迟diff会越来越大，恢复正常播放，则A的端到端延迟增加4s。如果A、B、C是小伙伴组队答题，A的问题解释永远落后于B、C，这是非常糟糕的体验。因此，需要对此类场景下的设备延迟差进行优化：此时播放器需要对帧进行跟踪微调，使A的播放速度赶上B、C。具体措施如下：追帧原则是：当A的播放器缓存超过6s时，开始倍速播放，直到缓存低于6s。此时A追上了B和C。1.4，当这样设置效果时，观众A可以在延迟4s的情况下通过追帧10s追上B和C。实际的阈值设置可以根据需要确定。原则上，当延迟满足需求时，尽量不触发追帧，保持正常速度播放效果。与最初的百万英雄答题相比，用户反馈的延迟和不同步大大降低了4s。低延迟字节应用内购买将直播类似于百万英雄的流媒体链接。所有观众的时延要求端到端时延在4s以内——对应首帧时延和平均端到端时延指标的差值。当用户听到主播说链接时，尽量与购物链接的弹出时间一致——对应设备延迟差异指标需求分析内购会有电商主播带货，所以他们对交互延迟很敏感。内购将是大规模的团购活动。员工将在他们的工作站面对面参与，因此他们也会对设备延迟很敏感。方案推送&转码流配置配置项值配置方式推流gop2sOBS流媒体配置转码gop2s转码模板CDN侧相对于百万英雄接听场景，内购对交互延迟比较敏感，这里需要为百万英雄做特殊配置-heroanswer，因为各个厂商默认的是gopCache策略，平均端到端延迟在6s左右。如果达不到4s的要求，需要通过配置url查询参数来控制厂商的gopCache策略，保证延迟在4s左右。播放参数配置详情延迟级别：4s参数配置目标：降低不同设备间的延迟差异，将用户延迟分配控制在【3000ms，4000ms】以内，保证设备间的延迟差异最多不超过1s-延迟低的用户播放慢一点，延迟高的用户追帧，这样才能更准确的控制设备延迟差低于gop长度2s倒计时确认定时内购会链接或答题。链接或发帖倒计时时间根据现场助理看播延迟时间确定。由于在快放和慢放之间对齐设备时延的过程，建议小助手先看直播1分钟，待时延稳定后，确认倒计时效果，接受线下演练和流媒体内容时延不同之间的时延官方领域的设备。进入广播后调整了速度和速度，延迟基本稳定在4s，并且不会超过1s。主播广播的“上行”与实际链接的弹出延迟差异在1s以内。抢购体验不错，基本没有滞后反馈。时长、观看渗透、留存等核心经营指标显着向好。电商GMV、充值奖励等收入指标显着为正。传统直播场景需求分析。不同的观众往往同时观看不同主播的直播，也往往是各自独立观看。对于同一个直播间，不同观众对延迟一致的需求基本不存在，所以延迟设备的差异不是优化的关键指标。秀场直播、直播带货等场景属于强交互场景，对交互时延要求高。这个需求的核心优化点是端到端的时延解决这个需求场景的受众都是抖音的直播用户，网络质量也参差不齐。为了保证降低延迟的需求目标得到满足，我们还需要保证看直播的流畅度不会太负Latency解决方案gop降低到2s，gopCache下限参数为1800ms，延迟范围为[1800+200ms，3800+200ms],average3sStutter优化方案先验知识科普启动缓冲策略：指的是第一帧渲染完成后，需要等到播放器的音频缓冲达到一定阈值后才能继续播放，可以增加网络抗抖能力网络评分1~8：8——相当于很好的4G网络；7—相当于更好的4G网络；6—相当于一般的4G网络；5—相当于4G网络不好；1~4—网络质量差基于网络质量的个性化启动缓冲策略设计设计的基本原则是基于网络分类，自适应调整启动缓冲设置启动缓冲最大调整间隔为[0,850ms]不同的网络等级映射到不同的启动缓冲间隔随着网络等级变差，启动缓冲档位的增加速度也加速了同一网络等级的不同vv，根据Retry和freezetimes是可以的-调整网络分类的启动缓冲间隔。随着卡顿次数的增加，相应档位范围内的起步缓冲器微调幅度逐渐减小。对于同一个app启动周期，出现多次直播vv的情况，需要考虑在最近一次直播中的freeze和retry，freeze和retry的影响权重随时间衰减QoS好处：负减少20%的freeze是基于网络质量的个性化延迟策略根据数据统计发现，网络1~4级的vv占比为5.54%，但stall指标贡献了47.83%。结合这种需求场景，设备之间的延迟差异不是核心指标，所以可以通过个性化延迟来优化延迟。方案设计的基本原理是基于网络分类，自适应调整延迟不同的网络分类映射不同的gopCache下限随着网络分类变差，延迟逐渐增加QoS收益：30%的延迟负减少+客户端控制CDN延迟优化策略在需求提升的过程中发现了两个奇怪的现象：在网络质量足够好的场景下进行离线测试，发现低延迟更容易触发CDN的丢帧策略（优化freeze的策略），导致渲染卡（与CDN沟通后，CDN方不愿透露过多的丢帧策略细节，无法验证根本原因。）AB实验时，某CDN厂商主动发起攻击丢帧策略，网上反馈很多，从用户反馈来看，基本上是freezet进了直播间。推测用户在启动阶段对丢帧和卡顿比较敏感。阶段更容易丢帧，启动时丢帧会严重影响QoE体验。因此，控制CDN丢帧策略对QoS（视频渲染冻结）和QoE有积极的优化作用。控制规则如下：参数名称说明规则protected_periodstreamingsession丢帧保护时间：请求开始前n毫秒不能丢帧。protected_period=0：表示整个推流过程中不能丢帧；whenvalue>0，比如protected_period=5000：表示streamingsessionFrames在前5000ms内不能掉帧，5000ms是以系统时钟的纬度（本地时间）来衡量的，对应的gop必须保持发送给用户的视频流总时长不低于2000msQoS收益：FLV低延迟渲染卡顿负降低30%左右最终效果验收QoE指标收益核心业务指标：直播人均viewingtime,viewingtime渗透率和留存率等收入相关指标显着正向：电商商户按单付费、支付渗透率、充值等Qos指标显着正向端到端延迟：3.24s滞后：增加13%由于低延迟gopCache，在带宽成本方面的优势，延迟减少到3秒。相比7s高延迟的FLV，开始播放时会少下载4s的数据，尤其是抖音直播流占70%，所以低延迟的FLV可以节省不必要的带宽成本。延迟的成本收益为10%后期思考思考一：受众对交互延迟的感知是否出现拐点，延迟降低到一定程度，用户无法感知？我们来思考三种典型的交互场景：观众评论，主持人看到评论并进行口头广播回应互动：观众在对话框中输入评论的平均时间至少为2秒。减少交互延迟是否有益？观众打赏送礼，主播口头感谢互动：假设观众的打赏平均耗时1秒左右，打赏后互动延迟3秒。此时的延迟水平是否足以满足观众对主播回应主播感谢的需求？？直播带货场景：无论“上行”弹窗是否与实际链接一致，还是秒拍场景，核心延迟指标是设备间的延迟差异指标会影响体验，实际端是否-to-end延迟实际上是对观众而不是交互延迟敏感？思考2??：在传统的标准直播http-flv场景下，是否可以基于本文介绍的方法，继续探索更低的延迟，比如1s？可以做个人判断，但要面对的挑战更多。需要更精细的播控策略来平衡延迟和播放流畅度。比如tcp/quic等传输协议场景，开始广播时CDN侧有带宽。(最佳发送速率)检测算法逻辑，根据实际发送数据检测结合ACK等反馈信息来提高发送速率，那么这里有一个问题——继续减小gopCache，满足延迟降到1s，但也会导致CDN用于发送检测的数据量会变少，不足以检测网络链路的实际带宽，从而降低gopCache阶段的平均发送速率，抗网络抖动的能力下降急剧，而且还会影响首帧，所以为了进一步探究延迟，需要播放器和CDN相互配合，优化启动包速率，保证流畅度不太消极。低延迟场景对延迟的要求也非常高，更容易卡顿。一旦卡住，延迟很容易呈指数增长，最终无法减少延迟。延迟的进一步探索还需要精细的帧跟踪或帧丢弃策略
