【REMB 】翻译：草案remb-03

已于 2024-01-16 16:27:08 修改
阅读量421 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 传输探索实践 文章标签： 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 document
了解本专栏 订阅专栏 解锁全文
REMB 拥塞控制
lcalqf的专栏
05-19 1514
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 330
2015
WebRTC GCC 拥塞控制算法（REMB-GCC）
椛茶的博客
11-19 4414
在网络传输中，所有应用程序都需要拥塞控制以避免网络出现拥塞的情况，对于音视频传输也是如此，假设发送方以某个码率值发送数据，但是网络出现拥塞，此时发送方应该降低发送码率，当网络拥塞情况好转，发送方又可以提升发送码率。GCC 算法是出自 Google 的一种结合延时梯度和丢包率的拥塞控制算法，WebRTC 默认使用该算法。
WebRTC REMB算法
rjc_lihui的专栏
11-08 814
定义：REMB是一种RTCP（Real-time Transport Control Protocol）反馈消息，作为接收方，它告诉发送方可以接收的带宽是多少。这是一种简单的拥塞控制方法，当接收方无法接收更多数据时，会通知发送方降低发送速度。原理：REMB基于接收端对视频数据的缓存情况和网络状况等信息，动态地估计可用的带宽，并向发送端发送估计值。发送端可以根据该估计值适当地调整视频的码率和分辨率，以达到最佳的视听体验。
WebRTC REMB 算法
hyl999的专栏
10-16 765
它基于接收端对视频缓存情况和网络状况的监测，动态地估计可用的带宽，并向发送端发送估计值，使得发送端可以根据估计值适当地调整视频的码率和分辨率。在实时通信中，网络带宽的变化经常会影响视频的质量和流畅度。发送端根据估计值调整码率和分辨率：发送端会根据接收端发来的带宽估计值，适当地调整视频的码率和分辨率，以适应当前的网络带宽。发送端发送带宽估计值：当缓存情况较好时，接收端会向发送端发送一个带宽估计值，告诉发送端当前的可用带宽。接收端监测缓存：接收端会定期监测自己的视频缓存情况，包括缓存的大小、缓存时间等指标。
REMB-接收端最大接收码率评估
luyumiao1990的专栏
07-14 651
发送者不知道接收方的带宽情况，它需要有一个机制由接收方告诉它有多少带宽可供传输, 这样发送方可以根据这个估计的带宽来调整分辨率(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 605
参考 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 1433
gcc
【WebRTC】QoS 拥塞控制 GCC 理论 Sender Side BWE 或 REMB
V的博客
12-04 1104
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 1134
【网络通信 -- 直播】网络通信协议简介 -- RTCP 协议的 WebRTC 扩展 参考致谢 本博客为博主的学习实践总结，并参考了众多博主的博文，在此表示感谢，博主若有不足之处，请批评指正。 【1】WebRTC之RTCP ...
接收方带宽估计的RTCP消息 REMB
温故而知新
01-05 1948
1) What Receiver Estimated Max Bitrate (REMB) 提出了提出了一种RTCP消息，供在实验中使用, 它为基于RTP的媒体流部署了拥塞控制算法。 它还描述了一个绝对值时间戳选项，用于带宽估计。该反馈消息用于通知一个在同一RTP会话上有多个媒体流的发送方, 通知它在该RTP会话的接收方路径上的总的估计可用比特率。 在用于反馈消息的公共数据包头中(如[RFC458...
webrtc研究-remb协议分析
liuhongxian的专栏
12-21 4650
分析入口 webrtc/ideo/vie_remb.ccvoid VieRemb::OnReceiveBitrateChanged(const std::vector<uint32_t>& ssrcs, uint32_t bitrate) { RtpRtcp* sender = nullptr; { rtc::CritScope
【音视频】remb && twcc原理
dualvencsdn的博客
12-22 1923
TWCC全称是Transport wide Congestion Control，是webrtc的最新的拥塞控制算法。其原理是在接收端保存数据包状态，然后构造RTCP包反馈给发送端，反馈信息包括包到达时间、丢包状态等；在发送端进行带宽估计，进行拥塞控制。发送方带宽估计有什么好处？谷歌解释的理论是，通过这种方式，所有的决策逻辑都在一个地方（发送方），因此可以轻松测试新算法，因为你不依赖两个端点。老实说，考虑到浏览器自动更新，我不认为这一点有什么大的优势，但它肯定更干净，即使它在带宽使用方面更昂贵。
【音视频第1天】常见的术语含义等
Magic_o的博客
03-27 1258
在WebRTC中，ARQ（Automatic Repeat Request）和Nack（Negative Acknowledge）也被用于数据传输过程中检测和纠正错误。发送方发送数据包，接收方收到并检验数据包，若数据包出现错误，则向发送方发送Nack请求重传该数据包。发送方收到Nack后，会重新发送该数据包，直到接收方接收到正确的数据包为止。ARQ和Nack解决的问题也是数据传输过程中的错误。在WebRTC中，数据传输过程中数据包可能会出现错误，比如数据包被丢失、数据包内容损坏等。
WebRTC 拥塞控制分析
aggresss
09-01 2195
参考文档 小议WebRTC拥塞控制算法：GCC介绍 https://www.dazhuanlan.com/2019/08/18/5d58c6377debc/
details about rtp and rtcp
mahout_xb的专栏
06-08 2778
准备分析webrtc的rtp_rtcp模块的源代码（webrtc_root/src/modules/rtp_rtcp), 工欲善其事，必先利其器， 先对rtp&rtcp的相关知识做一个总结： RTP是基于UDP而不是TCP 原因： 1. tcp内置的重传机制不适合实时传输 2. tcp是点到点的协议，而不直接支持多播机制 3. UDP和TCP的包中都没有时间戳，因此需要
码率自适应---RTCP goog-remb
qq_41681715的博客
11-20 1951
做音视频的同学应该都知道，基于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 QoS方法（汇总篇）
热门推荐
CrystalShaw的博客
05-24 2万+
目前总结出webrtc用于提升QOS的方法有： NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR（动态帧率调整策略）。 这几种方法在webrtc架构分布如下： 具体实现原理如下： 一、NACK 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收......
webrtc技术名词和关键技术要点:SVC,REMB,SVC...
睏哥的webrtc和janus视频会议技术专栏
02-01 1843
SDP (Session Description Protocol)会话描述协议SVC  (Scalable Video Coding）可伸缩视频编码技术 ARQ (Automatic Repeat-reQuest) 自动重传请求 FEC (Forward Error Correction) 前向纠错 RTX：发送端在新的SSRC上发送重传包或者冗余包。 PLC（Packet Loss Con...
remb是什么
最新发布
07-16
### REMB 的含义与技术背景 REMB（Receiver Estimated Maximum Bitrate）是一种用于实时通信中的带宽估计算法，尤其在 WebRTC 中广泛应用。其核心功能是接收端根据当前网络状况和缓冲区状态，估算出能够稳定接收的最大带宽，并将这一估计值反馈给发送端，从而指导发送端调整视频的码率[^2]。 #### 定义与原理 REMB 是一种 RTCP（Real-time Transport Control Protocol）反馈消息，由接收端生成并发送给发送端。它基于接收端对视频数据缓冲情况、网络延迟、丢包率等信息的监测，动态地估算可用带宽，并通过 RTCP 协议将该带宽估计值传递给发送端。发送端接收到 REMB 消息后，会根据该估计值调整视频的编码码率和分辨率，以适应当前的网络条件[^2]。 #### 实现方式 - **接收端监测缓存**：接收端定期检查其视频缓冲区的状态，包括缓冲区大小、延迟等指标。 - **发送 REMB 消息**：当检测到网络状况变化或缓冲压力增大时，接收端生成 REMB 消息并通过 RTCP 协议发送给发送端。 - **发送端调整码率**：发送端接收到 REMB 后，依据反馈的带宽估计值调整视频的码率和分辨率，确保传输流畅[^2]。 #### REMB 在 WebRTC 中的作用 - **优化视频传输**：通过动态调整码率，REMB 有助于在不同网络条件下保持最佳的视听体验。 - **避免网络拥塞**：当网络出现拥堵时，REMB 可促使发送端降低码率，从而缓解网络压力。 - **提高资源利用率**：合理利用带宽资源，提升视频传输效率。 #### REMB 与其他拥塞控制算法的关系 - **GCC 算法**：WebRTC 默认的拥塞控制算法 GCC 结合了延迟梯度和丢包率进行带宽估算。REMB 可作为 GCC 的补充，提供接收端的带宽估计值。 - **Sender Side BWE**：这是一种较新的方案，利用 RTCP 中的 TransportCC 协议进行带宽预估；而 REMB 使用的是 RTCP 中的 REMB 协议，可视为旧方案。在 REMB-GCC 模型中，接收端负责基于延迟梯度进行带宽估算，并通过 REMB 反馈给发送端；发送端则基于丢包率进行估算，并选择两者中较小的带宽值作为最终的发送码率[^2]。 #### REMB 在媒体转发中的应用 在 Kurento Media Server（KMS）中，REMB 被用于连接发送端和多个接收端的场景。KMS 会收集所有接收端的 REMB 值，并将其中最小的值反馈给发送端，确保发送端选择一个能够满足所有接收端网络条件的码率[^5]。 #### 数据格式说明 在 RTCP 协议中，REMB 消息的数据结构包含以下关键字段： - **SSRC of packet sender**：表示发送此 REMB 消息的源标识符。 - **SSRC of media source**：始终为 0，表明这是上行链路的 REMB 反馈[^1]。 - **Unique identifier (32 bits)**：固定为 "REMB" 四个 ASCII 字符。 - **Bitrate estimate**：4 字节的比特率估计值，单位为 bps[^3]。 ```c struct RembMessage { uint8_t ssrc_count; // SSRC count field uint8_t unique_id[4]; // Always 'R', 'E', 'M', 'B' uint32_t bitrate_estimate; // Estimated maximum bitrate in bps }; ``` ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

等风来不如迎风去

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

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

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

打赏作者

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

抵扣说明：

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

余额充值