【REMB 】翻译：草案remb-03

已于 2024-01-16 16:27:08 修改
阅读量409 收藏
点赞数
分类专栏： 传输探索实践 文章标签： p2p
于 2024-01-16 15:11:45 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/commshare/article/details/135623940
版权
REMB（Receiver Estimated Max Bitrate）是一种RTCP反馈消息，用于通知发送方RTP会话的总估计可用带宽。它包含在PSFB（Payload-specific Feedback message）中，PT类型为206，FMT类型为15。消息格式包括通用RTCP头、REMB标识、SSRC信息和带宽估计细节。REMB在带宽估计和P2P通信中起到关键作用。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

REMB

RTCP message for Receiver Estimated Maximum Bitrate

draft-alvestrand-rmcat-remb-03

在这里插入图片描述

对一个session的总带宽估计的RTCP消息定义

  • This documen
了解本专栏 订阅专栏 解锁全文
REMB 拥塞控制
lcalqf的专栏
05-19 1470
REMB 协议介绍 REMB (Receiver Estimated Maximum Bitrate) 接收端最大码率估计。 REMB一直是一个草案，并没有定义到标准rfc文档中，虽然主流的webrtc开源服务器，如：mediasoup、licode都支持REMB方式进行拥塞控制，但是会逐步放弃支持，未来会在发送到进行码率估计，即通过transport-cc的方式。 由于目前很多服务器还支持REMB方式，所以本篇文章打算介绍一下实现过程。 协议格式 文档：https://datatracker.ie
【GCC】2015: draft-alvestrand-rmcat-congestion-03 机器翻译
突围
12-16 297
2015
WebRTC GCC 拥塞控制算法（REMB-GCC）
椛茶的博客
11-19 4108
在网络传输中，所有应用程序都需要拥塞控制以避免网络出现拥塞的情况，对于音视频传输也是如此，假设发送方以某个码率值发送数据，但是网络出现拥塞，此时发送方应该降低发送码率，当网络拥塞情况好转，发送方又可以提升发送码率。GCC 算法是出自 Google 的一种结合延时梯度和丢包率的拥塞控制算法，WebRTC 默认使用该算法。
WebRTC REMB算法
rjc_lihui的专栏
11-08 758
定义：REMB是一种RTCP（Real-time Transport Control Protocol）反馈消息，作为接收方，它告诉发送方可以接收的带宽是多少。这是一种简单的拥塞控制方法，当接收方无法接收更多数据时，会通知发送方降低发送速度。原理：REMB基于接收端对视频数据的缓存情况和网络状况等信息，动态地估计可用的带宽，并向发送端发送估计值。发送端可以根据该估计值适当地调整视频的码率和分辨率，以达到最佳的视听体验。
WebRTC REMB 算法
hyl999的专栏
10-16 725
它基于接收端对视频缓存情况和网络状况的监测，动态地估计可用的带宽，并向发送端发送估计值，使得发送端可以根据估计值适当地调整视频的码率和分辨率。在实时通信中，网络带宽的变化经常会影响视频的质量和流畅度。发送端根据估计值调整码率和分辨率：发送端会根据接收端发来的带宽估计值，适当地调整视频的码率和分辨率，以适应当前的网络带宽。发送端发送带宽估计值：当缓存情况较好时，接收端会向发送端发送一个带宽估计值，告诉发送端当前的可用带宽。接收端监测缓存：接收端会定期监测自己的视频缓存情况，包括缓存的大小、缓存时间等指标。
REMB-接收端最大接收码率评估
luyumiao1990的专栏
07-14 608
发送者不知道接收方的带宽情况，它需要有一个机制由接收方告诉它有多少带宽可供传输, 这样发送方可以根据这个估计的带宽来调整分辨率(90p, 180p, 360p, 720p等)和帧率(每秒24, 30, 40, 60帧等)abs_send_time 是一个以秒为单位的时间戳，总共 3 个字节(24 bit) , 格式为 6.18 (小数位固定为18位), 每 64s 会溢出环绕，分辨率为 3.8us。再结合接收端的接收的bitrate，来评估出接收的带宽。RTP sequence number 计算丢包。
【rfc5285 】RTP Header 扩展
突围
05-26 579
参考 WebRTC RTP Header Extension 分析 mediasoup使用 rfc5285 。 说明 其中，frameMarking07 好像已经被RFC删除了。 uint8_t frameMarking07{ 0u }; // NOTE: Remove once RFC. mediasoup 实现 E:\ADDEV\RTCTRANS\36tTRANS\36trans_mediasoup\tomkwok-mediasoup-cpp\worker\include\RT..
【gcc】RtpTransportControllerSend学习笔记 3：gcc 算法
突围
10-07 1400
gcc
【WebRTC】QoS 拥塞控制 GCC 理论 Sender Side BWE 或 REMB
V的博客
12-04 1074
Sender Side Bandwidth Estimation 发送方带宽预估。Sender Side BWE 是新方案，利用的是 RTCP 中的 TransportCC 协议。Receiver Estimated Maximum Bitrate 接收端预估最大码率。REMB 是旧方案，利用的是 RTCP 中的 REMB 协议。WebRTC 中的拥塞控制算法有三种：GCC、BBR、PCC。GCC 是 WebRTC 的默认算法，GCC 包含基于 丢包 和 延迟 两种情况的算法。以下所有内容都是 GCC 中的
【网络通信 -- 直播】网络通信协议简介 -- RTCP 协议的 WebRTC 扩展
CopperSun 技术博客
07-26 1096
【网络通信 -- 直播】网络通信协议简介 -- RTCP 协议的 WebRTC 扩展 参考致谢 本博客为博主的学习实践总结，并参考了众多博主的博文，在此表示感谢，博主若有不足之处，请批评指正。 【1】WebRTC之RTCP ...
接收方带宽估计的RTCP消息 REMB
温故而知新
01-05 1900
1) What Receiver Estimated Max Bitrate (REMB) 提出了提出了一种RTCP消息，供在实验中使用, 它为基于RTP的媒体流部署了拥塞控制算法。 它还描述了一个绝对值时间戳选项，用于带宽估计。该反馈消息用于通知一个在同一RTP会话上有多个媒体流的发送方, 通知它在该RTP会话的接收方路径上的总的估计可用比特率。 在用于反馈消息的公共数据包头中(如[RFC458...
webrtc研究-remb协议分析
liuhongxian的专栏
12-21 4611
分析入口 webrtc/ideo/vie_remb.ccvoid VieRemb::OnReceiveBitrateChanged(const std::vector<uint32_t>& ssrcs, uint32_t bitrate) { RtpRtcp* sender = nullptr; { rtc::CritScope
【音视频第1天】常见的术语含义等
Magic_o的博客
03-27 1220
在WebRTC中，ARQ（Automatic Repeat Request）和Nack（Negative Acknowledge）也被用于数据传输过程中检测和纠正错误。发送方发送数据包，接收方收到并检验数据包，若数据包出现错误，则向发送方发送Nack请求重传该数据包。发送方收到Nack后，会重新发送该数据包，直到接收方接收到正确的数据包为止。ARQ和Nack解决的问题也是数据传输过程中的错误。在WebRTC中，数据传输过程中数据包可能会出现错误，比如数据包被丢失、数据包内容损坏等。
WebRTC 拥塞控制分析
aggresss
09-01 2153
参考文档 小议WebRTC拥塞控制算法：GCC介绍 https://www.dazhuanlan.com/2019/08/18/5d58c6377debc/
webrtc发送端带宽预测
occupy8的专栏
10-27 2724
当接收侧感知到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
WebRTC[5]-WebRTC拥塞控制之REMB and GCC
liuzhen007的专栏
07-10 2183
前言 WebRTC在处理网络拥塞问题时一般有网络拥塞（congestion）是指在分组交换网络中传送分组的数目太多时，由于存储转发节点的资源有限而造成网络传输性能下降的情况。当网络发生拥塞时，一般会出现数据丢失，时延增加，吞吐量下降，严重时甚至会导致“拥塞崩溃”（congestion collapse）。 ......
RDO率失真优化
专注HEVC，H.264，ffmpeg
08-20 6332
原帖地址：http://blog.sina.com.cn/s/blog_4de7908201000aqf.html Rate-Distortion Optimization 是视频编码中最优选择mode的一种方法。比如h.264里好多mode 8x8 16x16 I4x4 I16 在给定的条件下，哪个是最好的? Distortion 是指选用candidate mode产生的失真，ra
码率自适应---RTCP goog-remb
qq_41681715的博客
11-20 1927
做音视频的同学应该都知道，基于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
webrtc技术名词和关键技术要点:SVC,REMB,SVC...
睏哥的webrtc和janus视频会议技术专栏
02-01 1825
SDP (Session Description Protocol)会话描述协议SVC  (Scalable Video Coding）可伸缩视频编码技术 ARQ (Automatic Repeat-reQuest) 自动重传请求 FEC (Forward Error Correction) 前向纠错 RTX：发送端在新的SSRC上发送重传包或者冗余包。 PLC（Packet Loss Con...
webrtc tcc和remb区别
最新发布
02-27
好的，我现在需要解释WebRTC中的TCC和REMB这两种拥塞控制算法的区别。首先，我得回忆一下这两个术语的基本概念，然后找出它们的异同点。 我记得WebRTC使用拥塞控制来调整视频流的发送速率，避免网络过载。TCC和REMB...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

等风来不如迎风去

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

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

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

打赏作者

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

抵扣说明：

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

余额充值