【GCC】基于延迟梯度的带宽估计：速率控制状态机的理解

已于 2024-08-07 15:36:50 修改
阅读量292 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 传输探索实践 文章标签： webrtc 拥塞控制 GCC 状态机 码率评估
于 2024-08-07 15:36:30 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/commshare/article/details/140991224

  • 这部分是一个难点，决定了目标码率。
  • 参考了很多大神的分析，大神都很牛x，分析的都很到位。
  • 回顾下之前的学习，发现还是在 基于延迟的排队梯度这块，其根本目的就是本文的预估一个下一步的码率出来。
  • 之前的文章都在分析“基于延迟梯度的带宽估计” 的一些原理。

接收端在RTCP中增加transport-cc-feedback字段反馈所有媒体包到达的时间，发送端根据接受延迟和发送间隔计算出延迟梯度，从而估计带宽。

基于延迟梯度的带宽估计：过载检测器

了解本专栏 订阅专栏 解锁全文
【gcc】基于gpt和python的流程和延迟梯度分析
突围
08-05 261
https://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf
【gcc】RtpTransportControllerSend学习笔记 3：gcc 算法
突围
10-07 1437
gcc
流媒体弱网优化之路(WebRTC)——GCC带宽估计算法调优
qw225967的博客
07-14 3796
经过上述的调整，我们下行的屏幕分享流可以很快的进行平衡收敛，随后在发生拥塞的过程中立刻打乱后又重新进行收敛。目的就是实现绝对的码率平均——当然这样的做法只能说是暂时的缓解了问，大家一起讨论看看有没有更多的方式去调整GCC算法呢？
【音视频第1天】常见的术语含义等
Magic_o的博客
03-27 1262
在WebRTC中，ARQ（Automatic Repeat Request）和Nack（Negative Acknowledge）也被用于数据传输过程中检测和纠正错误。发送方发送数据包，接收方收到并检验数据包，若数据包出现错误，则向发送方发送Nack请求重传该数据包。发送方收到Nack后，会重新发送该数据包，直到接收方接收到正确的数据包为止。ARQ和Nack解决的问题也是数据传输过程中的错误。在WebRTC中，数据传输过程中数据包可能会出现错误，比如数据包被丢失、数据包内容损坏等。
Google 实时流拥塞控制算法GCC
u010029439的博客
03-14 1128
1、简介 参考：https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02#section-4.4 gcc是google实时流拥塞控制算法的简称，已经在webrtc中实现，应用于chrome，后面将应用到Hangouts（视频聊天产品）中，主要用于视频流的拥塞控制。 网络瓶颈主要发生在中间的传输设备上，比如路由器，所以如果有中间设备的帮助（ECN），网络瓶颈应该会更早并且更准确的被检测到，gcc属于端到端的拥塞控制算法，端到端的算法将中间路径想象成一个黑盒子
GCC算法 对比 BBR算法
百鸣的专栏
04-03 916
BBR 算法是由 Google 开发的一种 TCP 拥塞控制算法，它主要的目标是减少网络吞吐量的波动和延迟的增长，从而提高网络的整体性能。GCC 是一种通用的 TCP 拥塞控制算法，它可以根据网络带宽和延迟等信息，自适应地调整数据传输速率，以减少拥塞并提高网络性能。GCC 和 BBR 是两种 TCP 拥塞控制算法，都是用于优化网络吞吐量和延迟的方案。总之，GCC 和 BBR 都是优化网络性能的 TCP 拥塞控制算法。两者都有各自的特点和优势，具体的选择需要根据相应的应用场景和需求来确定。
小议WebRTC拥塞控制算法：GCC介绍
yinshipin007的博客
03-06 420
在新近的WebRTC的实现中，所有的带宽估计都放在了发送端，也就说发送端除了做基于丢包的带宽估计，同时也做基于延迟梯度的带宽估计。如果这个数据包丢失怎么办，RFC[2]和WebRTC实现中都是直接忽略，这里涉及的问题是，忽略该包对计算延迟梯度影响不大，只是相当于数据包的分组跨度更大了，丢失的包对计算没有太大影响，但另一个问题是，发送端需要计算接受端的接受速率，当feedback丢失时，会认为相应的数据包都丢失了，这会影响接受速率的计算，这个值在后续计算估计带宽中会用到，从而导致一定误差。
WebRTC发送端带宽估计(trendline)
fdsafwagdagadg6576的专栏
07-15 1379
下文前面是理论介绍,后面是源码分析 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 整体架构 上面这张图是一个比较老的架构图，但是也基本能说明整体架构，早期webrtc版本带宽估计是放到接收端处理，目前最新版本带宽估计放到了发送端，但是接收端计算得到的带宽并没有废弃，而是通过rtcp remb反馈给发送端。 在发送端带宽估计由3个元素结合决定，基于丢包率估算的带宽（丢包率通过rtcp rr得到）、接收端的remb反馈的带宽、发送端带宽估计（方法
When Machine Learning Meets Congestion Control: A Survey and Comparison
CloudsRush的博客
11-14 4226
论文阅读笔记 此论文是一篇综述性的文章，通过阅读本论文可以对拥塞控制算法有一个较为清晰的认识，区分传统算法及辨识各种传统算法的优劣，特别是本文通过导引的方式可以让读者了解机器学习在拥塞控制算法中的应用现状，对应该使用哪种机器学习的方法给读者指明了方向，并使得读者认识到应用RL在CC中的优劣势及面临的挑战。 When Machine Learning Meets Congestion Control: A Survey and Comparison 摘要： 主要介绍机器学习目前跨学科的应用和激增趋势。随后介绍
WebRTC的带宽评估的新变化
闲敲棋子落灯花
03-15 6668
带宽评估(BWE)也许是WebRTC的视频引擎中最关键的模块了, 它将决定视频通信中, 不引发网络拥塞时最多可以产生的视频数据量. 早期的带宽评估算法比较简陋, 大多是基于丢包来估计, 基本的策略是逐步增加发送的数据量, 直到检测到丢包为止. 为了让发送端获悉网络上的丢包信息, 可以使用标准的RTCP的RR来发送周期性的报告. 现代的带宽评估算法则可以在网络链路发送丢包以前就监测到网络
【GCC带宽估计】腾讯云：WebRTC 发送方码率预估实现解析
突围
07-09 655
技术解码 | WebRTC 发送方码率预估实现解析 原创 腾讯云音视频 腾讯云音视频 1周前 图片 技术解码 | WebRTC 发送方码率预估实现解析 导语 WebRTC是一个非常复杂且庞大的东西，今天我们就对其中的发送方码率评估这一块做一个简单的实现解析，帮助大家更好的理解这部分内容。 图片 Google Congestion Control WebRTC使用的是Google Congestion Control (简称GCC)拥塞控制，目前有两种实现： 旧的实现是接收方根据收到的音视频RT
弱网优化，GCC 动态带宽评估算法（内附详细公式）
weixin_44764152的博客
05-17 2383
通过上次的《RTC 系统音视频传输弱网对抗技术概览》，我们知道 RTC 的三大核心指标为实时性、清晰度、流畅度。在整个通话过程中核心表现达标，才能给用户一个基本的良好体验。关注【融云全球互联网通信云】了解更多 然而音视频数据在网络中传输时，网络是变化多端和不可预知的，比如地铁、公交、 家里、公司公用 WiFi，以及不同时间段流量高峰等造成的网络变化都不一样，这些都会造成网络的抖动、带宽容量动态变化等，最终影响音视频的体验。 因此，我们需要对网络带宽变化进行有效的动态探测和评估，保证音视频链路上发送的音视
音视频传输-带宽评估
loycine的博客
06-17 2741
音视频传输 - 带宽评估 网络拥塞是基于IP协议的数据宝交换网络中常见的一种网络传输问题。网络拥塞是导致网络吞吐降低，网络丢包等的主要原因之一。 WebRTC中传输的采用的是UDP协议，WebRTC的传输层采用的拥塞算法是GCC算法。 Google congestion control 1. 基于丢包的拥塞机制 基于丢包的拥塞控制比较简单。其基本思想是根据丢包的多少来判断网络的拥塞程度，丢包越多则...
WebRTC带宽估计
简单生活
03-28 6057
整体架构 上面这张图是一个比较老的架构图，但是也基本能说明整体架构，早期webrtc版本带宽估计是放到接收端处理，目前最新版本带宽估计放到了发送端，但是接收端计算得到的带宽并没有废弃，而是通过rtcp remb反馈给发送端。 在发送端带宽估计由3个元素结合决定，基于丢包率估算的带宽（丢包率通过rtcp rr得到）、接收端的remb反馈的带宽、发送端带宽估计（方法类似于接收端的带宽估计，具体逻辑下面会介绍到），取三者带宽的最小值作为最终带宽估计值。 接口说明 rr https://tools..
webrtc 带宽估计
EveryDayOneHour的博客
02-06 3254
1、整体架构： 此图是接收端码率控制整体结构图分成3个部分。 第一部分采集和发送：camera encode通过Pacer并结合fec发送。 第二部分基于延时的码率计算（卡尔曼模型）。 第三部分是结合丢包和延时计算出综合码率发送编码器。 2 发送端基于丢包率的码率控制 接收端维护两个计数器，每收到一个RTP包都更新： transmitted，接收到的RTP包的总数； ret...
FreeSWITCH Record
qq_27890899的博客
08-13 1602
FreeSWITCH学习记录，从部署到配置，从Java后端到H5前端，旨在实现一套企业级融合通信系统。
工具变量-5G示范城市DID（2014-2025）.xlsx
07-31
详细介绍及样例数据：https://blog.youkuaiyun.com/T0620514/article/details/149811741
langchain4j-web-search-engine-searchapi-0.34.0.jar中文文档.zip
07-31
1、压缩文件中包含： 中文文档、jar包下载地址、Maven依赖、Gradle依赖、源代码下载地址。 2、使用方法： 解压最外层zip，再解压其中的zip包，双击 【index.html】 文件，即可用浏览器打开、进行查看。 3、特殊说明： （1）本文档为人性化翻译，精心制作，请放心使用； （2）只翻译了该翻译的内容，如：注释、说明、描述、用法讲解 等； （3）不该翻译的内容保持原样，如：类名、方法名、包名、类型、关键字、代码 等。 4、温馨提示： （1）为了防止解压后路径太长导致浏览器无法打开，推荐在解压时选择“解压到当前文件夹”（放心，自带文件夹，文件不会散落一地）； （2）有时，一套Java组件会有多个jar，所以在下载前，请仔细阅读本篇描述，以确保这就是你需要的文件。 5、本文件关键字： jar中文文档.zip,java,jar包,Maven,第三方jar包,组件,开源组件,第三方组件,Gradle,中文API文档,手册,开发手册,使用手册,参考手册。
基于GJO-TCN-BiGRU-Attention的Matlab多变量时间序列预测算法及应用 - 注意力机制
最新发布
07-31
内容概要：本文介绍了利用Matlab实现的一种基于GJO-TCN-BiGRU-Attention的多变量时间序列预测方法。该方法结合了时间卷积网络(TCN)、双向门控循环单元(BiGRU)以及注意力机制，用于提高时间序列预测的准确性。文中详细描述了模型架构的设计思路，包括各层的功能及其相互关系，并提供了完整的源代码和数据集。此外，还讨论了参数优化的方法，特别是采用金豹优化(GJO)算法进行超参数调整的具体步骤。实验结果显示，该模型在电力负荷预测任务中表现出色，R2评分达到了0.93，MAPE约为4.7%，相比单一模型提升了大约8个百分点。 适用人群：对时间序列预测感兴趣的科研工作者、工程师和技术爱好者，尤其是那些希望深入了解并应用于实际项目的人员。 使用场景及目标：适用于需要处理复杂多变量时间序列数据的应用场景，如能源管理、金融分析等领域。目标是帮助用户掌握一种高效的时间序列预测工具，能够根据历史数据对未来趋势做出精准判断。 其他说明：作者分享了一些实践经验，比如避免TCN层数过多导致梯度爆炸的问题，推荐使用RobustScaler进行数据标准化处理，以及选择合适的序列滑窗长度等技巧。
GCC 4.6.2开发指南：入门与深入理解
本篇文档是关于GNU Compiler Collection (GCC) 的一份完整教程，特别针对的是GCC 4.6.2版本。作者是Richard Stallman以及庞大的GCC开发者社区，由GNUPress出版，隶属于Free Software Foundation。这份教程的目的是...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

等风来不如迎风去

你的鼓励是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值