【粗读webrtc】RTCP扩展反馈报文 接收 触发 nack重传

最新推荐文章于 2025-05-13 17:56:58 发布
最新推荐文章于 2025-05-13 17:56:58 发布
阅读量779 收藏 3
点赞数
CC 4.0 BY-SA版权
分类专栏： WebRTC入门与实战
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/commshare/article/details/106978699
本文深入分析了WebRTC中RTCP扩展反馈报文的NACK机制，详细阐述了NACK报文的格式，包括PID和BLP字段的含义。在接收端检测到丢包后，通过发送NACK报文触发重传。内容涵盖了RTCPReceiver的处理流程，如验证RTT、重发数据包的操作以及deque在处理过程中的作用。

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

RTCP扩展反馈报文 接收 触发 nack重传

  • WebRTC 中丢包重传 NACK 实现分析
  • NACK则在接收端检测到数据丢包后，发送NACK报文到发送端；
  • 发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端。
  • NACK需要发送端发送缓冲区的支持，RFC5104[2]定义NACK数据包的格式。

RTCP扩展反馈报文

  • webrtc的rtp重传代码分析
  • rtp也有nack机制，webrtc基于rtp实现了重传在一定程度上保证可靠性。
  • rfc4585，看到了这么一段 : RTCP扩展反馈报文，有一种nack报文
    在这里插入图片描述

当FMT=1并且PT=205时，代表此报文是个NACK报文

Name
了解本专栏 订阅专栏 解锁全文
【粗读webrtc】NACK 重传 :RtpPacketHistory NackList
突围
06-26 513
webrtc支持RTPFB和PLI FB两种重传方式 建立连接时，写入SDP O:\WEBRWTCSTORE\webrtc-checkout\src\media\engine\webrtc_video_engine.cc void AddDefaultFeedbackParams(VideoCodec* codec) { // Don't add any feedback params for RED and ULPFEC. if (codec->name == kRedCodecNam.
WEBRTC 的RTP/RTCP的 NACK, PLI，SLI,FIR
thehunters的专栏
08-23 1454
在网络环境不是太好的情况下，比如网络拥塞比较严重，丢包率可能比较高，简单实用NACK重传的机制，这样就会有大量的RTCP NACK报文，发送端收到相应的报文，又会发送大量指定的RTP报文，反而会增加网络的拥塞程度，可能导致更高的丢包率，导致接收端解码失败，导致花屏等马赛克现象。
rtcp nack 重传抓包
07-10
rtcp nack 重传抓包
流媒体协议-RTP、RTCP、RTX、RTFB、NACK
最新发布
qq_37811590的博客
05-13 1025
一个标准的 RTP 包由以下部分组成：2RTP（Real-time Transport Protocol）是用于在 IP 网络上传输音频、视频和其他实时数据流的协议。RTP 数据包本身仅携带实际的媒体数据（例如音频帧、视频帧等），但它通常不会单独传输。RTP 数据包通常是通过其他协议封装的，尤其是协议，因为 UDP 是一个无连接、低延迟的传输协议，适合实时数据流。链路层负责将数据帧从源主机传输到目标主机。0x08000x0806网络层的主要协议是在传输 RTP 数据包时，通常使用或。
Webrtc nack
fdsafwagdagadg6576的专栏
04-11 549
Nack 协议头 Nack: webrtc 10ms发送一次？ Nack重传分成两种类型的包，不仅仅是重传rtp 报文 PID（Packet identifier），即为丢失的 RTP 数据包的序列号 BLP（Bitmao of Lost Packets），通过掩码的方式指出了接下来 16 个数据包的丢失情况 Packet identifier(PID)即为丢失RTP数据包的序列号，Bitmap of Lost Packets(BLP)指示从PID开始接下来16个RTP数据包的丢失情况..
深入浅出WebRTC—NACK
程序员老六的专栏
07-20 2908
WebRTC NACK 的实现简单明了，发送端缓存报文，接收端请求重传。但发送端和接收端实现关注重点不太一样。发送端是被动接收 NACK 请求，实现相对简单一些，重点关注缓存队列的长度。接收端需要主动发送发送 NACK 请求，实现会相对复杂一些，由于存在报文乱序，什么时候发起 NACK 请求是一个值得斟酌的事情。除此之外，WebRTC 还考虑到了瞬间突发丢包的快速重传机制和基于关键帧的队列收缩等，这些都凸显了 WebRTC 对细节的掌控和重视。
WebRTC RTCP
clark的专栏
04-06 943
RTCP作为RTP控制协议，对于弱网下音视频质量和会话控制具有重要的作用。 RTCP header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
RTCP报文之NACK包的处理机制(RTP接收端)
infi
07-26 1771
首先来看看整体的处理流程(上图)。 处理过程主要包括两个： 1、判断收到的RTP 的seq num与最近最大的seq num的差值。根据差值不同，做不同的处理。 2、判断每个seq num的重发次数是否超过指定次数，如果超过，则不再重发。 下面是主要逻辑的代码： synchronized private boolean received(int seq) { if (lastReceivedSeq == -1) { lastReceivedSeq = seq; ret...
WebRTC-nack机制详解
Mr_xkHuang的专栏
08-12 3913
1.NACK的含义 丢包重传(NACK)是抵抗网络错误的重要手段。NACK在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端。NACK需要发送端，发送缓冲区的支持。 WebRTC中支持音频和视频的NACK重传。我们这里只分析nack机制，不分析jitterbuffer或者neteq的更多实现。 2.WebRTC中NACK请求发送的条件 这里以视频为例。 下面是webrtc中接收端触发nack的条件，我们看下nack_modul
WebRTC NACK
音视频学习专栏
06-29 1457
WebRTC NACK 在WebRTC中，前向纠错(FEC)和丢包重传(NACK)是抵抗网络错误的重要手段。FEC在发送端将数据包添加冗余纠错码，纠错码连同数据包一起发送到接收端；接收端根据纠错码对数据进行检查和纠正。RFC5109[1]定义FEC数据包的格式。NACK则在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接...
WebRTC服务质量（08）- 重传机制（05) RTX机制
Ziwubiancheng的博客
12-23 1796
函数是 WebRTC 中 RTP 协议层实现丢包恢复的重要部分。它利用记录和 RTX 协议实现高效的重传机制，同时考虑到带宽管理、速率限制和两种重传策略（RTX 和普通 RTP）的兼容性。在具体代码实现中，它通过灵活的封装和严格的速率控制，保证了无损恢复的同时避免了网络拥塞情况。
借助rtcp实现NACK丢包重传
好记性不如写博客！
10-10 5275
Qos.NACK 一、RTP/RTCP RTP/RTCP协议是流媒体通信最基本协议。RTP协议定义流媒体数据在互联网上传输的数据包格式，而RTCP协议则负责可靠传输、流量控制和拥塞控制等服务质量保证。在很多项目中，如WebRTC中，RTP/RTCP模块作为传输模块的一部分，负责对发送端采集到的媒体数据进行进行封包，然后交给上层网络模块发送；在接收端RTP/RTCP模块收到上层模...
RTCP 协议的 NACK 报文
qq_28581781的博客
09-13 3164
接收方定时把所有未收到的包序号通过反馈报文通知到发送方进行重传。 相对ARQ带来的改进：减少的反馈包的频率和带宽占用，同时也能比较及时地通知发送方进行丢包重传。 NACK 报文的定义在[rfc4585]文档中定义。 RTCP 的反馈报文包头定义如下，FMT 和 PT 决定了该报文的类型，FCI 则是该类型报文的具体负载： 转存失败重新上传取消转存失败重新上传取消 version (V): 2 bits 该字段标识RTP版本。当前版本是2 padding (P): 1 bit 如果...
RTCP丢包重传策略之NACK
qq_41681715的博客
01-07 1304
NACK全称Negative acknowledgements，相关具体描述可以查看rfc4585(NACK)文档。如果音视频收发双发都支持RTCP-NACK，当接收端认为发送端过来的RTP数据有丢包，这时接收端会向RTCP(NACK)的报文，请求发送端发送网络传输过程中丢掉的RTP数据包，同一个RTCP-NACK反馈包，可以请求发送端重传多个RTP包，下面主要讲下NACK格式的RTCP报文的主要组成部分： typedef struct rtcp_header { #if __BYTE_ORDER ==
webrtc之丢包重传
weixin_34259232的博客
10-31 1026
1 介绍 WebRTC丢包重传分为两种，一个是RTP报...
WebRTC的 丢包和重传
HOSTEN的博客
04-03 1343
前向纠错FEC和ulpfec 简述 WebRTC 中的音频大部分使用opus编码，opus编解码自带有FEC(前向纠错)； 前向纠错也叫前向纠错码(Forward Error Correction，简称FEC)，是增加数据通讯可信度的方法。在单向通讯信道中， 一旦错误被发现，其接收器将无权再请求传输。FEC 是利用数据进行传输冗余信息的方法，当传输中出现错误，将允许接收器再建数据。 基本原理: 前一帧与当前帧均正常， 前一帧数据正常解码； opus_decode(decoder, previous_
java丢包,webrtc之丢包重传
weixin_36116008的博客
03-13 226
介绍WebRTC丢包重传分为两种，一个是RTP报文丢失重传，另一个书PLI视频帧丢失重传，SDP格式如下：a=rtcp-fb:104 nack (RTP报文丢失重传)a=rtcp-fb:104 nack pli (PLI视频帧丢失重传)生成SDP的时候直接将以上参数加入到Codec，代码流程如下：AppendVideoCodecs ->AddDefaultFeedbackParams接口内...
WebRTC之丢包重传协议
徐福记456
09-24 1340
丢包处理可以使用FEC前向纠错、NACK丢包重传。上一篇文章咱们介绍过前向纠错，现在来探讨丢包重传。首先是接收端发送基于RTCP反馈的请求，发送端收到请求后重传指定packet包。
webrtc NACK
03-09
### WebRTC中的NACK机制及其实现细节 在网络状况不佳的情况下，为了提高媒体传输的质量和可靠性，WebRTC采用了多种技术手段。其中一种重要的纠错方法是负确认（Negative Acknowledgement, NACK）。当接收端检测到丢失的数据包时，会向发送方请求重新发送这些数据包。 #### 工作原理 在实时通信过程中，如果接收者未能接收到某些RTP数据包，则会在本地缓存中记录下缺失序列号的信息，并通过RTCP反馈报文告知发送者哪些具体的包已经丢失[^1]。随后，发送节点依据此信息决定是否以及何时重发相应的RTP负载。 这种基于丢包恢复的技术特别适用于具有突发性损失特性的网络环境，因为它允许快速响应并修正短期内的错误情况而不必等待整个流结束之后再处理。对于视频通话而言，及时补回少量错过的图像帧可以显著改善用户体验；而对于语音交流来说，即使是在较差连接条件下也能保持较好的音质清晰度[^3]。 #### 实现要点 - **延迟控制**：为了避免过度频繁地触发重传操作而导致额外开销甚至恶化拥塞状态，通常会对NACK消息的应用设置一定的阈值条件，比如仅针对连续丢失超过一定数量以上的包才发起请求。 - **优先级管理**：考虑到不同类型的多媒体内容可能有着不同的重要性和紧迫程度，在实际部署中往往还需要考虑如何合理分配有限资源给最需要被修复的部分。例如，关键帧相比于普通预测编码单元更值得优先保障其完整性。 - **与其他机制配合使用**：除了单独依靠NACK之外，还可以将其同前向纠错(FEC)等其他鲁棒化措施结合起来应用，从而形成更为全面有效的QoS策略体系。特别是新版WebRTC已经开始引入RED方式作为增强型音频保护方案的一部分。 ```python def nack_handler(missing_packets): """ 处理接收到的NACK指令，准备并发送必要的重传数据包 参数: missing_packets (list): 缺失的数据包包ID列表 返回: None """ for packet_id in missing_packets: # 查找对应的原始数据包副本 original_packet = find_original(packet_id) if original_packet is not None: send_retransmission(original_packet) ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

等风来不如迎风去

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

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

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

打赏作者

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

抵扣说明：

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

余额充值