这种问题在部分高热机型上的比例也是很高的，但同样的机型，FLV 播放并无这样的问题，通过对比 FLV 和 RTM 的播控策略，发现了一个关键不同点——传统的 RTC 场景优先保时延，全链路会触发各种丢帧（包括但不限于解码模块，网络模块），FLV 直播场景会优先保证观播体验（不丢帧，良好的音画同步效果）。RTM 要想减少卡顿，取得 QoE 的收益，播控策略需进行定制化，不影响连麦场景下的逻辑，内部采用新的播控策略，最后上线后卡顿显著减少。
RTC 内核 JitterBuffer 平滑出帧优化
RTM 网络传输 SDK 的抽象：将内核进行改造，复用引擎中的网络传输-组包-JitterBuffer/NetEQ 模块；去掉解码/渲染等模块；将音视频的裸数据抛出供播放器 demuxer 集成。
解码器复用：降低解码器重新初始化的时间，降低解码首帧延时；复用解码器-渲染器的播放缓冲区控速逻辑。
音画同步的优化：RTC 音视频出帧之后在播放器侧按照 FLV 的播控逻辑进行二次音画同步处理；按照 audio master clock 主时钟进行渲染校准，视频帧渲染同步到音频时间轴上。
6、RTM 针对世界杯的优化本次世界杯超高清档位的分辨率达到了 4K，对 RTM 方案的性能带来了很大的挑战，在前期测试时也发现了一些低分辨率没有的问题。当时时间非常紧，不过在正式比赛之前，还是完成了这些问题的修复，赶上了最后一班车。主要的问题和解决方案如下：
- 4K 高清档位卡顿严重卡顿: 优化 NACK 策略，保证更大的帧的组帧成功率。
- CPU/GPU 内存: 优化 video 传输 pipeline，减少不必要的 raw 数据格式转换。
最终在性能和效果都通过了测试，RTM 在世界杯期间也顺利上线，承担了一定的流量，上线后稳定性和质量都符合预期。
（三）世界杯中抖音和其它产品平均的延迟对比在实际的世界杯比赛中，抖音的延迟一直领先于相同信号源的其它产品 30s 左右。即使最后两场其它产品在个别直播间上了快速追赶策略比抖音快 0~1s，但追的速度过快且持续时间超过 15s ，有明显感知，体验相对较差，这种策略在抖音上也曾经做过 AB 实验 ，播放时长是显著负向的，所以最后并没有跟进。
四、未来的优化方向未来在高清、沉浸、互动的直播场景中，针对高码率、低延迟的需求，火山引擎视频云会继续打磨现有的适合不同场景的各种低延迟的方案，同时也会不断地探索新的方案，在延迟、成本、卡顿和其它播放体验上找到适合不同场景的最佳或者最平衡的方案。
在我看来，火山引擎视频云的最大的优势，在于可以把先进的技术放到真实的海量用户的场景去做线上训练，通过不断地总结失败的教训和成功的经验，对用户体验有更深更细微的理解。下面简单介绍一下火山引擎视频云在各个方案上继续努力的方向。
（一）FLV- 追帧策略实现更细粒度的追帧，做到“按需追帧”，避免不必要的追帧，引起 QoE 的负向。
- 挖掘合适的传输框架，建立与边缘云节点(发送端)交互的通道，实现云端联动的拥塞控制算法，优化卡顿，避免延迟增加。
- 目前大盘的平均延迟已经有了相当程度的降低，但有一小部分长尾用户的延迟是很大的，后期的优化方向也会适当地侧重到这部分长尾用户，让更多的长尾用户能享受到真正的低延迟，降低观看同一直播流的观众间延迟差，满足基于流内容的一些强互动玩法，比如倒计时跨年。
- FLV 低延迟协议标准化：沉淀适用不同直播场景(电商、赛事、游戏、演唱会等)、不同网络环境、可一键部署的套餐方案。
在 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，不断完善的同时，和业界一起向更低延迟演进。
（三）切片类协议的延迟优化海外的 CDN 基本都只支持切片式的协议如 HLS/Dash 等，不支持 FLV 这类“过时”的传输协议。但 HLS/Dash 因为切片的存在，而且为了保证视频的压缩率，切片一般都是秒级的，且需要切片完全生成才能分发该分片，并且需要至少两三个分片都生成完才能分发，所以和流式的协议相比，延迟上天然有一些劣势。其实这也是竞品使用的方式，如下图，每个分片 6s，在三个分片生成完后才可以分发，带来了 23s 的延迟。世界杯期间，在视频同源的情况下，其它产品的延迟显著高于 抖音 ，就是因为使用了类似的 HLS 的切片传输方案。
但随着 Akamai 和 Apple 分别提出了 CMAF 和 LL-HLS，引入了 fmp4 和 chunk 的概念，可以实现分片没有完全生成的时候就开始分发分片的部分 chunk，延迟下限有了很大程度的下降。如下图，延迟可以降到 1s。
火山引擎视频云在 Apple 提出 LL-HLS 之前就跟进了 CMAF，在 CMAF 的延迟和卡顿、拉流成功率上的优化上也持续有不小的投入。现在回顾 CMAF 的优化的过程，可以发现其实要解决的问题和 RTM 有很大的相似性，比如 CMAF 也存在拉流成功率、音画同步、性能问题，优化前在核心 体验指标 上同样显著差于 FLV。
与 FLV 的流式传输不同，CMAF 需要依赖用户不断发起各个分片的请求来获取音视频数据，如果继续采用 FLV 的请求模式，即建连->请求->响应->断开连接，会引入大量的建连耗时，造成卡顿，同时导致延迟的增大。做一个简单的计算，假设每个切片是 2s，那么平均 1s 就会有一次音频或视频请求的建连，这对于网络较差，尤其是高 RTT 的用户来说是不可接受的，如果此时为了低延迟强行降低 buffer 水位，建连时的缓存消耗将导致频繁的卡顿。
为此，可以在 CMAF 上采用 QUIC 协议与连接复用结合的方式，首先 QUIC 协议的 0-RTT 建连允许客户端在服务端确认握手成功之前就发出 HTTP 请求，而连接复用直接省去了后续请求的建连操作，大幅优化了建连耗时，维持延迟的稳定。但即使如此，每个分片的请求也会引入 1-RTT 的延迟，未来将与服务端一起探索预请求模式，进一步压缩延迟、降低卡顿。
