REMB 拥塞控制

最新推荐文章于 2023-07-14 14:30:40 发布
最新推荐文章于 2023-07-14 14:30:40 发布
阅读量1.2k 收藏 1
点赞数
分类专栏： mediasoup源码分析 文章标签： REMB AbsSendTime absolute time feedback 拥塞控制
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lcalqf/article/details/117040918
版权

目录

 

REMB 协议介绍

absolute send time

REMB 协议介绍

REMB (Receiver Estimated Maximum Bitrate) 接收端最大码率估计。
REMB一直是一个草案，并没有定义到标准rfc文档中，虽然主流的webrtc开源服务器，如：mediasoup、licode都支持REMB方式进行拥塞控制，但是会逐步放弃支持，未来会在发送到进行码率估计，即通过transport-cc的方式。

由于目前很多服务器还支持REMB方式，所以本篇文章打算介绍一下实现过程。

协议格式

文档：https://datatracker.ietf.org/doc/html/draft-alvestrand-rmcat-remb-03
REMB也是RTCP反馈报文的一种，具体格式如下：

    0                   1                   2                   3
 
了解本专栏 订阅专栏 解锁全文 超级会员免费看
致一
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
订阅专栏
苏宁易购2-(remb+js布局)
03-08
rem布局练习
【WebRTC】QoS 拥塞控制 GCC 理论 Sender Side BWE 或 REMB
V的博客
12-04 888
Sender Side Bandwidth Estimation 发送方带宽预估。Sender Side BWE 是新方案，利用的是 RTCP 中的 TransportCC 协议。Receiver Estimated Maximum Bitrate 接收端预估最大码率。REMB 是旧方案，利用的是 RTCP 中的 REMB 协议。WebRTC 中的拥塞控制算法有三种：GCC、BBR、PCC。GCC 是 WebRTC 的默认算法，GCC 包含基于 丢包 和 延迟 两种情况的算法。以下所有内容都是 GCC 中的
REMB-接收端最大接收码率评估
luyumiao1990的专栏
07-14 376
发送者不知道接收方的带宽情况，它需要有一个机制由接收方告诉它有多少带宽可供传输, 这样发送方可以根据这个估计的带宽来调整分辨率(90p, 180p, 360p, 720p等)和帧率(每秒24, 30, 40, 60帧等)abs_send_time 是一个以秒为单位的时间戳，总共 3 个字节(24 bit) , 格式为 6.18 (小数位固定为18位), 每 64s 会溢出环绕，分辨率为 3.8us。再结合接收端的接收的bitrate，来评估出接收的带宽。RTP sequence number 计算丢包。
WebRTC GCC 拥塞控制算法（REMB-GCC）
椛茶的博客
11-19 2556
在网络传输中，所有应用程序都需要拥塞控制以避免网络出现拥塞的情况，对于音视频传输也是如此，假设发送方以某个码率值发送数据，但是网络出现拥塞，此时发送方应该降低发送码率，当网络拥塞情况好转，发送方又可以提升发送码率。GCC 算法是出自 Google 的一种结合延时梯度和丢包率的拥塞控制算法，WebRTC 默认使用该算法。
接收方带宽估计的RTCP消息 REMB
温故而知新
01-05 1700
1) What Receiver Estimated Max Bitrate (REMB) 提出了提出了一种RTCP消息，供在实验中使用, 它为基于RTP的媒体流部署了拥塞控制算法。 它还描述了一个绝对值时间戳选项，用于带宽估计。该反馈消息用于通知一个在同一RTP会话上有多个媒体流的发送方, 通知它在该RTP会话的接收方路径上的总的估计可用比特率。 在用于反馈消息的公共数据包头中(如[RFC458...
webrtc研究-remb协议分析
liuhongxian的专栏
12-21 4440
分析入口 webrtc/ideo/vie_remb.ccvoid VieRemb::OnReceiveBitrateChanged(const std::vector<uint32_t>& ssrcs, uint32_t bitrate) { RtpRtcp* sender = nullptr; { rtc::CritScope
draft-alvestrand-rmcat-remb-03.txt
11-22
google gcc 标准
Python库 | TWCC_CLI-0.5.3a3-py2.py3-none-any.whl
03-25
python库，解压后可用。 资源全名：TWCC_CLI-0.5.3a3-py2.py3-none-any.whl
ion-sfu:Pure Go WebRTC SFU
03-11
拥塞控制（TWCC，REMB，RR / SR） 统一计划语义 发布/订阅对等连接（ O(n)端口使用情况） 音频电平指示（RFC6464）。 “ X在说话” 快速开始 运行回声测试示例 docker-compose -f examples/echotest/docker-...
WebRTC[5]-WebRTC拥塞控制之REMB and GCC
liuzhen007的专栏
07-10 2051
前言 WebRTC在处理网络拥塞问题时一般有网络拥塞（congestion）是指在分组交换网络中传送分组的数目太多时，由于存储转发节点的资源有限而造成网络传输性能下降的情况。当网络发生拥塞时，一般会出现数据丢失，时延增加，吞吐量下降，严重时甚至会导致“拥塞崩溃”（congestion collapse）。 ......
码率自适应---RTCP goog-remb
qq_41681715的博客
11-20 1759
做音视频的同学应该都知道，基于RTP/RTCP传输流媒体，难点在于怎么把Qos做好。比较常用的基于RTCP反馈机制的Qos策略有NACK、PLI和FIR，再网络比较拥塞的情况下，使用NACK、PLI或FIR机制，可能不会改善网络拥塞情况，反而可能会增加网络拥塞的程度，这时根据网络带宽的具体情况，适当调整发送码流可能会达到更好的效果，这里我们主要说下RTCP的REMB，根据REMB文档的规范https://tools.ietf.org/pdf/draft-alvestrand-rmcat-remb-03.pd
kurento之，支持remb算法
liuweihui521的专栏
07-23 737
Congestion Control (REMB)¶ Kurento implements the Google Congestion Control algorithm, so it is able to generate and parse both abs-send-time RTP headers and REMB RTCP messages. It is enabled by by ...
WebRTC 拥塞控制分析
aggresss
09-01 1996
参考文档 小议WebRTC拥塞控制算法：GCC介绍 https://www.dazhuanlan.com/2019/08/18/5d58c6377debc/
WebRTC QoS方法（汇总篇）
热门推荐
CrystalShaw的博客
05-24 1万+
目前总结出webrtc用于提升QOS的方法有： NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR（动态帧率调整策略）。 这几种方法在webrtc架构分布如下： 具体实现原理如下： 一、NACK 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收......
webrtc发送端带宽预测
occupy8的专栏
10-27 2641
当接收侧感知到2-10%丢包率，发送端的预测值不变。当实际丢包率超过预测值10%时，新的预测值可更新为As_hat(i)= As_hat(i-1)(1-0.5p)，其中p为丢包率。当实际丢包率小于2%时预测时可更新为As_hat(i)= 1.08(As_hat(i-1))+0.5+1000，其中p为丢包率。其中p是rtcp里的丢包率 void SendSideBandwidthEstimatio
details about rtp and rtcp
mahout_xb的专栏
06-08 2699
准备分析webrtc的rtp_rtcp模块的源代码（webrtc_root/src/modules/rtp_rtcp), 工欲善其事，必先利其器， 先对rtp&rtcp的相关知识做一个总结： RTP是基于UDP而不是TCP 原因： 1. tcp内置的重传机制不适合实时传输 2. tcp是点到点的协议，而不直接支持多播机制 3. UDP和TCP的包中都没有时间戳，因此需要
WebRTC之带宽控制部分学习(1) ------基本demo的介绍
DreamMaker
06-06 7079
WebRTC的代码真是非常之大啊，下载以及编译了我好几天才搞完。。。。。 可以看到WebRTCd代码分成了4个部分，目前为止只看了talk里的一些东西。       1、 talk中的项目文件大多数都是以libjingle开头的，可以看出libjingle是WebRTC中非常核心的一个东西啦。        libjingle中开辟了两个通道，分别为会话通道和数据通道，一个用来会话建立管理等
WebRTC带宽估计
fishmai的专栏
04-09 9283
带宽估计可能是WebRTC视频引擎中最重要的一部分了。带宽估计（BWE）模块的任务是决定你可以发送多大的视频流且不会造成网络拥塞，以此来保证不会降低视频质量。          在以前的带宽估计算法还是十分基础的，大体上是基于丢包而设计的。通常我们在开始慢慢的增加视频的比特率，直到我们检测到丢包为止。为了检测丢包，你使用标准的RTCP反馈，其中接收端使用RTCP接收端报告（RR）信息来周期性
webrtc中的网络反馈与控制
好久都没有更新博客喽，工作原因只能总结在内部机上：-（
12-11 5700
转自编风网 http://befo.io/4206.html一、引言站在风口上，猪都能飞起来。雷布斯的这句名言，已经被大家传的家喻户晓了，说起当下站在风口上的猪，除了丁老板的未央猪，这头实实在在的猪，视频直播应该可以算一个。今年各种直播平台，各个轮次的融资消息应接不暇。对于互联网技术从业者来说，RTC(Real Time Communication，实时通信)这个站着视频直播背后的技术也重新开始变
webrtc拥塞控制
最新发布
09-14
常见的拥塞控制算法包括REMB（Receiver Estimated Max Bitrate）和BWE（Bandwidth Estimation）等。 4. FEC（Forward Error Correction）：为了提高数据的可靠性，WebRTC还使用前向纠错技术，即在发送端添加冗余...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

致一

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

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

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

打赏作者

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

抵扣说明：

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

余额充值