降低延迟是一个巨大的挑战。本文主要介绍世界杯期间火山引擎视频云及相关团队在低延迟方面的工作和优化，作为低延迟方向的总结。本文重点关注生产和交付方面的延迟。制作环节的延迟主要由视频流提供商控制。技术团队能做到的是，尽可能准确地衡量生产中各个环节的实际延迟，发现不合理的情况，推动供应商解决。传输环节的延迟技术团队更加可控，这也是本次优化的重点。这部分技术能力可以作为火山引擎视频云的优势能力进行积累，对外提供服务。在优化的过程中，越来越清晰的认识是，降低延迟并不难，难的是降低延迟后如何通过优化保证播放体验不下降，甚至变好。一、背景资料首先简单介绍一下世界杯直播的整个分发链路，以及各个链路的时延测量方法，让大家对整体链路有一个初步全局的了解。1.1抖音世界杯信号分配链路1.2全链路时延测量及方法测量方法：照片视频画面上有时钟显示（如北京时间或左上角或右上角的比赛时长）屏幕一角，一般精确到秒），可以通过同时拍摄两张回放画面来同时记录两张画面，然后通过照片中时钟的差值来计算。手动秒表计算如果视频画面中没有时钟相关的内容，可以从低延迟视频画面中选择一个标志性的、容易识别的帧启动秒表，然后在高延迟画面中观察同一帧画面，停止秒表并记录秒表结果是延迟比较结果。仅适用于直播间推送到抖音播放链接计算方式：端到端时延=观众当前系统时间戳-SEI时间戳，单位ms。统计频率：每2s计算一次，每10s上报一次当前计算结果。每个I帧前都会有一个SEI，码流规范设置了一个I帧间隔2s，所以演播室推流端每2s会产生一个SEI帧。前置要求：在直播间进行流媒体播放前，需要进行NTP本地时钟校准。延迟测量手册：2.生产环节低延迟2.1信号源网络流量信号源在给抖音之前有多个链路，每个链路都可能对最终的延迟有影响，但是这部分技术团队可以影响比较少，主要是运维同学在交流。2.2演播室制作流程演播室收到央视源码流后，需要添加解说和包装，因此也会引入一定的延时。抖音的多个工作室负责多个第三方公司。第三方公司的生产规格不同。经过正式比赛前的大量沟通，两个最重要工作室的技术方案基本确定。它与使用的编码系统一致。不过这次在演播室环节引入的延迟还是偏高，达到了1.5s左右。与供应商工程师沟通后，为了保证短期内的稳定性，没有进一步压缩。这部分引入的延迟也与竞品一致。3.传输环节低时延下图是一个直播的简化流程：在直播传输环节，转码、分发、播放缓冲是影响时延的主要因素。采用实时转码方式，转码器引入的Latency一般在300ms以内甚至更小。CDN分发链路也会带来一定的延迟，但是比较短。为了对抗网络抖动引入的播放缓冲区引入的延迟，播放缓冲区引入的延迟往往有5s甚至更长，所以本文主要讨论如何在不影响整体性能的情况下，通过不断优化延迟来降低播放缓冲区.演奏经验（不只是口吃）。在调优的过程中，大家对播放体验有了更细致、更深入的了解，也逐渐摸清了哪些QoS指标可以对关键的QoE指标产生直接影响，未来要优化的方向也更加明确。3.1FLV解决方案FLV是目前国内主流直播使用的协议，火山引擎对低延迟直播的探索也是从FLV开始的。FLV低延迟方案也在百万英雄、内购交易会等活动中得到了多次验证。之前在抖音中详细介绍过FLV-3s方案的详细实践过程（详情可跳至基于http-的抖音直播端到端时延优化实践）FLV），同时提出了基于FLV的低延时下拉解决方案将面临更大的挑战：低延时场景对全链路传输稳定性的要求将呈指数级增长。直播，由于端到端链路整体缓冲较低，制作环节或观众网络抖动，更容易卡顿。只要出现卡顿，延迟就会以秒为单位增加，最终累积的延迟会越来越大。但是世界杯比赛的时延要求达到2s，延续FLV-3s的方案显然达不到要求，需要配合精细的追帧或者丢帧策略。3.1.1基于buffer&freeze信息的双阈值延迟追赶策略的音视频数据流序在详细描述延迟追赶策略之前，简单介绍一下播放器的音视频数据流序:网络IO下载音视频数据到播放器缓存缓冲区->解码器从缓冲区中解码数据并将解码后的数据保存到缓冲区中进行播放->音视频同步等播放控制策略->渲染播放音频和视频帧。Data-drivenQoE&QoSoptimization随着延迟的进一步降低，卡顿也会加剧，但延迟会逐渐增加，达不到低延迟的效果。因此，延迟检测必须配合延迟追赶广播控制策略来保证延迟增加。可以及时赶上恢复到低延迟。是不是只要延迟增加，马上赶上，就可以满足业务的需求？对于时延QoS指标来说确实如此，但是对于用户主观体验的QoE指标来说，这样的策略可能是负的。结合历史AB实验和DA详细数据分析，倍速追赶与QoE指标存在以下关联现象：倍速追赶带来的播放速度变化本身就是一种负面体验。负反馈倍速越高，前后播放速度差异越大，负向越严重。双速和常速的切换过于频繁，会带来负反馈。总之，需要复杂的广播控制策略来同时考虑延迟和QoE指标平衡。详细方案设计输入：播放器当前缓冲时长、历史Ns中缓冲抖动方差、历史Ns中停滞信息、追帧参数配置。策略可配置参数及含义映射：输出：目标播放速度。原理：根据bufferjitter方差和历史stall信息，定性衡量网络质量，判断能否赶上。只有当网络质量好的时候才能触发追赶逻辑，避免卡顿。追帧采用双门限，支持可配置，可以控制追帧时长不超过2s，也可以保证不频繁的速度变化。可以配置帧率，保证速度变化不超过一定范围。3.1.2FLV2s低延时方案在抖音上优化收益总结总结FLV2s低延时在抖音上得到验证好处：核心QoE波动大，电商指标显着正，成本也节省了一定比例。全额。世界杯：双端FLV-2s方案作为世界杯低延时方案之一，支持从开幕式到决赛的所有赛事。调优经验总结不管是播放时掉帧追延迟，还是卡顿后立即掉帧追延迟，只要掉帧，QoE都是负的。iOS端对倍速底片的敏感度低于Android，对倍速的容??忍度较高。精细化的倍速帧跟踪策略可以满足FLV-2s的延迟要求，但要进一步挖掘延迟，还需要配合卡顿优化方案，从源头上避免延迟增加。3.2RTM解决方案RTM解决方案是指WebRTC，可以让端到端延迟直接在1s以内。在抖音上打磨了一年多。总体来说遇到了很大的困难，在不断的推进中发现了新的问题，逐渐意识到直接把RTC在视频会议中的方案应用到直播场景中效果并不好，需要做大量的修改才能让直播体验被抖音用户认可。同时，评测同学也持续跟踪测试业界已经上线的同类解决方案。上线测试后，他们也发现现有的多种方案存在很多问题，所以一直没有停止自主研发。RTM优化的目标是在用户核心体验指标降低的情况下，在更广阔的市场上与FLV解决方案持平或超越。但由于FLV低延迟方案的不断优化和取得的成果，RTM的优化目标bar在一定程度上也在不断提升。每次迭代都要经历分析数据->发现问题点->提出优化方案->完成开发测试->AB实验->分析数据的反复循环，每个循环至少需要一个版本甚至多个版本的循环，所以整个项目需要很长时间。对于如何提高实验效率，也进行了大量的思考和探索。最后通过多次实验和反复解决问题，核心用户体验指标基本向FLV看齐，所以在很多世界杯比赛中，RTM方案也承担了一定的CDN容量，核心关键指标都向大市场看齐，稳定性和质量得到充分验证。3.2.1RTM方案优化概述项目启动后，直接将RTC实时通信SDK集成到播放器中，先进行在线AB测试。最初的实验结果令人惊讶：除了端到端延迟指标达到预期外，无论推流是否成功，FLV与FLV在码率、首屏打开时间秒级等方面都存在较大差距，冻结等指标；因此，RTC技术方案要想在直播场景中成功部署，还需要结合直播控制策略进一步优化。为了使RTM的综合指标与FLV保持一致，从多个角度自定义RTM的播放控制逻辑。所有的优化都围绕核心用户体验指标进行：DNS节点选择、SDK信令预加载、UDP连接预检测。解决了与流媒体成功率相关的问题。SDP信令相关优化主要解决信令耗时（首帧时间）和成功率问题。RTC内核播放控件的自定义，主要解决播放卡顿的问题。结合播放器播放控制逻辑解决音视频同步和渲染策略。3.2.2首帧时间优化传统的RTC技术使用SDP信令来协商媒体能力。SDP信令交互如下图所示：但HTTPSDP信令交互存在以下方案的不足：弱网络环境（如RTT大/网络信号不稳定），HTTP信令连接建立成功率不理想;导致播放请求响应慢或超时（基于巨大的信令包和TCP重传，信令响应速度不理想）；另一方面，SDP交互传输SDP文本的内容非常大（通常为3KB~10KB），建立链接的成本很高，导致初始化成本难以承受；与FLV的HTTP请求相比，它可以直接完成媒体数据的链接搭建和直传。采用一种新的信令模式：MiniSDP信令。这是一种基于二进制编码的压缩协议，为标准的SDP协议提供压缩处理；该方案可以减少信令交互时间，提高网络传输效率，减少直播首帧渲染时间，提高推流二次开启率/成功率等QoS统计指标。其工作原理是将原生SDP转换成更小的二进制格式（300bytes），通过一个UDP包（在MTU限制内）完成整个C/S交互。使用MiniSDP信令的媒体协商通信的信令交互过程如下图所示：MiniSDP压缩信令用于UDP网络传输；期望单个UDP包请求能够完成SDP完整压缩信息的传输。观察当前MiniSDP信令（UDP）信令上线后的后续QoS指标，发现信令关联建立成功率和首帧时间都有了很大的优化。3.2.3推流成功率优化通过在线AB实验，发现RTM推流成功率与FLV有一定差距。与流量成功率（UDP协议本身的特性）存在一定的正相关关系，即用户网络质量越高，成功率越高。拉流网络等级筛选，根据网络质量预估信息，综合评估用户的TCP/UDPRTT和数据下行吞吐率，得出用户的网络等级；选择网络质量好的用户使用RTM拉流，降低失败率。在线AB实验使用网络级漏斗进行网络筛选时，选择网络条件相对较好的用户开始实验（这部分用户占全网用户的绝大多数，其余用户使用默认的FLVlow-latency），原理是用户在拉流前综合权衡当前网络状况，当网络不适合RTM时，会通过策略转发回退到FLV，这样这些用户的体验就不会受到影响做作的。UDP节点检测拉流前，根据用户请求的URL所属的对应CDN边缘节点发起UDP检测；一段时间内发送数据包，观察对应CDN节点的数据RTT和丢包率，只有满足一定条件（比如RTT<80ms，丢包率<10%），才认为是UDP传输可以保证成帧的质量和成功率。在当前点播/直播间预加载信令，预加载下一个直播间的信令信息，提前做好SDP加载，减少下一个房间首帧画面时间。3.2.4StuckoptimizationkernelJitterBuffer禁用丢帧优化，不优化。经过AB实验，发现RTM视频卡顿明显增加，与预期不符。该团队在线分析了大量日志数据观察结果。目前的硬解具有核心用户体验指标的优势，但卡顿是FLV的近三倍。分析了网上大量的badcase，发现部分机型网络条件较好，但帧率极低，类似下表。:这类问题的比例在一些高热机型上也很高，但同机型在FLV播放中没有出现此类问题。通过对比FLV和RTM的播放控制策略，发现一个关键区别：传统的RTC场景优先保证时延，整个链路会触发各种丢帧（包括但不限于解码模块、网络模块)，而FLV直播场景会优先保证观看体验（不丢帧，音视频同步效果好）。如果RTM想要减少卡顿并获得QoE收益，则需要在不影响连麦场景下的逻辑的情况下定制广播控制策略。内部采用了全新的播控策略，上线后卡顿明显减少。RTC内核JitterBuffer平滑帧优化3.2.5广播控制逻辑优化RTM网络传输SDK抽象：改造内核，在引擎中复用网络传输-数据包-JitterBuffer/NetEQ模块；去除解码/渲染等模块；丢弃原始音频和视频数据以供播放器分离器集成。解码器复用：减少解码器的重新初始化时间，减少解码第一帧的延迟；多路复用解码器-渲染器的播放缓冲区速度控制逻辑。音视频同步优化：RTC音视频帧输出后，播放端根据FLV播放控制逻辑进行二次音视频同步处理；渲染校准根据音频主时钟进行，视频帧的渲染同步到音频时间线。3.2.6世界杯RTM优化世界杯超高清档位分辨率达到4K，这对RTM方案的性能带来了极大的挑战。一些在低分辨率下不存在的问题也在前期测试中被发现。当时时间非常紧迫，但在正式比赛之前，这些问题的修复已经完成，赶上了末班车。主要问题及解决方案如下：4K高清卡顿严重：优化NACK策略，保证更大的帧成功率。CPU/GPU内存：优化视频传输管道，减少不必要的原始数据格式转换。最终，性能和效果都通过了考验，RTM在世界杯期间顺利上线，承担了一定的流量，上线后稳定性和质量达到预期。3.3抖音与世界杯其他产品的平均延迟对比在实际世界杯中，抖音的延迟一直领先其他同信号源产品30s左右。甚至在最后两次直播中，其他产品都推出了比抖音快0~1s的快速追赶策略，但是追赶速度太快，持续了15s+以上，很明显，体验也比较差.这个攻略在抖音上也在上做了AB实验，播放时间显着为负，所以最后没有跟进。4.未来优化方向未来在高清、沉浸、互动直播场景，火山引擎视频云将不断完善已有的适用于不同场景的低时延方案，满足高码率和高时延的需求。低延迟。我们也将继续探索新的解决方案，在延迟、成本、卡顿等播放体验方面，为不同场景寻找最佳或最平衡的解决方案。在我看来，火山引擎视频云最大的优势就是可以把先进的技术放到海量用户的真实场景中进行在线培训。通过不断总结失败的教训和成功的经验，对用户体验产生积极的影响。更深入、更细致的理解。下面简单介绍一下火山机视频云在各种解决方案上持续发力的方向。4.1FLV追帧策略实现了更细粒度的追帧，实现了“按需追帧”，避免了不必要的追帧带来的负QoE。挖掘合适的传输框架，建立与边缘云端节点（发送方）交互的通道，实现云端拥塞控制算法，优化滞后，避免延迟增加。目前市场的平均时延已经有相当程度的降低，但是一小部分长尾用户的时延非常大，后期的优化方向会适当聚焦这些长尾用户，让更多的长尾用户可以享受到真正的低延迟，减少观看同一个直播的观众之间的延迟差异，满足一些基于流媒体内容的强交互玩法，比如跨年倒计时。FLV低延迟协议标准化：沉淀适用于不同直播场景（电商、赛事、游戏、演唱会等）、不同网络环境、一键部署的一揽子解决方案。4.2RTM在RTM方案中，火山引擎视频云还在不断探索优化点。以下几点是未来继续探索的几个方向：持续提升拉流成功率从SDK技术层面的共性差异来看，RTM协议中RTP包组的第一帧在成功率上存在短板，后续成功率优化需要从引擎的调优上继续探索。RTP扩展特性的不断迭代，缩小了首帧时间缩减与FLV的差距：RTM异步回源深度探索，目前只有一个CDN支持，需要扩展到其他CDN。进一步探索提高RTM推流成功率（针对用户网络差的场景）：检测ICE多模启动能力对成功率的提升，明确各CDN支持RTM启动TCP的能力/UDP和混合模式。RTM是一种全新的减少延迟的解决方案。为了将海量用户在业务中积累的经验教训反馈给整个行业，火山引擎视频云还与腾讯、阿里共同发起了RTM行业标准的制定。详情请参考https://www.volcengine.com/docs/6469/103014，未来该标准将扩展到更多的CDN，并在不断完善的同时，与业界一起向更低延迟方向演进。如果您对RTM方案感兴趣，可以点击阅读原文，进入火山引擎视频云官网了解详情和进一步试用。4.3切片协议时延优化国外的CDN基本上只支持HLS/Dash等切片协议，不支持FLV等“过时”的传输协议。但是由于HLS/Dash中切片的存在，并且为了保证视频的压缩率，切片一般都在秒级，需要切片完全生成后才能进行分发，并且至少必须生成两到三个切片才能分发。因此，与流式协议相比，在延迟方面自然存在一些劣势。事实上，这也是竞品的使用方式。如下图，每个分片为6s，三个分片生成后才能分发，带来了23s的延迟。世界杯期间，在相同视频源的情况下，其他产品的延迟明显高于抖音，因为采用了类似的HLS分片传输方案。但是随着Akamai和Apple分别引入CMAF和LL-HLS，以及引入fmp4和chunk的概念，可以在分片还没有完全生成的时候开始分发分片的一些chunk，并且较低延迟限制已大大降低。.如下图，延迟可以降低到1s。火山引擎视频云在苹果提出LL-HLS之前就跟进了CMAF，并持续在CMAF延迟、卡顿、推流成功率的优化上投入巨资。回顾CMAF的优化过程，我们可以发现要解决的问题与RTM非常相似。比如CMAF也存在推流成功率、音视频同步、性能等问题。优化前，核心体验指标也明显较差。在FLV上。与FLV流媒体不同的是，CMAF需要依赖用户对每个分片不断发起请求来获取音视频数据。如果继续使用FLV的请求方式，即建立连接->请求->响应->断开连接，会引入大量的连接建立耗时，造成卡顿，增加延迟。做个简单的计算，假设每个分片是2s，那么平均1s就会有一个音频或者视频请求连接建立，这对于网络不好的人来说是不能接受的，尤其是RTT高的用户，如果这个时候强行降低bufferwaterlevelforlowlatency，连接建立时的buffer消耗会导致频繁卡顿。为此，可以在CMAF上结合使用QUIC协议和连接复用。首先，QUIC协议的0-RTT连接建立允许客户端在服务器确认握手成功之前发送HTTP请求，连接复用直接省去了后续请求的连接建立操作，大大优化了连接建立时间和保持延迟的稳定性。但即便如此，每个分片请求都会引入1-RTT的延迟。未来我们会和服务端一起探索预请求模式，进一步压缩延迟，减少卡顿。CMAF优化整体难度较高，团队成员经常需要半夜与海外CDN工程师对接解决问题。不过，经过不断努力，近期一些领域已经取得了阶段性进展。在某些情况下，核心指标已与FLV保持一致。团队也有信心在不久的将来取消机型和网络类型的限制，让CMAF可以承载更多常规比例的流量。4.4XR直播时延优化XR直播的沉浸感和高交互性是普通直播无法比拟的，但这也给传输层带来了更大的压力：分辨率为8Kx4K或8Kx8K，源码流比特rate达到50M甚至120M，非常容易造成卡顿，拥塞增加延迟，甚至无法正常解码播放。火山引擎视频云的方法是将8K视频分成多个tile，只传输用户视口（viewport）中的部分超高清tile，只传输2K或4K分辨率的缩减背景流在其他地区。当用户切换视角时，重新请求新的超高清块。当然，有必要尽可能降低切换延迟。经过长时间的优化，切换延迟已经降到了很低的水平。一般情况下，已经感觉不到切换过程了。未来我们会继续优化，让切换延迟更低。两种方式都引入了优先级的概念，即数据在用户视角的优先级高于其他部分，低清晰度数据的优先级高于高清数据。基于这一特性，火山引擎视频云将探索基于UDP的内容优先级感知传输方案，优先传输高质量数据，而对低质量数据选择不可靠传输。即使丢失，也无需重传，保证了XR直播的低延迟，不会引入过多的视觉失真。优化后，在传输8Kx8K/8Kx4K超高清视频时，对播放端的码率要求从120M/50M降低到20M/10M左右甚至更低，大大降低了卡顿的概率用户端，从而也减少了延迟增加的概率。未来，火山引擎视频云将在更高码率、更高分辨率下持续优化XR直播的卡顿和延迟，为用户提供更沉浸的观看体验。
