身临其境：沉浸互动——大型赛事直播与互动实践指南

大型赛事直播与互动实战指南 目录 抖音大型赛事直播的低延迟是怎么做到的？第一章:突破极限03 多项黑科技引领VR直播新体验 抖音视频编码器优化第二章:高清流畅25 从多人同看到智能陪看第六章:新奇互动57 第七章:AI 创新场景探索3373 本指南精选火山引擎视频云支撑抖音在世界杯、亚运会等大型赛事直播中的关键技术实践，围绕低时延直播、视频编码、画质优化、弹性分发、沉浸体验与互动创新等方向，呈现面向世界杯周期的能力升级路径，帮助客户在更高清、更稳定、更智能、更具参与感的观赛体验中获得新的增长空间。 2026 年世界杯来临，大型赛事直播正在进入新的竞争阶段。对于平台、媒体、品牌与内容运营伙伴而言，赛事已经不再只是一次流量洪峰承接，而是一场围绕全球分发、低时延体验、高清画质、内容生产效率与互动创新的综合能力比拼。 面对世界杯这样覆盖多国家、多时区、长周期运行的全球顶级赛事，大家关注的重点也从“能否承接超大并发”进一步延伸到“能否更低时延、更高清、更稳定、更智能地放大赛事内容价值”。 火山引擎基于支撑抖音在 2022 世界杯、2024 亚运会等大型赛事直播中的实践积累，以及海量业务场景中沉淀的技术能力，整理了一套更适合 2026 世界杯场景的实战参考，帮助客户更高效地完成直播承接、内容生产、互动体验与全球化运营准备。 作为支撑抖音 2022 世界杯、2024 亚运会等大型赛事直播的主要技术服务方，火山引擎也在持续推动视频云能力从“赛事保障”走向“赛事增长”，为客户提供更具可复制性和可运营性的产品化支撑。 抖音大型赛事直播的低延迟是怎么做到的？ （二）全链路延迟测量以及方法 - 抖音大型赛事直播的低延迟是怎么做到的？ 测算方法 -拍照： ·视频画面上有时钟展示的 ( 比如画面左上角或者右上角的北京时间或者比赛持续时间，一般精确到秒 )，可以通过同时拍照两个播放画面的方式，记录同一时刻两个画面，然后通过照片中的时钟做差来计算。 在世界杯、亚运会等大型赛事直播实践中，火山引擎视频云携手抖音持续验证了 4K 超高清、超低延迟看播能力在海量并发场景下的可行性。对于大型赛事而言，如何在超大规模并发、复杂网络条件与多终端差异下，稳定流畅地做到更低的延迟，是一个巨大的挑战。本章节主要介绍火山引擎视频云和相关团队在大型赛事低延迟方向上的关键工作和优化，并结合抖音在世界杯、亚运会等场景中的实践进行总结。 -手动秒表计算： ·如果视频画面中无时钟相关内容，那么可以从延迟低的视频画面中选取具有标志性易识别的帧启动秒表，然后观察延迟高的画面出现同样的帧画面时，停止秒表，记录秒表结果为延迟对比结果。 -仅适用演播室推流到抖音播放链路 背景信息 下文以抖音卡塔尔世界杯整个分发链路，以及每个环节的延迟测量方法为例，让大家对整体链路有初步的全局认识。 （一）抖音卡塔尔世界杯信号分发链路 - 计算方法：端到端延迟 = 观众当前系统时间戳 - SEI 中的时间戳，单位 ms。 - 统计频度：每 2s 计算一次，每 10s 上报一次当前计算结果。 - 每个 I 帧前会有一个 SEI，流规格设置为 I 帧间隔为 2s，因此每 2s 演播室推流侧会生成一个SEI 帧。 - 前置要求：演播室推流前进行 NTP 本地时钟校准。 在演播室制作阶段，必须在“极致低延迟”与“广播级高可用”之间做出审慎的技术平衡。综合考量赛事转播的绝对安全性，我们将该环节的延迟基准控制在 1.5 秒左右。这一设定旨在为系统预留充分的容错缓冲空间以确保稳定，该标准也与业内顶级赛事的最高制作规格保持一致。 传输环节的低延迟 下图是一次直播的简化的流程： 延迟如何产生 生产环节的低延迟 （一）信号源 直播信号源在给到抖音之前，需经过多个上游采集与传输环节。这些前置环节客观上会产生一定的链路耗时。 （二）演播室制作环节 演播室在接收到央视源流之后，需进行解说音轨叠加、视觉包装等二次制作，此过程会引入一定的计算延迟。在世界杯等超大型赛事转播中，通常需要协同多家第三方演播室供应商。面对制作规格不一的挑战，我们在实战中建立了一套严格的技术协同规范，确保核心演播室的技术链路、制作标准与编码系统达成高度一致。 在直播传输链路中，转码、分发与端侧播放缓冲是决定端到端延迟的核心环节。依托高性能实时转码架构，转码侧的耗时通常可被极度压缩至 300ms 甚至更低；同时，CDN 边缘分发网络所产生的物理传输延迟也相对可控。然而，真正导致高延迟的瓶颈在于端侧——为对抗复杂弱网环境下的网络抖动，传统播放器往往需设定长达 5 秒甚至更高的抗抖动缓冲区。 因此，大型赛事低时延优化的核心技术命题在于：如何在大幅压缩端侧播放缓冲区的同时，通过系统级调优，确保整体播放体验（涵盖但不限于卡顿率、画质、首屏耗时）不发生任何妥协降级。通过历次超大型赛事的实战打磨，我们构建了更精细化的体验评估体系，精准映射了底层网络 QoS（服务质量）对终端 QoE（用户体验质量）的直接驱动关系。这套科学的量化模型，为在极限低时延场景下持续突破体验天花板确立了清晰的技术演进方向。 数据驱动 QoE & QoS 优化 由于进一步下探延迟，卡顿也会随之恶化，反而延迟逐渐累积增加达不到低延迟的效果，因此延迟下探必须配合延迟追赶播控策略来确保延迟增大后可及时追赶恢复到低延迟。是否只要在延迟增加后立即倍速追赶就能满足业务的需求呢？对于延迟 QoS 指标来说的确是，但对于用户主观体验的 QoE 指标，这样的策略反而可能是负向的。 低延时直播方案 结合历史 AB 实验以及 DA 详细数据分析，有以下几点倍速追赶与 QoE 指标之间的关联现象： · 倍速追赶带来的播放速度变化本身就是负面的体验· 倍速时长超过 2 秒，用户即可有感知且负向反馈· 倍速速度越大，播放速度前后变化 diff 越大，负向越严重· 倍速与正常速度的切换过于频繁，会带来负向反馈 （一）FLV 方案 FLV 是现在国内主流直播播放使用的协议，火山引擎视频云对低延迟直播的探索也是从 FLV 开始的。基于 FLV 方案做更低延迟下探，所面临的挑战很大：更低延迟的场景对直播全链路的传输稳定性要求苛刻程度会几何倍数增加，由于端到端链路的整体 buffer 更低，生产环节或者观众网络抖动，就更容易发生卡顿。只要发生一次卡顿，延迟就会秒级增加，最终累积延迟会越来越大。而世界杯赛事延迟要求达到 2s，继续延续 FLV-3s 方案显然达不到要求，需要配合精细的追帧或者丢帧策略。 综上，需要一套精细的播控策略兼顾延迟与 QoE 指标的平衡。详细方案设计如下： -输入： ·播放器当前 Buffer 时长、历史 Ns 内 buffer 抖动方差、历史 Ns 内卡顿信息以及追帧参数配置。 1、基于 buffer & 卡顿信息的双阈值延迟追赶策略 · 策略可配置参数以及含义映射： 音视频数据流转时序 在展开描述延迟追赶策略方案细节前，先简单介绍播放器音视频数据流转时序：网络 IO 下载音视频数据到播放器缓存 buffer-> 解码器从 buffer 中取数据解码并降解码后的数据存入待播放缓存 -> 音画同步等播控策略 -> 渲染播放音视频帧。 -输出：目标播放速度。 1、RTM 方案优化概述 -原理： 在 RTM 方案早期的线上 A/B 测试中，数据客观揭示了一个行业共性痛点：直接集成原生 RTCSDK 虽然能达成预期的低延迟，但在拉流成功率、首屏秒开及卡顿等直播核心体验指标上，仍显著落后于高度成熟的 FLV 方案。 ·基于 buffer 抖动方差 & 历史卡顿信息，来定性衡量网络质量，判断是否可以追赶，只有在网络质量良好时才能触发追赶逻辑避免卡顿。 ·追帧采用双阈值，并且支持可配置，可以控制追帧持续时长不超过 2s，同时也可以保证不频繁变速。 这一技术落差明确了 RTC 技术向高并发直播场景平滑迁移的必经之路。为确保 RTM 方案在综合指标上严格对齐 FLV 大盘，我们以核心用户体验为绝对导向，从以下多个维度对 RTM 的播控逻辑展开了深度定制化改造： · 追帧速度可配置，保证倍速变化不超过一定辐度。 2、FLV 2s 低延迟方案在抖音上调优总结 ·DNS 节点优选、SDK 信令预加载、UDP 连通性预探测主要解决的拉流成功率相关问题。·SDP 信令相关优化主要解决信令时间消耗的问题 ( 首帧时间 ) 与成功率问题。·RTC 内核播控定制化主要解决播放的卡顿问题。·播放器播控逻辑结合解决的音画同步与渲染策略的问题。 - 无论播放过程中丢帧方式追赶延迟，还是卡顿后立即丢帧追赶延迟，只要是丢帧，QoE 都是负向。 - iOS 端对倍速负向没有 Android 敏感，对倍速容忍度高。 - 精细化倍速追帧策略可以满足 FLV-2s 的延迟需求，但再进一步下探延迟，就需要同时配合卡顿优化方案从源头避免延迟增加。 （二） RTM 方案 RTM 方案参考了 WebRTC 技术架构，旨在将端到端直播延迟压缩至 1 秒以内。在技术落地初期，我们发现直接将 RTC 方案应用于赛事直播场景，难以满足抖音等海量用户对极致播放体验的要求；同时，业内现有类似方案在实测中亦暴露出多项短板。为此，我们确立了深度自研与底层改造的技术路线。RTM 方案的核心攻坚目标在于：在实现亚秒级低延迟的同时，确保各项核心用户体验指标能够对齐甚至超越持续进化的 FLV 大盘方案。 为 达 成 这 一 高 标 准，建 立 了“数 据 分 析 -> 瓶 颈 定 位 -> 策 略 优 化 -> 开 发 测 试 -> A/B 实 验”的严密闭环迭代机制，并持续提升实验验证效率。经过技术攻坚，RTM 方案的核心体验指标最终成功对齐 FLV。在世界杯等多场重大赛事的直播中，该方案成功承载了规模庞大的 CDN分发流量，各项核心指标表现优异，其在极高并发场景下的稳定性与服务质量得到了充分的实战验证。 2、首帧时间的优化 - 单 UDP 包极速交互： ·压缩后的信令体积被严格控制在标准网络 MTU 限制之内，使得客户端与服务端（C/S）只需通过单个 UDP 数据包，即可一次性完成完整的媒体协商信息的可靠传输。 传统的 RTC 技术采用 SDP 信令方式进行媒体能力协商，SDP 信令通过如下图方式进行交互。参见下图： - 核心体验指标跃升： ·这种极简交互模式大幅缩减了信令交互与传输耗时。在线上实战中，它显著降低了直播拉流的首帧渲染时间，全面提升了拉流成功率、秒开率等核心 QoS 指标。采用 MiniSDP 进行媒体协商的信令交互流程如下图所示： HTTP SDP 信令交互在复杂网络环境下存在显著的技术瓶颈。一方面，在弱网场景（如高 RTT或网络波动）下，HTTP 信令建联成功率易受波动影响，一旦发生 TCP 重传，将直接导致播放请求响应迟缓甚至超时；另一方面，标准 SDP 文本体积较大（通常为 3KB~10KB），这导致初始化成本会令人无法忍受。 相较于 FLV 方案在 HTTP 请求后即可直接下发媒体数据的轻量体验，基于 RTC 架构的直播亟需更高效的握手方式。为此，我们全面引入了MiniSDP 信令模式来重构建联流程： - 极致的二进制压缩封装： ·MiniSDP 是一种基于二进制编码的深度压缩协议，可将冗长的原生 SDP 文本压缩转换为极小的二进制格式（体积缩减至 300 Bytes 左右）。 当前 MiniSDP 信令（UDP）信令上线后观察后续的 QoS 指标发现，信令建联的成功率和首帧时间得到了大幅度的优化。 4、卡顿的优化 内核 JitterBuffer 禁用丢帧优化 3、拉流成功率的优化 未调优时候经过 AB 实验发现，RTM 的视频卡顿大幅度上涨，跟预期不匹配，对此团队分析了线上的大量日志数据观察。当前的硬解具有核心用户体验指标的收益，但卡顿是 FLV 的将近 3倍 , 分析了大量线上 badcase，