雨燕直播,NBA直播,世界杯直播,足球直播,台球直播,体育直播,世界杯,欧洲杯,苏超直播,村BA直播,苏超联赛,村超,村超直播

　　本文主要讨论生产和传输环节的延迟。生产环节的延迟主要受视频流供应商控制，技术团队可以实现的是，尽可能准确地测量出生产的每一个环节的实际延迟，并在发现不合理的情况时推动供应商解决。传输环节的延迟技术团队更可控，也是本次优化的重点。这部分技术能力可以作为火山引擎视频云的优势能力积累并对外提供服务。在优化的过程中，一个越来越清晰的认知是：降低延迟并不困难，难的是延迟降低之后，怎么通过优化保证播放体验不下降甚至变得更好。

　　直播的传输环节里，对延迟影响大的主要是转码、分发和播放缓冲，使用实时的转码模式，转码器引入的延迟一般在 300ms 以内甚至更短。CDN 的分发环节也会带来一定的延迟，但相对也较短。为了对抗网络抖动引入的播放缓冲区引入的延迟播放缓冲引入的延迟常常会有 5s 甚至更多，所以本文主要讨论怎么在减少播放缓冲的情况下，通过不断地优化延迟降低的同时不影响整体的播放体验(不仅仅是卡顿)。在调优过程中，大家对播放体验也有了更细致、更深的理解，逐渐弄清楚了哪些 QoS 指标可以对关键的 QoE 指标产生直接的影响，对以后要优化的方向也更明确了。

　　之前详细介绍过 FLV-3s 方案在抖音落地的详细实践过程(细节内容可跳转到基于 http-FLV 的抖音直播端到端延迟优化实践），同时提出过基于 FLV 方案做更低延迟下探，所面临的挑战也会更大：更低延迟的场景对直播全链路的传输稳定性要求苛刻程度会几何倍数增加，由于端到端链路的整体 buffer 更低，生产环节或者观众网络抖动，就更容易发生卡顿。只要发生一次卡顿，延迟就会秒级增加，最终累积延迟会越来越大。而世界杯赛事延迟要求达到 2s，继续延续 FLV-3s 方案显然达不到要求，需要配合精细的追帧或者丢帧策略。

　　RTM 的方案参考了 WebRTC，可以让端到端延迟直接进入 1s 以内，已经持续在抖音上打磨了一年多，整体来说遇到的困难很大，在推进的过程也不断地发现了新的问题，也逐渐认识到，直接把RTC在视频会议上的方案应用到直播播放场景的效果并不好，需要做大量的改造才能让直播的体验得到抖音用户的认可。同时评测的同学也持续对行业内已经上线的类似方案进行了跟踪和测试，经过线上测试后，也发现现有多方案也存在很多问题, 所以一直也没有停止自研。RTM 优化的目标是在延迟降低的情况下，用户核心体验指标对齐或者优于大盘的 FLV 方案。但是由于 FLV 低延迟方案的持续优化并拿到结果，一定程度上RTM 的优化目标的bar是在不断提高的。

　　每次迭代都要经过分析数据-找到问题点-提出优化方案-完成开发和测试-AB 实验-分析数据的反复循环，每一次循环的都需要至少一个版本甚至多个版本的周期，所以项目整体耗时较长。关于如何提升实验的效率，也做了很多思考和探索。最后通过多次的实验和反复的问题解决，在核心用户体验指标基本对齐了 FLV,所以在世界杯的多场比赛中，RTM 方案也承担了一定量级的 CDN 容量，核心键指标上都对齐了大盘，稳定性和质量得到了充分的验证。

　　但是 HTTP SDP 信令交互存在如下方案的弊端：弱网环境下(如 RTT 较大/网络信号不稳定)，HTTP 信令建联成功率不理想；导致播放请求响应缓慢或超时（基于信令数据包庞大且发生 TCP 重传导致信令响应速度不理想）；另一方面 SDP 交互传输 SDP 文本的内容很大（通常 3KB~10KB）建联的成本较高导致初始化的成本无法忍受；对比 FLV 的 HTTP 请求完成后直接完成建联和媒体数据直接传输，可以采用新的信令模式：MiniSDP 信令。这是一种基于二进制编码的压缩协议，提供对标准 SDP 协议进行压缩处理；这种方案可以降低信令交互时间，提高网络传输效能，降低直播拉流首帧渲染时间，提高拉流秒开率/成功率等 QoS 统计指标。其作用原理是将原生 SDP 转换成更小的二进制格式（300bytes）通过一个 UDP 包（MTU 限制之内）完成整个 C/S 交互。

　　海外的 CDN 基本都只支持切片式的协议如 HLS/Dash 等，不支持 FLV 这类“过时”的传输协议。但 HLS/Dash 因为切片的存在，而且为了保证视频的压缩率，切片一般都是秒级的，且需要切片完全生成才能分发该分片，并且需要至少两三个分片都生成完才能分发，所以和流式的协议相比，延迟上天然有一些劣势。其实这也是竞品使用的方式，如下图，每个分片 6s，在三个分片生成完后才可以分发，带来了 23s 的延迟。世界杯期间，在视频同源的情况下，其它产品的延迟显著高于抖音，就是因为使用了类似的 HLS 的切片传输方案。

　　与 FLV 的流式传输不同，CMAF 需要依赖用户不断发起各个分片的请求来获取音视频数据，如果继续采用 FLV 的请求模式，即建连-请求-响应-断开连接，会引入大量的建连耗时，造成卡顿，同时导致延迟的增大。做一个简单的计算，假设每个切片是 2s，那么平均 1s 就会有一次音频或视频请求的建连，这对于网络较差，尤其是高 RTT 的用户来说是不可接受的，如果此时为了低延迟强行降低 buffer 水位，建连时的缓存消耗将导致频繁的卡顿。

　　XR 直播的沉浸感以及高交互性是普通直播无法比拟的，但是这也导致了传输层需要承担更大的压力：分辨率为 8K x 4K 或 8K x 8K, 源流码率达到 50M 甚至120M、非常容易因为拥塞导致卡顿、延迟增大，甚至无法正常解码播放。火山引擎视频云的做法是将 8K 的视频切分成多个块(tile)，只传输用户视角(viewport)内的部分超高清块，其它区域只传输 2K 或 4K 分辨率的缩小后的背景流，在用户切换视角的时候再去重新请求新的超高清块。当然这里需要把切换延迟尽可能降到更低，经过长时间的优化，切换延迟已经降低到非常低，一般情况下已经感受不到切换的过程，未来会持续优化，让切换延迟更低。

　　这两种做法都引入了优先级的概念，即用户视角内的数据优先级高于其他部分，低清数据优先级高于高清数据。基于这种特性，火山引擎视频云将探索基于 UDP 的内容优先级感知的传输方案，优先保障高优数据的传输，对于低优数据可选择非可靠传输，即使丢失也无需重传，保证 XR 直播低延迟的同时不引入过大的视觉失真。经过优化后，在传输 8K x 8K/8K x 4K 的超高清视频时对播放端的码率要求从 120M/50M 降低到 20M/10M 左右甚至更低，在用户侧极大地减少了卡顿发生的概率，从而也减少了延迟增大的概率。未来火山引擎视频云也会持续优化 XR 直播下在更高码率更高分辨率下的卡顿和延迟，为用户提供更沉浸的观看体验。