qw225967的博客

音频NackTracker的逻辑与视频NackRequest有相似的地方，但是相比多了播放时间以及丢包的等待估计，因此限制更多。在同样的模拟环境下，原NackTracker的逻辑丢包明显。这与音频的特点有关，音频可以合理的丢弃数据并不会明显的影响听感，但是视频少一个数据就无法组成完整的图像。因此WebRTC为了保证实时性，增加了播放时间对比以及丢包参考，如果想要保证Nack的效果与视频一致，那么也需要调整一下它的频率和最大限制。

ProbeBitrateEstimator和AcknowledgedBitrateEstimator两个类是gcc做码率控制的基础，webrtc对AcknowledgedBitrateEstimator的修改较少，但是对Probe相关的类一直在做调整。上面展示的m77代码和我最近看的m105代码差距就已经发生明显的变化。在Pacer中，m105增加了线程控制而且产生padding包的逻辑也做了调整。同时在触发探测的逻辑上也进行多处修改。

前面为大家介绍了GCC的部分逻辑，GCC作为码率控制的第一环所有的数据都会收到它输出的参考码率的限制。在发送的数据内容中有很多的分类：视频数据、音频数据、重传数据、FEC数据。FEC前面有向大家介绍过，中文称为：前向纠错。在WebRTC中有一个很好的Fec应用例子，它通过RR回复的网络信息进行动态调整，使得在传输中抵抗不同程度的网络损伤。下面我针对FEC给大家介绍一下动态变化的逻辑。FecController是WebRTC提供的接口，如果需要自定义自己的控制类，那么继承它之后进行开发就可以了。

Pacer（Packet Pacing）的作用是在传输数据时能平滑的发送出去，减少对网络冲击和抖动的产生，提高通信质量。在一次数据传输中，如果所有包几乎同时发送，网络就可能会遭遇到冲击，这就可能导致网络拥塞，数据包丢失等问题。为了避免这样的问题，需要通过一个定时器均匀分散发送数据包。特别是在音视频传输中，PACER更是非常重要的一部分。因为音视频的传输对于网络的稳定性和实时性要求非常高，任何形式的网络抖动或者丢包都会造成音视频的卡顿，延迟等问题。

WebRTC 的 InterArrival 类是用于计算包之间的到达时间差(Inter-Arrival Time)的类。如果观察WebRTC的提交记录你会发现，这个类随着卡尔曼滤波器、趋势线等等算法的变更也一直在调整。那么为什么要存在这个接收间隔的计算类呢？细心的小伙伴在观察我们发送视频数据的时候会发现，数据的发送是一股一股的——常常是一次发送几个包。

它提供的高度灵活性、适应性和计算能力扩展了在包括网络运营和管理在内的多个领域中使用的传统方法。在本文中，我们探索了基于RL的CC算法的性能，并提出了当前基于RL的CC算法存在的问题。例如：当某些包从一个高延迟的路由转向一个低延迟的路由时，假设其他路由的延迟不变就会产生乱序的情况（但大概率在p2p的模式下发生比较明显）。这类情况也是随机而又聚簇的形式，假设这类路由出现明显的乱序也会出现和无线丢包类似的情况（这个在现代的流媒体传输中尤为重要，因为流媒体传输要保证绝对的时序性）。

GCC竞争分析：GCC在弱网产生的瞬间，按它自身的敏感特性立刻下调到了**最低的状态**，随后**动态阈值生效**，进入上涨的周期，直到与BBR平衡后可以基本维持竞争能力。BBR竞争分析 ：BBR在弱网产生的瞬间，利用congestion_windows 和 bytes_in_flight判定了网络拥塞，限制了发送。随后由于网络竞争方GCC下调码率，飞行数据大量降低，于是立刻恢复了带宽利用。随后在于GCC的竞争中逐渐趋于平衡。

本文简单介绍了quiche中，BBR-V1的实现主流程，还有很多细节没有详细介绍。在quic的BBR算法中，思想主要集中在对整个传输链路承载能力的检测，重点是采样检测而非GCC逻辑中的预估。这两种思想的不同也造就了BBR算法相比GCC算法更主动，在带宽抢占中更有野性。同时，BBR中比较关键的点是保证采样的可靠性，因此使用什么类型的滤波、回归算法也是BBR可靠性很重要的一部分。后续我们将会对这些算法进行更深入的了解。

经过上述的调整，我们下行的屏幕分享流可以很快的进行平衡收敛，随后在发生拥塞的过程中立刻打乱后又重新进行收敛。目的就是实现绝对的码率平均——当然这样的做法只能说是暂时的缓解了问，大家一起讨论看看有没有更多的方式去调整GCC算法呢？

本文简单演示了断点整个GCC统计的流程——比较水。大家如果有兴趣的话可以在github下载我的demo代码，一点点去断点调试，后续会加入更多的带宽估计算法，并且会做更多有趣的实验。欢迎大家使用！

流媒体弱网优化之路(WebRTC)——jitterbuffer分析与优化我正在的github给大家开发一个用于做实验的项目 —— github.com/qw225967/Bifrost目标：可以让大家熟悉各类Qos能力、带宽估计能力，提供每个环节关键参数调节接口并实现一个json全配置，提供全面的可视化算法观察能力。欢迎大家使用！文章目录流媒体弱网优化之路(WebRTC)——jitterbuffer分析与优化一、jitterbuffer原理二、jitterbuffer的实现三、framebuf

该模块会通过ack情况计算出对端接收数据的情况，通过经验值调整作为当前吞吐量的估计值用于计算下一次发送的码率。该模块计算出来的吞吐量会作用到码率计算模块，是一个非常重要的模块。根据每一次feedback的数据量作为采样点，通过贝叶斯估计获得一个平滑的估计值。贝叶斯估计补充：贝叶斯估计是统计学范畴里常用的参数估计方法，是基于先验采样。在经典的频率统计中，参数是固定的，样本统计量是随机变量。而在贝叶斯统计中，认为参数也是随机变量，服从某一概率分布的随机变量，贝叶斯统计的重点是研究参数的分布。

2022年7月25日，Google在arXiv平台上发布了一篇名为：SQP: Congestion Control for Low-Latency Interactive Video Streaming 的文章（这篇文章上下充斥着与Copa较量的意味，可能GCC被Copa比下去了很不爽，赶紧找了个场子）。文章内容详细介绍了他们为了应对低延迟场景设计的新拥塞控制算法，并给出了一些测试对比的效果，今天我们详细地看看这篇文章。

在mediasoup上行中引入了RED编码来抵抗音频丢包造成的质量下降，将RED解码部分放置于Consumer中，实现尾端解码。

使用mediasoup最新加入的h264源码，并在该基础上进行新的优化。

本文主要简单解释了一下FEC的编码和解码的实现，同时展示了经过我修改的webrtc源码。之前文章中引入fec的部分还存在问题。主要是因为使用了同一条ssrc导致flexfec内部出现异常。我们需要在解码的部分所有判断ssrc的地方都区别一下media包和fec包才行。如果不区别这个问题会造成小部分fec包无法恢复，但大部分都是正常的。

本模块主要针对趋势线滤波模块进行理论分析与解释，并对比旧的卡尔曼滤波器内容进行分析，来得到调整参数的参考。本文主要介绍了如何根据时延梯度得到网络状态，判断网络拥塞状况，并结合WebRTC相关源码进行分析。当我们得到当前网  络拥塞状况后，就要对发送码率进行调节，以适应当前网络。后续文章我们将研究如何根据网络状态进行相应码率调整。

gcc全流程分析

本文讲了mediasoup的拥塞控制接收端类，讲得稍微细一些。其实主要就两个功能产生发送端带宽估计的feedback报文、产生接收端估计的remb报文（已废弃）。remb和transport-cc两个在mediasoup中无法同时使用，所以这俩只有一个会在工作时运行，之后的文章我们会跟着分析一下webrtc的gcc算法和发送控制类——TransportCongestionControlClient。httpshttpshttps。...

流媒体学习之路(mediasoup)——前后端交互全流程解析（8）文章目录流媒体学习之路(mediasoup)——前后端交互全流程解析（8）