抖音上调优总结收益总结调优经验总结
先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
如果你需要这些资料，可以添加V获取：vip1024b （备注go）
正文
音视频数据流转时序
数据驱动 QoE & QoS 优化
综上，需要一套精细的播控策略兼顾延迟与 QoE 指标的平衡。
输出：目标播放速度。
原理：
3.1.2 FLV 2s 低延迟方案在抖音上调优总结
收益总结
调优经验总结
3.2 RTM 方案
RTM 的方案参考了 WebRTC，可以让端到端延迟直接进入 1s 以内，已经持续在抖音上打磨了一年多，整体来说遇到的困难很大，在推进的过程也不断地发现了新的问题，也逐渐认识到，直接把RTC在视频会议上的方案应用到直播播放场景的效果并不好，需要做大量的改造才能让直播的体验得到抖音用户的认可。同时评测的同学也持续对行业内已经上线的类似方案进行了跟踪和测试，经过线上测试后，也发现现有多方案也存在很多问题, 所以一直也没有停止自研。RTM 优化的目标是在延迟降低的情况下，用户核心体验指标对齐或者优于大盘的 FLV 方案。但是由于 FLV 低延迟方案的持续优化并拿到结果，一定程度上RTM 的优化目标的bar是在不断提高的。
每次迭代都要经过分析数据->找到问题点->提出优化方案->完成开发和测试->AB 实验->分析数据的反复循环，每一次循环的都需要至少一个版本甚至多个版本的周期，所以项目整体耗时较长。关于如何提升实验的效率，也做了很多思考和探索。最后通过多次的实验和反复的问题解决，在核心用户体验指标基本对齐了 FLV,所以在世界杯的多场比赛中，RTM 方案也承担了一定量级的 CDN 容量，核心键指标上都对齐了大盘，稳定性和质量得到了充分的验证。
3.2.1RTM方案优化概述
项目启动后，将 RTC 实时通信 SDK 直接集成进入播放器后首先进行线上 AB 测试，初期的实验效果显得大跌眼镜：除了端到端延迟指标符合预期以外无论是拉流成功率，首屏秒开时间，卡顿等指标均与FLV差距很大；所以 RTC 技术方案要顺利部署到直播场景，还需要配合直播播控策略进一步优化。
为了让 RTM 的综合指标对齐 FLV，从若干角度来进行 RTM 的播控逻辑定制化，所有的优化围绕着核心用户体验指标进行展开：
3.2.2 首帧时间的优化
传统的 RTC 技术采用 SDP 信令方式进行媒体能力协商，SDP 信令通过如下图方式进行交互参见下图：
但是 HTTP SDP 信令交互存在如下方案的弊端：弱网环境下(如 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 协议本身特性），即用户网络质量越高成功率越高。
拉流网络等级筛选
UDP节点探测
信令预加载
3.2.4 卡顿的优化
内核 JitterBuffer 禁用丢帧优化
RTC内核 JitterBuffer 平滑出帧优化
3.2.5 播控逻辑的优化
RTM 网络传输 SDK 的抽象：将内核进行改造，复用引擎中的网络传输-组包-JitterBuffer/NetEQ 模块；去掉解码/渲染等模块；将音视频的裸数据抛出供播放器 demuxer 集成。
解码器复用：降低解码器重新初始化的时间，降低解码首帧延时；复用解码器-渲染器的播放缓冲区控速逻辑。
音画同步的优化：RTC 音视频出帧之后在播放器侧按照 FLV 的播控逻辑进行二次音画同步处理；按照 audio master clock 主时钟进行渲染校准，视频帧渲染同步到音频时间轴上。
3.2.6 RTM 针对世界杯的优化
本次世界杯超高清档位的分辨率达到了 4K，对 RTM 方案的性能带来了很大的挑战，在前期测试时也发现了一些低分辨率没有的问题。当时时间非常紧，不过在正式比赛之前，还是完成了这些问题的修复，赶上了最后一班车。主要的问题和解决方案如下：
最终在性能和效果都通过了测试，RTM 在世界杯期间也顺利上线，承担了一定的流量，上线后稳定性和质量都符合预期。
3.3 世界杯中抖音和其它产品平均的延迟对比
在实际的世界杯比赛中，抖音****的延迟一直领先于相同信号源的其它产品 30s 左右。即使最后两场其它产品在个别直播间上了快速追赶策略比抖音快 0~1s，但追的速度过快且持续时间超过 15s+，有明显感知，体验相对较差，这种策略在抖音上也曾经做过AB 实验，播放时长是显著负向的，所以最后并没有跟进。
4. 未来的优化方向
未来在高清、沉浸、互动的直播场景中，针对高码率、低延迟的需求，火山引擎视频云会继续打磨现有的适合不同场景的各种低延迟的方案，同时也会不断地探索新的方案，在延迟、成本、卡顿和其它播放体验上找到适合不同场景的最佳或者最平衡的方案。
在我看来，火山引擎视频云的最大的优势，在于可以把先进的技术放到真实的海量用户的场景去做线上训练，通过不断地总结失败的教训和成功的经验，对用户体验有更深更细微的理解。下面简单介绍一下火山引擎视频云在各个方案上继续努力的方向。
4.1 FLV 4.2 RTM
在 RTM 方案上，火山引擎视频云还在不断地发掘优化点。以下几点是未来会继续探索的几个方向：
拉流成功率的持续改进
RTP扩展特性的持续迭代
RTM 是降低延迟的一种全新方案，为了把在海量用户的业务上积累的经验和教训反馈给整个业界，火山引擎视频云也联合腾讯和阿里发起了 RTM 行业标准的制订，具体可以参考 ，未来也会把标准推广到更多的 CDN，不断完善的同时，和业界一起向更低延迟演进。对 RTM 方案感兴趣的，可以点击阅读原文，进入火山引擎视频云官网了解细节和进一步试用。
4.3 切片类协议的延迟优化
海外的 CDN 基本都只支持切片式的协议如 HLS/Dash 等，不支持 FLV 这类“过时”的传输协议。但 HLS/Dash 因为切片的存在，而且为了保证视频的压缩率，切片一般都是秒级的，且需要切片完全生成才能分发该分片，并且需要至少两三个分片都生成完才能分发，所以和流式的协议相比，延迟上天然有一些劣势。其实这也是竞品使用的方式，如下图，每个分片 6s，在三个分片生成完后才可以分发，带来了 23s 的延迟。世界杯期间，在视频同源的情况下，其它产品的延迟显著高于抖音，就是因为使用了类似的 HLS 的切片传输方案。
但随着 Akamai 和 Apple 分别提出了 CMAF 和 LL-HLS，引入了 fmp4 和 chunk 的概念，可以实现分片没有完全生成的时候就开始分发分片的部分 chunk，延迟下限有了很大程度的下降。如下图，延迟可以降到 1s。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
3.png)
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）
[外链图片转存中…(img-2lEKJ76r-77)]
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
