抖音世界杯直播的低延迟是怎么做到的？

　　作者火山引擎直播团队
　　策划鲁冬雪
　　世界杯已经结束了，梅西带领阿根廷时隔三十六年之后终于如愿捧杯。抖音直播提供的4K超高清超低延迟看播能力给亿万观众留下了深刻的印象，决赛的PCU达到3700w，在这样大规模并发下，如何能稳定流畅地做到更低的延迟，是一个巨大的挑战。本文主要介绍世界杯期间火山引擎视频云和相关团队在低延迟上的工作和优化，作为低延迟方向上的总结。
　　本文主要讨论生产和传输环节的延迟。生产环节的延迟主要受视频流供应商控制，技术团队可以实现的是，尽可能准确地测量出生产的每一个环节的实际延迟，并在发现不合理的情况时推动供应商解决。传输环节的延迟技术团队更可控，也是本次优化的重点。这部分技术能力可以作为火山引擎视频云的优势能力积累并对外提供服务。在优化的过程中，一个越来越清晰的认知是：降低延迟并不困难，难的是延迟降低之后，怎么通过优化保证播放体验不下降甚至变得更好。一、背景信息
　　首先简单介绍下世界杯直播的整个分发链路，还有每个环节的延迟的测量方法，让大家对整体的链路有初步的全局认识。（一）抖音世界杯信号分发链路
　　（二）全链路延迟测量以及方法
　　测算方法：拍照视频画面上有时钟展示的（比如画面左上角或者右上角的北京时间或者比赛持续时间，一般精确到秒），可以通过同时拍照两个播放画面的方式，记录同一时刻两个画面，然后通过照片中的时钟做差来计算。手动秒表计算如果视频画面中无时钟相关内容，那么可以从延迟低的视频画面中选取具有标志性易识别的帧启动秒表，然后观察延迟高的画面出现同样的帧画面时，停止秒表，记录秒表结果为延迟对比结果。仅适用演播室推流到抖音播放链路
　　计算方法：端到端延迟观众当前系统时间戳SEI中的时间戳，单位ms。统计频度：每2s计算一次，每10s上报一次当前计算结果。每个I帧前会有一个SEI，流规格设置为I帧间隔为2s，因此每2s演播室推流侧会生成一个SEI帧。前置要求：演播室推流前进行NTP本地时钟校准。
　　延迟测量手册：
　　二、生产环节的低延迟（一）信号源
　　网络流信号源在给到抖音之前存在多个环节，每个环节都可能会对最终的延迟有影响，但这一部分技术团队可以影响的比较少，主要是运营同学在沟通。（二）演播室制作环节
　　演播室在收到央视的源流之后，需要加上解说和包装，所以也会引入一定的延迟。这次抖音的多个演播室是由多家第三方公司负责的，第三方公司的制作规格不一，在正式比赛之前经过大量的沟通，基本确认最重要的两个演播室的技术方案和使用的编码系统是一致的。
　　不过这次在演播室环节引入的延迟仍然偏高，达到了1。5s左右，和供应商工程师沟通后，短期内为了保证稳定，没有再进一步压缩了，这部分引入的延迟和竞品也是一致的。三、传输环节的低延迟
　　下图是一次直播的简化的流程：
　　直播的传输环节里，对延迟影响大的主要是转码、分发和播放缓冲，使用实时的转码模式，转码器引入的延迟一般在300ms以内甚至更短。CDN的分发环节也会带来一定的延迟，但相对也较短。为了对抗网络抖动引入的播放缓冲区引入的延迟播放缓冲引入的延迟常常会有5s甚至更多，所以本文主要讨论怎么在减少播放缓冲的情况下，通过不断地优化延迟降低的同时不影响整体的播放体验（不仅仅是卡顿）。在调优过程中，大家对播放体验也有了更细致、更深的理解，逐渐弄清楚了哪些QoS指标可以对关键的QoE指标产生直接的影响，对以后要优化的方向也更明确了。（一）FLV方案
　　FLV是现在国内主流直播播放使用的协议，火山引擎对低延迟直播的探索也是从FLV开始的。在百万英雄、内购会等活动中，FLV低延迟方案也多次得到了验证。
　　之前详细介绍过FLV3s方案在抖音落地的详细实践过程（细节内容可跳转到基于httpFLV的抖音直播端到端延迟优化实践），同时提出过基于FLV方案做更低延迟下探，所面临的挑战也会更大：更低延迟的场景对直播全链路的传输稳定性要求苛刻程度会几何倍数增加，由于端到端链路的整体buffer更低，生产环节或者观众网络抖动，就更容易发生卡顿。只要发生一次卡顿，延迟就会秒级增加，最终累积延迟会越来越大。而世界杯赛事延迟要求达到2s，继续延续FLV3s方案显然达不到要求，需要配合精细的追帧或者丢帧策略。1、基于buffer卡顿信息的双阈值延迟追赶策略
　　音视频数据流转时序
　　在展开描述延迟追赶策略方案细节前，先简单介绍播放器音视频数据流转时序：网络IO下载音视频数据到播放器缓存buffer解码器从buffer中取数据解码并降解码后的数据存入待播放缓存音画同步等播控策略渲染播放音视频帧。
　　数据驱动QoEQoS优化
　　由于进一步下探延迟，卡顿也会随之恶化，反而延迟逐渐累积增加达不到低延迟的效果，因此延迟下探必须配合延迟追赶播控策略来确保延迟增大后可及时追赶恢复到低延迟。是否只要在延迟增加后立即倍速追赶就能满足业务的需求呢？对于延迟QoS指标来说的确是，但对于用户主观体验的QoE指标，这样的策略反而可能是负向的。
　　结合历史AB实验以及DA详细数据分析，有以下几点倍速追赶与QoE指标之间的关联现象：倍速追赶带来的播放速度变化本身就是负面的体验倍速时长超过2秒，用户即可有感知且负向反馈倍速速度越大，播放速度前后变化diff越大，负向越严重倍速与正常速度的切换过于频繁，会带来负向反馈
　　综上，需要一套精细的播控策略兼顾延迟与QoE指标的平衡。详细方案设计如下：
　　输入：播放器当前Buffer时长、历史Ns内buffer抖动方差、历史Ns内卡顿信息以及追帧参数配置。
　　策略可配置参数以及含义映射：
　　输出：目标播放速度。
　　原理：基于buffer抖动方差历史卡顿信息，来定性衡量网络质量，判断是否可以追赶，只有在网络质量良好是才能触发追赶逻辑避免卡顿。追帧采用双阈值，并且支持可配置，可以控制追帧持续时长不超过2s，同时也可以保证不频繁变速。追帧速度可配置，保证倍速变化不超过一定辐度。2、FLV2s低延迟方案在抖音上调优总结
　　（1）收益总结FLV2s低延迟已在抖音验证收益：核心QoE波动，电商指标显著正向，成本也有一定比例的节省，目前已全量。世界杯：双端FLV2s方案作为世界杯低延迟方案之一，支持了开幕赛到决赛的全部赛事。
　　（2）调优经验总结无论播放过程中丢帧方式追赶延迟，还是卡顿后立即丢帧追赶延迟，只要是丢帧，QoE都是负向。iOS端对倍速负向没有Android敏感，对倍速容忍度高。精细化倍速追帧策略可以满足FLV2s的延迟需求，但再进一步下探延迟，就需要同时配合卡顿优化方案从源头避免延迟增加。（二）RTM方案
　　RTM的方案参考了WebRTC，可以让端到端延迟直接进入1s以内，已经持续在抖音上打磨了一年多，整体来说遇到的困难很大，在推进的过程也不断地发现了新的问题，也逐渐认识到，直接把RTC在视频会议上的方案应用到直播播放场景的效果并不好，需要做大量的改造才能让直播的体验得到抖音用户的认可。同时评测的同学也持续对行业内已经上线的类似方案进行了跟踪和测试，经过线上测试后，也发现现有多方案也存在很多问题，所以一直也没有停止自研。RTM优化的目标是在延迟降低的情况下，用户核心体验指标对齐或者优于大盘的FLV方案。但是由于FLV低延迟方案的持续优化并拿到结果，一定程度上RTM的优化目标的bar是在不断提高的。
　　每次迭代都要经过分析数据找到问题点提出优化方案完成开发和测试AB实验分析数据的反复循环，每一次循环的都需要至少一个版本甚至多个版本的周期，所以项目整体耗时较长。关于如何提升实验的效率，也做了很多思考和探索。最后通过多次的实验和反复的问题解决，在核心用户体验指标基本对齐了FLV，所以在世界杯的多场比赛中，RTM方案也承担了一定量级的CDN容量，核心键指标上都对齐了大盘，稳定性和质量得到了充分的验证。1、RTM方案优化概述
　　项目启动后，将RTC实时通信SDK直接集成进入播放器后首先进行线上AB测试，初期的实验效果显得大跌眼镜：除了端到端延迟指标符合预期以外无论是拉流成功率，首屏秒开时间，卡顿等指标均与FLV差距很大；所以RTC技术方案要顺利部署到直播场景，还需要配合直播播控策略进一步优化。
　　为了让RTM的综合指标对齐FLV，从若干角度来进行RTM的播控逻辑定制化，所有的优化围绕着核心用户体验指标进行展开：DNS节点优选、SDK信令预加载、UDP连通性预探测主要解决的拉流成功率相关问题。SDP信令相关优化主要解决信令时间消耗的问题（首帧时间）与成功率问题。RTC内核播控定制化主要解决播放的卡顿问题。播放器播控逻辑结合解决的音画同步与渲染策略的问题。2、首帧时间的优化
　　传统的RTC技术采用SDP信令方式进行媒体能力协商，SDP信令通过如下图方式进行交互参见下图：
　　但是HTTPSDP信令交互存在如下方案的弊端：弱网环境下（如RTT较大网络信号不稳定），HTTP信令建联成功率不理想；导致播放请求响应缓慢或超时（基于信令数据包庞大且发生TCP重传导致信令响应速度不理想）；另一方面SDP交互传输SDP文本的内容很大（通常3KB10KB）建联的成本较高导致初始化的成本无法忍受；对比FLV的HTTP请求完成后直接完成建联和媒体数据直接传输，可以采用新的信令模式：MiniSDP信令。这是一种基于二进制编码的压缩协议，提供对标准SDP协议进行压缩处理；这种方案可以降低信令交互时间，提高网络传输效能，降低直播拉流首帧渲染时间，提高拉流秒开率成功率等QoS统计指标。其作用原理是将原生SDP转换成更小的二进制格式（300bytes）通过一个UDP包（MTU限制之内）完成整个CS交互。
　　采用MiniSDP信令进行媒体协商通信的信令交互流程如下图所示：采用MiniSDP压缩信令方式利用UDP网络传输；预期单个UDP数据包请求即可完成SDP完整压缩信息的传输。
　　当前MiniSDP信令（UDP）信令上线后观察后续的QoS指标发现，信令建联的成功率和首帧时间得到了大幅度的优化。3、拉流成功率的优化
　　经过线上的AB实验发现：RTM拉流成功率相比FLV持续存在着一定的差距，而且这种差距经过观察得知：用户的网络等级质量和用户的拉流成功率存在一定的正相关性（UDP协议本身特性），即用户网络质量越高成功率越高。
　　拉流网络等级筛选
　　根据网络质量预估信息综合评估用户的TCPUDPRTT和数据下行吞吐率，得出用户网络等级；选择网络质量优异的用户采用RTM拉流降低失败率。
　　当线上AB实验采用网络等级漏斗进行网络筛选以后，选择用户网络情况相对较好的这一部分的用户开启实验（这部分用户占全网用户的绝大部分，剩余的用户采用默认FLV低延时），原理就是用户在拉流前综合权衡当前网络状态，当网络不适合RTM时候通过策略前置回落到FLV，使得这部分用户的体验不受到影响。
　　UDP节点探测
　　拉流前根据用户请求的URL所归属的对应CDN边缘节点，发起UDP探测；一段时间内发送数据包观察对应CDN节点的数据RTT和丢包率，只有满足一定条件（如RTT80ms且丢包率10）的场景才会认为UDP传输可以保证质量和组帧成功率。
　　信令预加载
　　在当前点播直播房间中，预先加载后一个直播间的信令信息，提前做好SDP加载，降低下一个房间的首帧上屏时间。4、卡顿的优化
　　内核JitterBuffer禁用丢帧优化
　　未调优时候经过AB实验发现，RTM的视频卡顿大幅度上涨，跟预期不匹配，对此团队分析了线上的大量日志数据观察。当前的硬解具有核心用户体验指标的收益，但卡顿是FLV的将近3倍，分析了大量线上badcase，发现部分机型网络条件较好，但帧率却极低，类似下表这种：
　　这种问题在部分高热机型上的比例也是很高的，但同样的机型，FLV播放并无这样的问题，通过对比FLV和RTM的播控策略，发现了一个关键不同点传统的RTC场景优先保时延，全链路会触发各种丢帧（包括但不限于解码模块，网络模块），FLV直播场景会优先保证观播体验（不丢帧，良好的音画同步效果）。RTM要想减少卡顿，取得QoE的收益，播控策略需进行定制化，不影响连麦场景下的逻辑，内部采用新的播控策略，最后上线后卡顿显著减少。
　　RTC内核JitterBuffer平滑出帧优化
　　5、播控逻辑的优化
　　RTM网络传输SDK的抽象：将内核进行改造，复用引擎中的网络传输组包JitterBufferNetEQ模块；去掉解码渲染等模块；将音视频的裸数据抛出供播放器demuxer集成。
　　解码器复用：降低解码器重新初始化的时间，降低解码首帧延时；复用解码器渲染器的播放缓冲区控速逻辑。
　　音画同步的优化：RTC音视频出帧之后在播放器侧按照FLV的播控逻辑进行二次音画同步处理；按照audiomasterclock主时钟进行渲染校准，视频帧渲染同步到音频时间轴上。6、RTM针对世界杯的优化
　　本次世界杯超高清档位的分辨率达到了4K，对RTM方案的性能带来了很大的挑战，在前期测试时也发现了一些低分辨率没有的问题。当时时间非常紧，不过在正式比赛之前，还是完成了这些问题的修复，赶上了最后一班车。主要的问题和解决方案如下：4K高清档位卡顿严重卡顿：优化NACK策略，保证更大的帧的组帧成功率。CPUGPU内存：优化video传输pipeline，减少不必要的raw数据格式转换。
　　最终在性能和效果都通过了测试，RTM在世界杯期间也顺利上线，承担了一定的流量，上线后稳定性和质量都符合预期。（三）世界杯中抖音和其它产品平均的延迟对比
　　在实际的世界杯比赛中，抖音的延迟一直领先于相同信号源的其它产品30s左右。即使最后两场其它产品在个别直播间上了快速追赶策略比抖音快01s，但追的速度过快且持续时间超过15s，有明显感知，体验相对较差，这种策略在抖音上也曾经做过AB实验，播放时长是显著负向的，所以最后并没有跟进。四、未来的优化方向
　　未来在高清、沉浸、互动的直播场景中，针对高码率、低延迟的需求，火山引擎视频云会继续打磨现有的适合不同场景的各种低延迟的方案，同时也会不断地探索新的方案，在延迟、成本、卡顿和其它播放体验上找到适合不同场景的最佳或者最平衡的方案。
　　在我看来，火山引擎视频云的最大的优势，在于可以把先进的技术放到真实的海量用户的场景去做线上训练，通过不断地总结失败的教训和成功的经验，对用户体验有更深更细微的理解。下面简单介绍一下火山引擎视频云在各个方案上继续努力的方向。（一）FLV
　　追帧策略实现更细粒度的追帧，做到按需追帧，避免不必要的追帧，引起QoE的负向。挖掘合适的传输框架，建立与边缘云节点（发送端）交互的通道，实现云端联动的拥塞控制算法，优化卡顿，避免延迟增加。目前大盘的平均延迟已经有了相当程度的降低，但有一小部分长尾用户的延迟是很大的，后期的优化方向也会适当地侧重到这部分长尾用户，让更多的长尾用户能享受到真正的低延迟，降低观看同一直播流的观众间延迟差，满足基于流内容的一些强互动玩法，比如倒计时跨年。FLV低延迟协议标准化：沉淀适用不同直播场景（电商、赛事、游戏、演唱会等）、不同网络环境、可一键部署的套餐方案。（二）RTM
　　在RTM方案上，火山引擎视频云还在不断地发掘优化点。以下几点是未来会继续探索的几个方向：
　　拉流成功率的持续改进
　　从SDK技术层面共性差异看，RTM协议中的RTP包组首帧存在成功率短板，后续的成功率优化需要从引擎的调优持续探索。
　　RTP扩展特性的持续迭代降低首帧时间缩小和FLV的差距：RTM异步回源的深入探索，目前只有一家CDN支持，需要推广至其它CDN。进一步探索提升RTM的拉流成功率（针对用户网络不佳的场景）：探测ICE多模式启播能力对成功率的提升，明确各家CDN支持RTM启播TCPUDP及混合模式的能力。
　　RTM是降低延迟的一种全新方案，为了把在海量用户的业务上积累的经验和教训反馈给整个业界，火山引擎视频云也联合腾讯和阿里发起了RTM行业标准的制订，具体可以参考https：www。volcengine。comdocs6469103014，未来也会把标准推广到更多的CDN，不断完善的同时，和业界一起向更低延迟演进。（三）切片类协议的延迟优化
　　海外的CDN基本都只支持切片式的协议如HLSDash等，不支持FLV这类过时的传输协议。但HLSDash因为切片的存在，而且为了保证视频的压缩率，切片一般都是秒级的，且需要切片完全生成才能分发该分片，并且需要至少两三个分片都生成完才能分发，所以和流式的协议相比，延迟上天然有一些劣势。其实这也是竞品使用的方式，如下图，每个分片6s，在三个分片生成完后才可以分发，带来了23s的延迟。世界杯期间，在视频同源的情况下，其它产品的延迟显著高于抖音，就是因为使用了类似的HLS的切片传输方案。
　　但随着Akamai和Apple分别提出了CMAF和LLHLS，引入了fmp4和chunk的概念，可以实现分片没有完全生成的时候就开始分发分片的部分chunk，延迟下限有了很大程度的下降。如下图，延迟可以降到1s。
　　火山引擎视频云在Apple提出LLHLS之前就跟进了CMAF，在CMAF的延迟和卡顿、拉流成功率上的优化上也持续有不小的投入。现在回顾CMAF的优化的过程，可以发现其实要解决的问题和RTM有很大的相似性，比如CMAF也存在拉流成功率、音画同步、性能问题，优化前在核心体验指标上同样显著差于FLV。
　　与FLV的流式传输不同，CMAF需要依赖用户不断发起各个分片的请求来获取音视频数据，如果继续采用FLV的请求模式，即建连请求响应断开连接，会引入大量的建连耗时，造成卡顿，同时导致延迟的增大。做一个简单的计算，假设每个切片是2s，那么平均1s就会有一次音频或视频请求的建连，这对于网络较差，尤其是高RTT的用户来说是不可接受的，如果此时为了低延迟强行降低buffer水位，建连时的缓存消耗将导致频繁的卡顿。
　　为此，可以在CMAF上采用QUIC协议与连接复用结合的方式，首先QUIC协议的0RTT建连允许客户端在服务端确认握手成功之前就发出HTTP请求，而连接复用直接省去了后续请求的建连操作，大幅优化了建连耗时，维持延迟的稳定。但即使如此，每个分片的请求也会引入1RTT的延迟，未来将与服务端一起探索预请求模式，进一步压缩延迟、降低卡顿。
　　CMAF优化的整体难度较大，团队同学也经常需要在半夜和海外的CDN的工程师对齐和解决问题。不过经过不断的努力，最近在部分地区的也已经有了阶段性的进展，在部分场景下核心指标已经对齐FLV，团队也有信心在最近一段时间就能去掉机型和网络类型的限制，让CMAF可以承载更多常规比例的流量。（四）XR直播的延迟优化
　　XR直播的沉浸感以及高交互性是普通直播无法比拟的，但是这也导致了传输层需要承担更大的压力：分辨率为8Kx4K或8Kx8K，源流码率达到50M甚至120M、非常容易因为拥塞导致卡顿、延迟增大，甚至无法正常解码播放。火山引擎视频云的做法是将8K的视频切分成多个块（tile），只传输用户视角（viewport）内的部分超高清块，其它区域只传输2K或4K分辨率的缩小后的背景流，在用户切换视角的时候再去重新请求新的超高清块。当然这里需要把切换延迟尽可能降到更低，经过长时间的优化，切换延迟已经降低到非常低，一般情况下已经感受不到切换的过程，未来会持续优化，让切换延迟更低。
　　这两种做法都引入了优先级的概念，即用户视角内的数据优先级高于其他部分，低清数据优先级高于高清数据。基于这种特性，火山引擎视频云将探索基于UDP的内容优先级感知的传输方案，优先保障高优数据的传输，对于低优数据可选择非可靠传输，即使丢失也无需重传，保证XR直播低延迟的同时不引入过大的视觉失真。经过优化后，在传输8Kx8K8Kx4K的超高清视频时对播放端的码率要求从120M50M降低到20M10M左右甚至更低，在用户侧极大地减少了卡顿发生的概率，从而也减少了延迟增大的概率。
　　未来火山引擎视频云也会持续优化XR直播下在更高码率更高分辨率下的卡顿和延迟，为用户提供更沉浸的观看体验。