深入浅出WebRTC
文章平均质量分 95
old-six-programmer
一个老六程序员
展开
-
深入浅出WebRTC—Pacer
报文优先级定义如下,数字越小优先级越高(参考函数GetPriorityForType)。0 - Audio本文详细分析了 WebRTC 平滑发送模块的整体框架和实现原理,并对重要的数据结构和逻辑进行了深入剖析。平滑发送模块设计的非常灵活,采用动态发包周期和漏桶控制机制,能够满足媒体报文发送、带宽探测、高优先级报文优先发送等多种发送要求。不过,相比于固定发包周期,这种设计实现起来更加复杂性,大家在借鉴的时候,要充分评估、小心谨慎。原创 2024-07-23 10:17:20 · 1127 阅读 · 0 评论 -
深入浅出WebRTC—LossBasedBweV2
与带宽一样,固有丢包率(inherent loss)也是网路链路的一个属性,而且是动态变化的。当观察到丢包的时候,我们如何判断这是由于链路固有丢包率导致的丢包还是由于网络拥塞导致的丢包?除非我们知道链路的固有丢包率和带宽,但显然这是无法办到的。WebRTC 为解决这个问题打开了一扇窗,其思路是建立网络丢包的二项式分布模型,通过搜集足够多的观测值,构造目标函数,使用牛顿方法去搜索链路带宽和固有丢包率的最佳组合。然后对这个最佳组合进行必要的校正与调整。原创 2024-07-23 03:37:28 · 1171 阅读 · 0 评论 -
深入浅出WebRTC—ULPFEC
ULPFEC 实现的核心是 FEC 保护比率的计算和掩码表的生成,FEC 保护比率决定了能使用多少 FEC 报文来保护原始报文,掩码表决定了 FEC 报文如何保护原始报文。围绕这两个核心概念,涉及如何生成 FEC 报文,如何打包和解包、如何发送和接收以及如何恢复原始报文等相关处理逻辑。原创 2024-07-22 02:54:18 · 1237 阅读 · 0 评论 -
深入浅出WebRTC—NACK
WebRTC NACK 的实现简单明了,发送端缓存报文,接收端请求重传。但发送端和接收端实现关注重点不太一样。发送端是被动接收 NACK 请求,实现相对简单一些,重点关注缓存队列的长度。接收端需要主动发送发送 NACK 请求,实现会相对复杂一些,由于存在报文乱序,什么时候发起 NACK 请求是一个值得斟酌的事情。除此之外,WebRTC 还考虑到了瞬间突发丢包的快速重传机制和基于关键帧的队列收缩等,这些都凸显了 WebRTC 对细节的掌控和重视。原创 2024-07-20 00:01:42 · 2250 阅读 · 0 评论 -
深入浅出WebRTC—ALR
识别 ALR 状态对 WebRTC 的拥塞控制来说非常重要,很多人可能没有意识到这一点。为什么这么说,是因为,WebRTC 的拥塞控制算法本质上是一种“刀尖上跳舞”的算法,只有当你要求的最大带宽超过链路容量时,才需要做拥塞控制,此时 WebRTC 会在链路容量的上限疯狂试探。如果带宽随便你使用,怎么用都用不完,怎么用都不会造成拥塞,那也就没必要做拥塞控制了。ALR 状态本质上是用来标识当前带宽是否够用,进入 ALR 状态和退出 ALR 状态,所需要的控制策略是不一样的,相关算法都需要做调整。原创 2024-07-19 22:01:24 · 1301 阅读 · 0 评论 -
深入浅出WebRTC—DelayBasedBwe
基于延迟的带宽估计,以处于非 ALR 状态的 ACK 码率为基础,基于延迟梯度估计链路真实带宽,实现对链路带宽的动态跟踪,算法的核心逻辑可以表述为:1)网络过载,说明网络产生拥塞,当前发送码率过高,需要降低发送码率。2)网络欠载,说明网络正在排空,不要急着提升发送码率,先保持当前发送码率一段时间。3)网络正常,可以试着增加发送码率,探测下带宽的上限。同时,在网络非过载状态下,使用探测带宽对估计值进行校正,使估计更加精准。算法在计算延迟梯度、判断网络使用状况都做了精心的设计,会尽量排除随机噪声的干扰。原创 2024-07-19 20:46:24 · 2289 阅读 · 0 评论 -
深入浅出WebRTC—GCC
简单总结下 WebRTC 拥塞控制思路。拥塞控制的核心是获取链路的带宽,对于实时音视频通信来说,还要考虑延时指标。因为只有获得了链路的真实带宽,才能确保发送的码率不会超过链路容量,从而避免产生拥塞。那有没有一种办法,在不发送码流的情况下,提前知道链路的真实带宽呢?答案是没有。这个问题貌似变成了一个先有鸡还是先有蛋的问题。理论上是这样的,但实践中,可以采用一个带有负反馈回路的控制算法来打破这个循环魔咒,这就是 WebRTC 拥塞控制的核心思想。原创 2024-07-19 18:45:03 · 1428 阅读 · 1 评论