WEBRTC 实时视频传输中的RTCP协议码率控制报文

最新推荐文章于 2025-06-26 22:35:25 发布
最新推荐文章于 2025-06-26 22:35:25 发布
阅读量2.8k 收藏 6
点赞数
分类专栏： webrtc 文章标签： webrtc rtcp
本文介绍了视频传输中常用的RTCP包类型，包括关键帧请求、重传请求和码率控制等，重点阐述了它们在视频会议场景中的应用。

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

流媒体传输中常用的RTCP包主要有SR／RR／SDES／BYE／APP／XR，主要由RFC 3611和RFC 3550定义。

而WEBRTC视频中常用的RTCP包比语音要多很多，语音的RTCP主要用于状态传递，统计数据。而视频中的RTCP更多赋予了控制功能，比如关键帧请求，码率控制等等。


本文不介绍语音中的RTCP，只介绍视频中的RTCP包。

这些报文遵守RFC4585和RFC5104协议。


第一类：关键帧请求

主要包括SLI／PLI／FIR，作用是在关键帧丢失无法解码时，请求发送方重新生成并发送一个关键帧。

这本质是一种重传，但是跟传输层的重传的区别是，它重传是最新生成的帧。

PLI 是Picture Loss Indication，SLI 是Slice Loss Indication。

发送方接收到接收方反馈的PLI或SLI需要重新让编码器生成关键帧并发送给接收端。


FIR 是Full Intra Request，这里面Intra的含义可能很多人不知道。

Intra的含义是图像内编码，不需要其他图像信息即可解码；Inter指图像间编码，解码需要参考帧。

故Intra Frame其实就是指I帧，Inter Frame指P帧或B帧。


那么为什么在PLI和SLI之外还需要一个FIR呢？

原因是使用场景不同，FIR更多是在一个中心化的Video Conference中，新的参与者加入，就需要发送一个FIR，其他的参与者给他发送一个关键帧这样才能解码，

而PLI和SLI的含义更多是在发生丢包或解码错误时使用。


第二类：重传请求

主要包括RTX／NACK／RPSI

这个重传跟关键帧请求的区别是它可以要求任意帧进行重传


第三类：码率控制

主要包括REMB／TMMBR／TMMBN

TMMBR是Temporal Max Media Bitrate Request，表示临时最大码率请求。表明接收端当前带宽受限，告诉发送端控制码率。

REMB是ReceiverEstimated Max Bitrate，接收端估计的最大码率。

TMMBN是Temporal Max Media Bitrate Notification


WebRTC[54] - WebRTC之RTCP详解
liuzhen007的专栏
02-08 548
在WebRTC中，流媒体协议使用的RTP/RTCP协议，其中，RTP负责流媒体数据传输，RTCP负责传输的质量控制。RTCP的作用还是非常重要，它可以实现发送数据/接收数据的反馈、丢包重传、关键帧请求、⽹络指标RTT、丢包率、抖动的计算及反馈，拥塞控制相关的带宽反馈，以及⽤户体验相关的⾳视频同步等。文本将重点介绍RTCP相关的内容和基础知识。
webrtc笔记-媒体部分（RTP/RTCP）
weixin_40578430的博客
12-01 465
webrtc媒体部分主要研究媒体数据的处理和传输，这也是webrtc的核心，本系列重点研究传输，包括传输过程中丢包、抖动、拥塞问题，涉及到的协议就是流传输协议RTP/RTCP。 RTP/RTCP协议栈位于webrtc-master\webrtc-master\modules\rtp_rtcp目录，主要负责将帧打包成RTP报文，RTP报文解包成帧，每10ms的PCM ...
Webrtc(7) 实时视频传输中的RTCP协议
热门推荐
wangruihit的专栏
07-24 1万+
我以前主要研究语音，语音中常用的RTCP包主要有SR／RR／SDES／BYE／APP／XR，主要由RFC 3611和RFC 3550定义。 而视频中常用的RTCP包比语音要多很多，语音的RTCP主要用于状态传递，统计数据。而视频中的RTCP更多赋予了控制功能，比如关键帧请求，码率控制等等。 本文不介绍语音中的RTCP，只介绍视频中的RTCP包。 这些报文遵守RFC4585和RFC51
Android IOS WebRTC 音视频开发总结（八十六）-- WebRTC中RTP/RTCP协议实现分析
weixin_33860722的博客
10-21 582
  本文主要介绍WebRTC中的RTP/RTCP协议，作者：weizhenwei ，文章最早发表在编风网，微信ID：befoio   支持原创，转载必须注明出处，欢迎关注我的微信公众号blacker（微信ID：blackerteam 或 webrtcorgcn）。   一 前言   RTP/RTCP协议是流媒体通信的基石。RTP协议定义流媒体数据在互联网上传输的数据包格式，而RTCP...
WebRTC（十）：RTP和SRTP
www_dong的博客
06-26 1075
RTP 用于（如音频、视频），它不提供可靠传输，而是关注低延迟、高实时性。
webrtc中rtcp反馈与码率控制模块分析
MeRcy_PM的博客
05-09 5495
webrtc中rtcp反馈与码率控制模块分析
WEBRTC RTP/RTCP协议族
伍意的博客
02-22 4758
RF3550定义实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对流媒体传输的基础协议，该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输，并不能提供可靠传输、流量控制和拥塞控制等服务质量保证，这需要RTCP协议提供这些服务。 RTCP协议负责流媒体的传输质量保证，提供流量控制和拥塞控制等服务。在RTP会话期间，各参与者周期性彼此发送
rtcp码率控制反馈流程
奔向火星的博客
06-06 1611
前面的分析我们知道，RR报文中主要包含丢帧率fraction loss, 通过它估算出目标发送码率，然后更新编码器和PacedSender, 本节记录一下它们的类图，以及总流程： 类图： 流程图：
WebRTC中RTP/RTCP协议实现分析
yinshipin007的博客
10-10 781
若是，则首先从RTPSender::GetDataCounters()获取RTP发送统计信息，然后调用RTCPSender::SendRTCP()，接着是SendCompoundRTCP()发送RTCP组合报文。在接收端，RTP报文的接收和解包操作主要在Worker线程中执行，RTP报文从Network线程拿到后，进入Worker线程，经过解包操作，进入VCM模块，由Decode线程进行解码，最终由Render线程进行渲染。需要注意的是，在RtpSender中进行Rtp发送后，会统计RTP报文相关信息。
rtcp webrtc 接收_WebRTC代码走读（十）：rtp_rtcp模块分析，webrtcrtp_rtcp
weixin_33330762的博客
12-29 215
转自：http://www.bkjia.com/Androidjc/1020017.html1. 对外提供的主要流程接口收包的调用接口RtpReceiverImpl::IncomingRtpPacket发包的调用接口ModuleRtpRtcpImpl::SendOutgoingData收包处理之后的回调接口RtpData2. 主要处理类ModuleRtpRtcpImpl， 控制模块，是个Modul...
WebRTC RTCP XR
clark的专栏
04-09 2092
RTCP扩展报告(XR)用于补充RTCP 的发送方报告 (SR) 和接收方报告 (RR) 数据包的报告块中的六个统计信息。 Value Name Long Name Description Reference 1 RRT Receiver Reference Time 接收方参考时间 rfc3611#section-4.4 2 DLSR Delay since the last Sender Report 自上次发送方报告以来的延迟
WebRTC RTCP PS Feedback
clark的专栏
04-09 821
作为WebRTC RTCP消息中的一种，PS Feedback包含的内容同样也很多。 在RTCP Header中，这类消息的负载类型Payload Type=206，反馈消息类型FMT如下： FMT Name Long Name Description Reference 1 PLI Picture Loss Indication 图片丢失指示 RFC4585 2 SLI Slice Loss Indication 切片丢失指示
WebRTC中RTCP协议详解
永远积极向上、永远热泪盈眶、永远豪情满怀、永远坦坦荡荡
11-16 1200
一、RTCP协议 |Data| |RTCP Header|Data| |UDP Header|RTCP Header|Data| |IP Header|UDP Header|RTCP Header|Data| |Mac Header|IP Header|UDP Header|RTCP Header|Data|Mac Tailer| 14byte 20byte 8byte 4byte 可变长度 4
【译】WebRTC API
671coder的专栏
04-28 984
翻译自：WebRTC APIMDN web docs 互用性 WebRTC 概念及使用方法 WebRTC 接口 连接设置与管理 身份和安全 电话技术 指导 辅导材料 手册 另请参阅 WebRTC(Web Real-Time Communications) 是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Pe...
WebRTC RTP/RTCP协议分析(一)
翻肚鱼儿的博客
08-13 809
1 rtp/rtcp通道创建流程 RtpTransportInternal为webrtc 网络rtp以及rtcp传输层的接口,rtp和rtcp数据经该api层讲数据发送到PacketTransportInternal它们之间的关系如下图: RtpTranspor.png RtpTransportInternal主要供用户拿到rtp数据流后调用,而PacketTransportInternal为底层网络通信层接口 RtpTransportInternal的创建时机是在创建PeerConnection的时候通.
WebRTC的RTP、RTCP协议实现分析
yinshipin007的博客
03-02 296
若是，则首先从RTPSender::GetDataCounters()获取RTP发送统计信息，然后调用RTCPSender::SendRTCP()，接着是SendCompoundRTCP()发送RTCP组合报文。接下来每种RTCP报文都会调用各自的序列化函数，把报文序列化为网络字节流。RTCPReceiver::IncomingRtcpPacket()使用RTCPParser解析组合报文，针对每一种报文类型，调用对应的处理函数(如处理SDES的HandleSDES函数)，反序列化后拿到报文的描述结构。
html5 webrtc fir 请求关键帧_中信建投官网强调认可我们的投资理念的股民朋友请求 CTRL D 收藏、锁定本直播地址...
weixin_39914975的博客
11-04 132
本文摘要：有关中信建投官网强调认可我们的投资理念的股民朋友请求 CTRL D 收藏、锁定本直播地址的内容分享，跟踪了解如何看股票k线图，分享热点专题。欢迎来到 橘子股票直播间，本直播每日为大家更新最快、最精准、最全面的股市内容，并有潜力股分享。要想做强，要想稳定盈利，需要不断地思考和不断地成长。不要盲目跟风！注意短线原则，留强去弱！！认可我们的投资理念的...
WebRTC RTCP 分析
aggresss
08-15 2140
参考文档
在谷歌实现的WebRTC中，使用REMB来控制码率，接收端发送时需要考虑发送端的网络情况吗，比如接收端实际上网络状态良好，反而是发送端的网络条件比较差，这种情况下接收端能发现吗？
最新发布
07-04
<think>首先，用户的问题是关于WebRTC中的REMB机制：接收端使用REMB反馈码率控制时，是否能感知发送端的网络状况并做出调整。具体来说，用户问在发送端网络状况较差的情况下，接收端能否感知并调整码率反馈。 我需要参考提供的引用内容来构建回答。引用包括： -引用[1]：解释了REMB的定义、原理、实现方式，以及在WebRTC中的作用。它提到REMB是接收端基于缓存和网络状况估计带宽，并发送给发送端。-引用[2]：描述了WebRTC的发送端除了使用REMB外，还根据丢包率调整码率。伪代码显示发送端基于丢包率调整视频码率。-引用[3]：详细说明了GCC算法，包括发送端基于丢包率的码率控制和接收端基于延迟的码率控制。接收端通过RTCPREMB报文返回估计码率给发送端。 -引用[4]：给出了一个算法框架，涉及发送端处理反馈报文来计算码率调整。-引用[5]：提到发送方需要接收方告诉它带宽情况，以便调整分辨率和帧率。关键点： -REMB是接收端驱动的：接收端估计带宽并反馈给发送端。-接收端主要基于自己的网络状况（如缓存、延迟）来估计带宽，而不是发送端的网络状况。-发送端的网络状况较差（如发送端有高丢包或延迟）时，接收端可能无法直接感知，因为REMB是接收端到发送端的反馈。 -在GCC算法中，发送端有自己的机制（基于丢包率）来调整码率，而接收端基于延迟估计带宽。-引用[3]说：“发送端综合As、Ar和预配置的上下限，计算出最终的目标码率A”。其中As是基于丢包率的码率，Ar是接收端估计的码率。所以，回答用户的问题：-接收端不能直接感知发送端的网络状况。REMB机制是接收端基于自己的网络状况（接收端看到的网络状况）来估计带宽。 -如果发送端网络状况较差（如发送端有瓶颈），接收端可能看到延迟或丢包增加，从而间接感知到问题，但这不是直接感知发送端网络。-在发送端网络状况较差时，接收端可能会检测到网络拥塞（通过延迟增加），并降低REMB反馈的带宽估计。-发送端也会基于丢包率调整码率，这可以处理发送端网络问题。 现在，结构回答：1.**解释REMB机制**：简要概述REMB是什么，如何工作。 2. **回答核心问题**：接收端是否能感知发送端网络状况？不能直接感知；它是基于接收端视角。 3. **如何处理发送端网络差的情况**：接收端可能间接感知，并通过降低REMB反馈来响应。发送端有额外机制。4.**引用支持**：在回答中引用相关部分，如引用[1]、[2]、[3]。 系统级指令： -所有行内数学表达式用$...$，例如$A_s$。-独立公式用$$...$$，但这里可能不需要复杂公式。- LaTeX语法正确。-使用中文回答。-生成相关问题：在末尾添加相关问题。 -回答中引用的段落末尾添加引用标识，例如[^1]。回答结构： -清晰、逐步解决问题。 -帮助用户理解。 -保证真实可靠，基于引用。最终，回答后添加相关问题。相关问题示例： 1. REMB机制如何与GCC算法结合？2.在WebRTC中，发送端如何综合REMB反馈和自身估计？ 3.当网络不对称时（如上行带宽大，下行带宽小），REMB机制如何表现？ 基于引用生成。</think>### WebRTC中REMB机制对发送端网络状况的处理 在WebRTC中，REMB（Receiver Estimated Maximum Bitrate）机制是一种接收端驱动的带宽估计算法，用于动态调整视频传输码率。用户询问的核心问题是：**当发送端网络状况较差时，接收端能否感知并调整REMB反馈的码率？** 我将逐步解释REMB的工作原理，并基于WebRTC的实现细节回答这个问题。参考WebRTC的拥塞控制机制（如GCC算法），REMB主要依赖接收端的网络状况估计，而非直接感知发送端网络状况。以下是详细分析： #### 1. **REMB机制的基本原理** - REMB是接收端通过RTCP（Real-time Transport Control Protocol）反馈给发送端的带宽估计值，表示接收端可承受的最大码率。接收端基于以下因素动态计算带宽： - **视频缓存状态**：如缓存大小和缓存时间，反映数据包到达的平滑度。 - **网络延迟变化**：通过监测数据包到达时间差（例如，使用延时梯度）来推断网络拥塞。 - 接收端独立计算带宽估计值$A_r$（基于延迟），并通过REMB消息发送给发送端[^1][^3]。 - 发送端接收到REMB消息后，会结合自身估计（如基于丢包率的码率$A_s$）调整视频码率和分辨率，以优化传输[^1][^3]。公式表示为： $$ A = \min(A_s, A_r) $$ 其中$A$是最终目标码率，$A_s$是发送端基于丢包率计算的码率，$A_r$是接收端反馈的REMB值[^3]。 #### 2. **接收端能否感知发送端网络状况？** - **不能直接感知**：REMB机制的核心是接收端基于**自身观测的网络状况**（例如，接收端到发送端的下行链路）进行估计。接收端无法直接访问发送端的网络状态（如发送端的上行带宽瓶颈或本地拥塞），因为REMB反馈仅依赖接收端收到的数据包信息[^1][^3][^5]。 - **间接感知可能**：如果发送端网络状况较差（例如，发送端上行带宽不足或高丢包），这可能导致数据包到达接收端时出现异常： - 接收端可能检测到**延迟增加**或**丢包率升高**（因为发送端无法及时发送数据），从而推断网络拥塞。 - 在此情况下，接收端的带宽估计算法（如GCC的基于延迟部分）会降低$A_r$值，并通过REMB消息反馈较低的码率[^3]。例如，当延时梯度上升时，接收端判断网络过载，并减少$A_r$[^3]。 - 总之，REMB机制**不设计为感知发送端网络**，而是响应接收端观测到的网络变化。如果发送端网络差影响了接收端数据流，接收端会间接调整反馈；否则，REMB反馈不会主动适应发送端问题。 #### 3. **发送端网络状况较差时的处理机制** 当发送端网络状况较差（例如，上行带宽受限或高丢包），REMB机制的处理流程如下： - **接收端响应**： - 接收端通过监测数据包到达延迟或缓存压力，检测到网络异常（如延迟梯度$m(t)$增加），并降低REMB反馈值$A_r$[^3]。引用[3]说明：“接收端基于延迟的码率控制运行在接收端，WebRTC根据数据包到达的时间延迟，估算出网络延迟，并通过过载检测器判断拥塞状况，最后计算出$A_r$”。 - 如果发送端问题导致接收端丢包率升高（例如 >10%），接收端在REMB反馈中可能隐含这一信息，但REMB消息本身不包含丢包数据；它主要承载带宽估计值[^1][^2]。 - **发送端调整**： - 发送端独立于REMB，有自己的拥塞控制机制。基于RTCP RR报文中的丢包率，发送端计算码率$A_s$（例如，丢包率 <2% 时增加码率，丢包率 >10% 时减少码率）[^2][^3]。伪代码如下： ```python if loss_rate < 0.02: # 2%丢包率 A_s *= 1.08 # 增加码率 elif loss_rate > 0.10: # 10%丢包率 A_s *= (1 - 0.5 * loss_rate) # 减少码率 A = min(A_s, A_r) # 综合REMB反馈 ``` - 发送端网络差时，其$A_s$值会下降（由于高丢包），并结合REMB的$A_r$，最终码率$A$被限制在较低水平[^2][^3]。这间接缓解了发送端问题对整体传输的影响。 - **整体效果**：REMB机制**无法主动感知发送端网络**，但通过端到端协作（接收端反馈 + 发送端调整），WebRTC能适应网络变化。在发送端网络差的情况下： - 接收端可能因数据流异常而降低$A_r$。 - 发送端优先使用$A_s$和$A_r$中的较小值，确保码率不超过网络承载能力[^3]。 #### 4. **优缺点与局限性** - **优点**：REMB在接收端实现低开销估计，适合动态网络；结合发送端机制，提高了WebRTC的鲁棒性[^1][^3]。 - **局限性**：REMB对发送端网络不敏感，可能导致问题： - 如果发送端网络差但未影响下行链路（例如，仅上行拥塞），接收端不会调整REMB反馈。 - 在不对称网络（上行/下行带宽不同）中，REMB可能低估或高估带宽[^5]。新方案如Sender Side BWE（基于TransportCC）正逐步替代REMB，以更好处理发送端问题[^1]。 总之，REMB机制主要依赖接收端网络状况，发送端网络较差时，接收端只能间接感知（通过数据流异常）并调整反馈。WebRTC通过GCC算法的综合设计，确保了整体拥塞控制的效率[^1][^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值