受学术界最新研究方向 Pensieve[1] 的启发，我们和北京邮电大学合作，定制淘宝直播基于强化学习的拥塞控制算法，自研与传统拥塞控制算法相结合的策略，在平稳网络中，保持带宽利用率不降的情况下，可以降低 20% 的延迟，以及约 25% 的卡顿。
淘宝直播对于该方向的研究成果，已经受到学术界认可，连续两年在网络方向顶级会议 MobiCom 上发表论文(Concerto[2], OnRL[3])。
[1]. Hongzi Mao,Ravi Netravali, and Mohammad Alizadeh. 2017. Neural Adaptive Video Streaming with Pensieve. In Proceedings of the Conference of the ACM Special Interest Group on Data Communication, SIGCOMM 2017, LosAngeles, CA, USA, August 21-25, 2017. 197–210.
[2]. Zhou, Anfu, et al. “Learning to coordinate video codec with transport protocol for mobile video telephony.” The 25th Annual International Conference on Mobile Computing and Networking. 2019.
[3]. Zhang, Huanhuan, et al. “OnRL: improving mobile video telephony via online reinforcement learning.” Proceedings of the 26th Annual International Conference on Mobile Computing and Networking. 2020.
适合直播的网络传输策略
拥塞控制算法主要反馈网络拥塞情况，并不能直接缓解网络拥塞。要缓解网络拥塞，必须配合网络传输策略，包括大小流切换、SVC、丢GOP、平滑发送、FEC、ARQ/NACK等。
拥塞控制算法从webrtc完整模块化剥离和重构，性能是webrtc原来实现的2倍以上，针对直播场景深度优化，同时兼顾秒开和延迟，支持GCC和BBR算法，追求最大吞吐率。在网络小范围抖动情况下不受影响，最大支持20%丢包和500ms内的抖动。和通信场景追求极低延迟和流畅性的方式还不一样，直播场景追求高画质，保证用户的观看体验。整个算法通过线上播放数据AB做反馈，系统不断优化迭代。
▐ 零转码的码率自适应系统
目前业界大多数直播系统，当用户网络较差时，用户可以切换更低的清晰度来保障播放流畅。
低清晰度的直播流需要云转码生成。云转码需要解码后编码，编解码是非常消耗计算资源的，因此会带来大量的转码成本。
通信技术里不需要转码，拥塞控制算法发现带宽拥塞时，会自动调整发送码率来缓解拥塞。然而这种拥塞控制算法，在直播系统里并不适用，因为部分用户网络差，会将所有观看者的质量拉低。所以直播系统的码控不能直接调整主播编码码率。需要分开来看，如果主播上行网络拥塞，确实需要调整主播编码码率，如果是部分观众下行网络拥塞，则不能调整主播编码码率，而是在CDN边缘上实现丢弃一些不重要的信息，来实现有损降码率。降码率的策略包括：SVC、丢GOP、大小流等。
SVC是一种可以丢掉部分视频内容，虽然降低一点观看质量，但能保证内容可看的一种技术，适应于相对静态的场景。这种场景下，由于动作不大，几乎看不出来，比如直播带货等。
**SVC又分两种，空域SVC和时域SVC。**空域SVC是指，丢掉一部分视频内容，帧率不变，但每一帧视频清晰度降低的技术。时域SVC是指，丢掉一部分视频内容，帧率下降，但每一帧清晰度跟原帧的清晰度几乎不变的技术。简而言之，时域SVC是保证清晰度损失流畅度，空域SVC是保证流畅度损失清晰度。目前行业大部分空域SVC的编码算法，压缩率都会下降，甚至效果不如同时编大小流，因此使用得较少。
平坦结构
行业上常用的结构是X265的单层金字塔结构。
金字塔结构
淘宝直播使用S265编码器，支持多层金字塔结构。好处是参考帧更近，相关性更强。金字塔越上层的帧，优先级越低，在网络拥塞时丢弃的影响越小。
参考帧选择时考虑时间、质量、层级
参考帧的选择很重要，选择质量更好的参考帧，解出来的质量也越好，选择越近的参考帧，帧的相似度越高，压缩的质量也就越好。因为每一层都会有质量损失，参考层级越高，质量越差，因此参考层级越高，越需要缩短参考距离，提升帧的质量。
因此，使用S265的时域SVC技术后，不仅能实现拥塞时在CDN边缘节点的丢帧降码率能力，降低卡顿率，还能实现不丢数据时有更高的压缩率，整体压缩率提升5~6个百分点。
不过在极度拥塞的情况下，这还是不够的。需要使用丢gop策略，快速解决拥塞。在一个gop中，需要按照gop纬度统计码率。如果带宽不足的情况下，需要丢弃后面的帧，直到I帧为止。这也带来一个问题，gop中后半程的数据只有音频，数据不足，拥塞控制带宽会降的好多。针对这种情况，算法层面做了一系列调整。
▐ 对抗丢包的策略
对抗丢包的策略，除了前面讲到的降码率，还包括FEC、ARQ/NACK、平滑发送等等。
FEC是前向纠错码，即，在编码的时候，多编一些冗余，使得解码侧丢失一些数据，仍能恢复出原始数据的一种技术。FEC以往通常用于广电系统，在单向传输系统中发挥了重要作用。后来的音视频通信技术，FEC也成为了标配。但直播系统即不同于广电系统，也不同与音视频通信系统。由于观众量巨大，如果编的FEC要对抗每一个观众的丢包，则有大量观众即使网络好也会收到冗余，带来带宽的消耗以及成本提升。如果在CDN边缘针对每个观众重新计算冗余，FEC矩阵计算量比较大，则CDN的计算成本又非常高昂。因此直播系统的FEC，是主播侧编入固定的冗余，CDN在边缘节点针对每个观众的网络，选择透传多少FEC比例，从而达到既能抗网络丢包，又节约成本的目的。
ARQ或者NACK，都是发现丢包时，请求重传的技术。但网络拥塞时，请求重传会加重拥塞情况，需要谨慎使用。
网络上发生卡顿的一大凶手，是网络抖动，例如wifi、4G信号被干扰，可能造成短时间网络中断，然后瞬间所有数据全部到达。瞬间所有数据全部发送，可能造成网络拥塞，导致卡顿，更严重的，如果是超大主播出现发送数据的尖峰，可能直接把CDN节点打满，造成更大范围的卡顿。
平滑发送算法策略防止网络突发，平滑网络流量，尤其是在大量用户同时进入直播间的情况下。同时针对秒开场景深度定制。并且重新设计发送机制和算法，发送性能大大提高，是原生webrtc性能1.4倍以上。平滑发送使用了udp多包发送机制sendmmsg，构造新的发送逻辑，大大提高发送效率。直播场景播放侧有秒开的需求，在启播的阶段服务器会根据配置发送多余gop数据，这个和通信场景的pacer有些不同。
针对直播场景，我们把平滑发送细分三个阶段
-
秒开首帧
-
- 主要是首个I帧的数据，在直播中这个通常很大。首个I帧的数据在配置最大速度下，快速发送给播放端。
-
秒开gop缓存
-
- 首个I帧发送完毕后，使用相对比较大的速度发送gop缓存数据。
-
正常发送
-
- 这个时候按照配置速度发送，或者按照拥塞控制给出的带宽来发送。
此外直播场景还有固定时间大的I帧的冲击。在通信场景中只有pli，fir请求I帧的时候才有大的I帧的发送，数据相对比较平稳。但是直播场景固定2-4s会有I帧的到来，类似下面图例右边的场景。大的I帧在网络带宽不足的情况下，可能会发送200-400ms。由于平滑发送队列中音视频同时存在，会阻塞音频发送。所以我们在秒开阶段是音视频按顺序交错发送，过了秒开阶段，优先发送音频。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
最后
学习视频：
大厂面试真题：
战项目、讲解视频，并且后续会持续更新**
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-EvxyB5uo-1711871684899)]
最后
学习视频：
[外链图片转存中…(img-1ErUjRfg-1711871684899)]
大厂面试真题：
[外链图片转存中…(img-nY0Inacr-1711871684900)]
1714
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
