一些webrtc gcc相关

最新推荐文章于 2025-09-02 20:24:20 发布
原创 最新推荐文章于 2025-09-02 20:24:20 发布 · 1k 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

1. 
Google Congestion Control（就是WebRTC中用的）
WebRTC通控制发送端数据发送码率来达到控制网络拥塞。
draft-ietf-rmcat-gcc-02.pdf 
（较早的草案draft-alvestrand-rmcat-congestion-03.pdf）


2.
（1）从WebRTC的最初级阶段开始，媒体引擎（由Google搭建，但是Firefox和Chrome都在使用）
就是基于远端带宽估计理论而搭建的。正像我之前说的那样，接收端会分析包间延时，
并且会对可用带宽产生一个估计值，然后使用RTCP信息报回给发送端，其中RTCP信息使用了
一种被设计来完成这项工作的信息类型：REMB。
REMB文档： draft-alvestrand-rmcat-remb-03.pdf


（2）另一个关于WebRTC实现的细节是，发送端不会只使用这个在REMB包中接收的带宽估计值，
也会使用反馈的丢包来决定最终发送的目标视频比特率。


send_side_bandwidth_estimation.cc
UpdateEstimate中更新lossRate;


（3）源代码  
控制上行带宽的文件在webrtc/modules/bitrate_controller，
下行带宽的文件是webrtc/modules/remote_bitrate_estimator


（4）传输与反馈
#1 传输宽序列号的报头扩展；
#2 传输反馈：接收端会周期性地将包含有关已接收数据包和包间延时的信息反馈给发送端。为了完成这项工作，接收端使用了新的RTCP包（传输反馈）
采用了部分Google建议的规范：https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-00
采用了部分官方标准化：https://www
最低0.47元/天 解锁文章
webrtc gcc详解
sweibd的专栏
07-07 1729
webrtc的gcc算法(Google Congestion Control)，貌似国内很多文章都没有细讲，原理是怎么样的，具体怎么进行计算的。这里详解一下gcc
WebRTC GCC代码深度解读(12) Probe:ProbeController
yinshipin007的博客
02-28 896
probe的思想是，在短时间内以目标码率发送数据，如果被ACK的码率达到发送码率的一定比例，那么便认为探测成功，此时链路可用带宽即是我们探测到的带宽。// 如果还需要继续探测，那么需要设置一个下次探测的最低带宽min_bitrate_to_probe_further_bps_// 全局的probe id，自增。// 分为两次，第一次为3*start_bitrate_bps_，第二次为6*start_bitrate_bps_
WebRTC 基于GCC的拥塞控制(上)
伍意的博客
02-22 3761
实时流媒体应用的最大特点是实时性，而延迟是实时性的最大敌人。从媒体收发端来讲，媒体数据的处理速度是造成延迟的重要原因；而从传输角度来讲，网络拥塞则是造成延迟的最主要原因。网络拥塞可能造成数据包丢失，也可能造成数据传输时间变长，延迟增大。 拥塞控制是实时流媒体应用质量保证(QoS)的重要手段之一，它在缓解网络拥堵、减小网络延迟、平滑数据传输等质量保证方面发挥重要作用。WebRTC通控制发送端数
WebRTC GCC算法介绍
月天寒的专栏
07-28 1215
转自：http://mp.weixin.qq.com/s?__biz=MzI2MzA4MTgxNw==&mid=2652046558&idx=2&sn=5f6b34c37f4cb72a2dbacc2e990f05a9&scene=23&srcid=0728AGRb292ufggiuyQ1qUx0#rd 虽然视频会议已商用了多年，特别是SKYPE这样的视频应用在互联网上已有10年时间，但针对实时音
流媒体学习之路(WebRTC)——GCC分析（1）
qw225967的博客
07-21 1829
gcc全流程分析
WebRTC GCC 拥塞控制算法（TCC-GCC）
椛茶的博客
12-07 5549
网络传输中链路的带宽是有限的，为避免往链路发送过载的数据量导致网络拥塞，我们需要进行带宽预估，结合预估带宽作出调整避免网络拥塞。 在《WebRTC GCC 拥塞控制算法（REMB-GCC）》中我们总结了 REMB-GCC 拥塞控制算法，并在文末提到 Google 已经推出 TCC-GCC 取代 REMB-GCC。TCC-GCC 的原理也是基于延时梯度和丢包率进行带宽预估并避免网络拥塞，不同之处在于逻辑都在发送端进行计算，接收端只是反馈包的接收状态（是否收到，以及与上一个包的接收时间差）。
WebRTC GCC拥塞控制算法详解
yinshipin007的博客
03-02 1109
m74GCC全称Google Congest Control，所谓拥塞控制，就是控制数据发送的速率避免网络的拥塞。可以对比TCP的拥塞控制算法，由于WebRTC使用基于UDP的RTP来传输媒体数据，需要一个拥塞控制算法来保证基本的Qos。*注：本文不涉及Transport CC，只是早期版本的GCC。GCC核心思想就是通过预测可用带宽来控制发送的速率，会结合发送端和接收端两端各自估测的带宽来综合计算，其中发送端的带宽估测主要依赖于丢包率(其实也有延迟)，接收端的带宽估测依赖于延迟(的变化)。换句话说，GCC
webrtc gcc算法(1)
hyl999的专栏
10-16 935
在最近的WebRTC实现中， GCC把它的两种拥塞控制算法都移到了发送端来实现， 但是两种算法本身并没有改变，只是在发送端需要计算延迟， 因而需要一些额外的feedback信息， 为此WebRTC扩展了RTCP协议， 其中最主要的是增加了Transport-CC Feedback，该包携带了接收端接收到的每个媒体包的到达时间。基于丢包的拥塞控制比较简单， 其基本思想是根据丢包的多少来判断网络的拥塞程度， 丢包越多则认为网络越拥塞， 那么我们就要降低发送速率来缓解网络拥塞；
WebRTC GCC 拥塞控制算法（REMB-GCC）
椛茶的博客
11-19 4873
在网络传输中，所有应用程序都需要拥塞控制以避免网络出现拥塞的情况，对于音视频传输也是如此，假设发送方以某个码率值发送数据，但是网络出现拥塞，此时发送方应该降低发送码率，当网络拥塞情况好转，发送方又可以提升发送码率。GCC 算法是出自 Google 的一种结合延时梯度和丢包率的拥塞控制算法，WebRTC 默认使用该算法。
深入浅出WebRTC—GCC
程序员老六的专栏
07-19 2496
简单总结下 WebRTC 拥塞控制思路。拥塞控制的核心是获取链路的带宽，对于实时音视频通信来说，还要考虑延时指标。因为只有获得了链路的真实带宽，才能确保发送的码率不会超过链路容量，从而避免产生拥塞。那有没有一种办法，在不发送码流的情况下，提前知道链路的真实带宽呢？答案是没有。这个问题貌似变成了一个先有鸡还是先有蛋的问题。理论上是这样的，但实践中，可以采用一个带有负反馈回路的控制算法来打破这个循环魔咒，这就是 WebRTC 拥塞控制的核心思想。
WebRTC拥塞控制算法——GCC介绍
yinshipin007的博客
03-01 740
网络拥塞是基于IP协议的数据报交换网络中常见的一种网络传输问题，它对网络传输的质量有严重的影响， 网络拥塞是导致网络吞吐降低， 网络丢包等的主要原因之一， 这些问题使得上层应用无法有效的利用网络带宽获得高质量的网络传输效果。特别是在通信领域， 网络拥塞导致的丢包， 延迟， 抖动等问题， 严重的影响了通信质量， 如果不能很好的解决这些问题， 一个通信产品就无法在现实环境中正常使用。 在这方面WebRTC中的网络拥塞控制算法给我们提供了一个可供参考的实现，这篇小文会尽量详细的介绍WebRTC中的拥塞控制算法--
WebRTC-gcc算法详解
viyana的博客
07-07 516
本文为翻译和理解，这里是原文链接 本文翻译参考了知乎的博文，参考链接，并对其翻译，进行了微调，使其阅读更加顺畅，更容易阅读。 建议阅读本文时，参考原文，配合阅读，毕竟翻译水平有限，防止个人理解误导。 A Google Congestion Control Algorithm for Real-Time Communication draft-alvestrand-rmcat-congestion-031 简介2 系统模型3 反馈和扩展4 Delay-based control4.1 到达时间模型4.2 到达
流媒体学习之路(WebRTC)——GCC分析（4）
qw225967的博客
01-02 2212
WebRTC 的 InterArrival 类是用于计算包之间的到达时间差(Inter-Arrival Time)的类。如果观察WebRTC的提交记录你会发现，这个类随着卡尔曼滤波器、趋势线等等算法的变更也一直在调整。那么为什么要存在这个接收间隔的计算类呢？细心的小伙伴在观察我们发送视频数据的时候会发现，数据的发送是一股一股的——常常是一次发送几个包。
流媒体学习之路(WebRTC)——GCC分析（2）
qw225967的博客
09-30 1507
本模块主要针对趋势线滤波模块进行理论分析与解释，并对比旧的卡尔曼滤波器内容进行分析，来得到调整参数的参考。本文主要介绍了如何根据时延梯度得到网络状态，判断网络拥塞状况，并结合WebRTC相关源码进行分析。当我们得到当前网  络拥塞状况后，就要对发送码率进行调节，以适应当前网络。后续文章我们将研究如何根据网络状态进行相应码率调整。
【音视频】 WebRTC GCC 拥塞控制算法
最新发布
Antonio915的博客
09-02 1567
GCC（Google Congestion Control）是 Google 为实时音视频通信（RTC）设计的拥塞控制算法，是 WebRTC 框架默认的拥塞控制方案。其核心目标是在避免网络拥塞的前提下，最大化利用网络带宽，同时保证音视频传输的低延迟和低丢包率 —— 这对实时场景（如视频会议、直播）至关重要。
流媒体弱网优化之路(WebRTC)——GCC带宽估计算法调优
qw225967的博客
07-14 4480
经过上述的调整，我们下行的屏幕分享流可以很快的进行平衡收敛，随后在发生拥塞的过程中立刻打乱后又重新进行收敛。目的就是实现绝对的码率平均——当然这样的做法只能说是暂时的缓解了问，大家一起讨论看看有没有更多的方式去调整GCC算法呢？
WebRTC基于GCC的拥塞控制分析
SkylineRunner的博客
09-12 1639
本文转自anyRTC论坛下的https://bbs.anyrtc.io/d/15/3，感谢原作者分享。   本文从源代码实现角度对WebRTC的GCC算法进行分析，所以说本文非常适合大小码农。主要内容包括: RTCP RR的数据源、报文构造和接收,接收端基于数据包到达延迟的码率估计,发送端码率的计算以及生效于目标模块。 拥塞控制是实时流媒体应用的重要服务质量保证。通过本文从数学基础、算法步骤...
流媒体学习之路(WebRTC)——GCC分析（3）
qw225967的博客
02-13 1472
该模块会通过ack情况计算出对端接收数据的情况，通过经验值调整作为当前吞吐量的估计值用于计算下一次发送的码率。该模块计算出来的吞吐量会作用到码率计算模块，是一个非常重要的模块。根据每一次feedback的数据量作为采样点，通过贝叶斯估计获得一个平滑的估计值。贝叶斯估计补充：贝叶斯估计是统计学范畴里常用的参数估计方法，是基于先验采样。在经典的频率统计中，参数是固定的，样本统计量是随机变量。而在贝叶斯统计中，认为参数也是随机变量，服从某一概率分布的随机变量，贝叶斯统计的重点是研究参数的分布。
webrtc gcc
09-12
WebRTC GCC（Generic Congestion Control）是WebRTC中的一种拥塞控制算法。它基于丢包率估计带宽，并通过计算最小的发送码率来调整发送速率。根据引用[2]中的描述，GCC的最终发送码率是两种拥塞控制算法计算的发送...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值