WebRTC系列-网络之带宽估计和码率估计(3)接收端带宽估计-发送端

已于 2022-10-25 10:59:07 修改
阅读量552 收藏
点赞数
分类专栏： WebRTC进阶 文章标签： 1024程序员节 webrtc
于 2022-10-24 18:20:47 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lym594887256/article/details/127485825
版权
本文详细探讨了WebRTC中接收端带宽评估的丢包处理，包括收包一致性的处理、丢包评估算法以及评估值的限制。在丢包处理部分，讲解了OnTransportLossReport方法如何处理RTCP报告中的丢包。接着，文章分析了滑动窗口及本地发包处理，如本地发包的ProcessSentPacket方法和CongestionWindowPushbackController的角色。整体来看，WebRTC在丢包率为10%以下时表现良好，但面对高丢包率场景，仍需要针对性优化。
摘要由CSDN通过智能技术生成

文章目录


在上一篇文章 WebRTC系列-网络之带宽估计和码率估计(2)接收端带宽估计主要介绍了接收端带宽估计在接收端根据延迟估计评估发送端的带宽然后通过RTCP发送的过程；
这一篇主要介绍WebRTC接收端带宽估计的发送端处理；

1. 丢包处理

在之前的文章中也介绍了gcc算法主要是基于丢包率（Loss-based BWE）和网络延迟（Delay-based BWE）进行码率估计；上篇文章分析了基于接收端延迟带宽估计算了；这篇就从发送端的丢包开始；

1.1 收包一致

其中GoogCcNetworkController是WebRTC在发送端的主要处理函数(不管是发送端评估还是接收端评估都是在这个类中)；
其中OnTransportLossReport方法，就是主要处理来着rtcp报告的丢包的方法，其调用堆栈如下：
在这里插入图片描述
其中GoogCcNetworkControl

了解本专栏 订阅专栏 解锁全文 超级会员免费看
简简单单lym
关注
专栏目录
订阅专栏
WebRTC系列-网络之带宽估计和码率估计(4)接收端带宽估计-发送端paced
HOSTEN的博客
10-28 626
这篇是接收端带宽评估的最后一篇，在上一篇中分析了在接收端基于丢包的带宽估计处理方法；带宽估计后的值一方面会反馈到编码器控制编码码率，同时也会反馈到节拍器中；
WebRTC系列-网络之带宽估计和码率估计(1)
HOSTEN的博客
10-18 802
之前写过一篇WebRTC带宽评估的文章，这篇文章主要介绍设置参数对WebRTC带宽评估接口的影响以及带宽评估后的结果对于音视频编解码器码率的影响；以这篇文章为开篇，接下来重点开始分析WebRTC中的网络模块中的重点拥塞控制及带宽评估；webrtc版本:M76。
WebRTC带宽估计
fishmai的专栏
04-09 9371
带宽估计可能是WebRTC视频引擎中最重要的一部分了。带宽估计（BWE）模块的任务是决定你可以发送多大的视频流且不会造成网络拥塞，以此来保证不会降低视频质量。          在以前的带宽估计算法还是十分基础的，大体上是基于丢包而设计的。通常我们在开始慢慢的增加视频的比特率，直到我们检测到丢包为止。为了检测丢包，你使用标准的RTCP反馈，其中接收端使用RTCP接收端报告（RR）信息来周期性
webrtc 带宽估计
EveryDayOneHour的博客
02-06 2861
1、整体架构： 此图是接收端码率控制整体结构图分成3个部分。 第一部分采集和发送：camera encode通过Pacer并结合fec发送。 第二部分基于延时的码率计算（卡尔曼模型）。 第三部分是结合丢包和延时计算出综合码率发送编码器。 2 发送端基于丢包率的码率控制 接收端维护两个计数器，每收到一个RTP包都更新： transmitted，接收到的RTP包的总数； ret...
WebRTC系列-网络之带宽估计和码率估计(2)接收端带宽估计
HOSTEN的博客
10-20 557
上一篇介绍了WebRTC中带宽估计整体类关系；也介绍了接收端带宽估计的主要类及关系，这节就从类开始分析源码。
【网络通信 -- WebRTC】WebRTC 源码分析 -- GCC 带宽估计 -- 接收端带宽估计
CopperSun 技术博客
06-23 776
【网络通信 -- WebRTC】WebRTC 源码分析 -- 接收端带宽估计 【1】OveruseEstimator 中的卡尔曼滤波公式简介 【2】OveruseDetector 中的带宽负载信号的触发与阈值的动态调整 阈值动态调整公式 为到达时间差，为时刻的延迟，为自适应增益； 带宽负载信号触发时机的判断 并且持续时间大于 100ms 则判断为带宽过载 则判断为带宽过量 则判断为带宽正常 【3】AimdRateControl 中有限状态机的状态转移 ......
WebRTC系列-- 带宽估计参数及限制编码器编码码率流程
HOSTEN的博客
05-13 1293
文章目录发送端带宽估计核心类 SendSideBandwidthEstimation带宽估计限制参数参数设置流程视频编码器的速率调整评估码率分配核心类BitrateAllocatorAddObserver方法AllocateBitrates 方法音频码率调整及参数 发送端带宽估计核心类 SendSideBandwidthEstimation 带宽估计限制参数 SendSideBandwidthEstimation 是发送端带宽估计的核心处理类;在其中的头文件中有三个关键参数: DataRate curr
WebRTC发送端带宽估计(trendline)
fdsafwagdagadg6576的专栏
07-15 1282
下文前面是理论介绍,后面是源码分析 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 整体架构 上面这张图是一个比较老的架构图，但是也基本能说明整体架构，早期webrtc版本带宽估计是放到接收端处理，目前最新版本带宽估计放到了发送端，但是接收端计算得到的带宽并没有废弃，而是通过rtcp remb反馈给发送端。 在发送端带宽估计由3个元素结合决定，基于丢包率估算的带宽（丢包率通过rtcp rr得到）、接收端的remb反馈的带宽、发送端带宽估计（方法
WebRTC 中带宽估计与拥塞控制算法
最新发布
qq_31231915的博客
02-19 477
BBR 使用其模型寻找具有高吞吐量的操作点和低延迟，以在最佳工作点附近工作，系统需要保持两个条件：Rate Balance（最大发送速率）和 Full Pipe（BDP = BBR.BtlBw * BBR.RTprop）。：基于丢包的带宽估计，其基本思想是根据丢包的多少来判断网络的拥塞程度。丢包越多则认为网络越拥塞，发送速率就需要降低；基于发送端的延迟算法，也是利用区间延迟值，通过 TrendLine 滤波器（最小二乘法滤波器），通过斜率的增加或者减小来判断当前网络的拥塞状况。
webrtc中的带宽自适应算法
SurpassLi的专栏
03-26 673
webrtc中的带宽自适应算法分为两种： １，　发端带宽控制，　原理是由rtcp中的丢包统计来动态的增加或减少带宽，在减少带宽时使用TFRC算法来增加平滑度。 ２，　收端带宽估算，　原理是并由收到rtp数据，估出带宽；　用卡尔曼滤波，对每一帧的发送时间和接收时间进行分析，　从而得出网络带宽利用情况，修正估出的带宽。 两种算法相辅相成，　收端将估算的带宽发送给发端，　发端结合收到的带宽以及丢包率，调整发送的带宽。 下面具体分析两种算法： 2, 接收端带宽估算算法分析 结合文档ht...
webrtc研究-视频接收端处理
boywgw的专栏
04-27 464
http://blog.csdn.net/liuhongxiangm/article/details/53581064
webrtc 发送带宽估计
liuhongxian的专栏
06-29 2414
几个问题 1、webrtc的发送带宽估计是针对每一路流还是总的带宽 2、webrtc的remb是统计的整体带宽吗？ 3、如果webrtc同时观看了多路流，如何针对每一路流反馈带宽，丢包等信息 5、如果webrtc同时发送了多路流，如何估计每一路的带宽情况跟踪代码 目的是 当有多个观看 和 发送 的时候， 发送端如何调整带宽void ProcessThreadImpl::Process()
webrtc音频QOS方法四（音频接收端NACK流程实现）
CrystalShaw的博客
03-02 1014
一、概述 发送端的音视频NACK实现没有差异，可以公用一套rtp_packet_history代码，但是在接收端，音视频NACK实现细节是不一样的。 视频接收端NACK实现函数是NackModule2，音频接收端NACK实现函数是NackTracker。 音视频NACK实现差异主要有两点： 视频NACK满足一定条件会进行IDR帧请求：视频模块会配置nack_list的最大长度为kMaxNackPackets，即本次发送的nack包至多可以对kMaxNackPackets个丢失的包进行重传请求。如果丢
WebRTC基于TransportCC和Trendline Filter的发送端码率估计(Sendside-BWE)
老衲不出家
08-29 2284
1引言 众所周知，WebRTC的拥塞控制和码率估计算法采用GCC算法[1]。该算法充分考虑了网络丢包和网络延迟对码率估计的不同影响，分别基于丢包率和网络延迟进行码率估计，最后综合这另种码率得出最优值。在算法实现上，基于丢包率的码率估计在发送端进行，基于网络延迟的码率估计在接收端进行。最后在发送端计算出最优值，作用于Codec和PacedSender模块。GCC算法能够较好地基于网络实时状况估计网...
webrtc视频码率计算
qq_37051858的博客
12-18 1880
前言 webrtc码率相关介绍 研究了好久的webrtc，一直想要自己计算webrtc视频的码率，但是一直没有找到具体的公式或者算法，困扰了很久，今天找到了计算方法，在这里记录一下。 提示：以下是本篇文章正文内容，下面案例可供参考 一、webrtc码率计算？ BPP指数：每像素位数（BPP）是应用于视频文件中每个像素的平均数据量。通过将数据速率（kbps）除以视频的每秒像素数（像素宽度乘以高度像素乘以每秒帧数）来计算： BPP = 数据速率/（分辨率*每秒帧数） BPP通常在0.05到0...
WEBRTC浅析（九）带宽估计算法之BBR
muwesky的专栏
05-06 2798
带宽估计算法之BBR BBR带宽估计 （Bottleneck Bandwidth and Round-trip propagation time） 参考文档：https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control 参考文档：https://www.ietf.org/proceedings/98/slides/slides-98-iccrg-an-update-on-bbr-congestion-con
第86篇 webrtc一对一学生端研究（一）
二刀流的博客
11-02 897
关键词：老师新建白板时学生端图片同步, 老师切换白板时学生端图片同步 一、webrtc学生端 1.1 学生端图片同步-----老师新建白板时  思路：昨天整了一天，终于想出思路了，如下：  老师端点新建白板时，学生端同时也触发新建白板的按钮，同时保存一张；老师端保存的是老师端的页面，学生端保存的是学生端的页面，因为学生端的页面是老师端同步过去的，页面是相同的。 1）学生端新建一个按钮
webrtc中rtcp反馈与码率控制模块分析
MeRcy_PM的博客
05-09 5380
webrtc中rtcp反馈与码率控制模块分析
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

简简单单lym

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

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

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

打赏作者

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

抵扣说明：

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

余额充值