WebRTC系列-Qos系列之接收NACK

已于 2023-02-13 14:36:07 修改
阅读量1.3k 收藏
点赞数
分类专栏： WebRTC进阶 文章标签： webrtc
于 2023-01-23 08:45:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/lym594887256/article/details/128706317
版权
本文详细介绍了WebRTC中处理接收NACK的流程，从区分RTP和RTCP包开始，深入解析查找丢失包的逻辑，以及如何在OnReceivedNack方法中处理丢失包。重点分析了RTPHeaderParser中的区分方法和RTPSender的处理过程，涉及RTCP包头结构、RTP包头结构，以及Pacer在重传过程中的作用。

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

文章目录


在文章 WebRTC系列-Qos系列之RTP/RTCP源码分析-RTP/RTCP包解析-3的2.3.3章节介绍了NACK包在WebRTC中解析方式及RFC规定协议的定义。
这篇文章开始，详细分析其接受RTCP包到解析nack的处理流程；

1. 主要调用流程

在WebRTC中主要调用流程调试设置断点后如下：
在这里插入图片描述

这里主要分析上面堆栈中红色部分的函数，首先Call函数的DeliverPacket的主要逻辑如下：

PacketReceiver::DeliveryStatus Call::DeliverPacket(
    MediaType media_type,
了解本专栏 订阅专栏 解锁全文 超级会员免费看
WebRTC系列-Qos系列之接收方RTX处理
HOSTEN的博客
02-13 806
在上一篇文章中分析了接收到nack后解析的主要流程。在WebRTC里NACKRTXRTX协议是一种针对实时音视频通信的传输协议。RTX协议主要解决了丢包问题，以提高实时音视频通信的质量。RTX协议的详细规定可以在以下的文档中找到，该文档规定了RTX协议的用于视频数据的具体实现方式；需要注意的是，以上文档仅规定了RTX协议在视频数据中的应用，RTX协议在音频数据中的应用并未在此列举。但是，RTX协议的原理与应用是相通的，因此在音频数据中的应用方式与在视频数据中类似。
WebRTC系列-Qos系列之发送NACK
HOSTEN的博客
01-18 1375
在之前的文章介绍了音频开启对包重传的方式及验证是否开启的成功的方式；在文章的2.3.3章节介绍了NACK包在WebRTC中解析方式及RFC规定协议的定义。在WebRTC中是支持音频和视频的NACK，本文只分析NACK及其重点相关的机制，不分析jitterbuffer或者neteq的相关知识及实现，这些将会有其他的文章重点介绍。
WebRTC NACK
音视频学习专栏
06-29 1427
WebRTC NACK 在WebRTC中，前向纠错(FEC)和丢包重传(NACK)是抵抗网络错误的重要手段。FEC在发送端将数据包添加冗余纠错码，纠错码连同数据包一起发送到接收端；接收端根据纠错码对数据进行检查和纠正。RFC5109[1]定义FEC数据包的格式。NACK则在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接...
WebRTC QoS方法一（NACK实现）
热门推荐
CrystalShaw的博客
07-26 1万+
一、概念 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。 NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。 在rfc4585协议中定义可重传未到达数据的类型有二种： 1）RTPFB：r...
Webrtc nack
fdsafwagdagadg6576的专栏
04-11 531
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 2736
WebRTC NACK 的实现简单明了，发送端缓存报文，接收端请求重传。但发送端和接收端实现关注重点不太一样。发送端是被动接收 NACK 请求，实现相对简单一些，重点关注缓存队列的长度。接收端需要主动发送发送 NACK 请求，实现会相对复杂一些，由于存在报文乱序，什么时候发起 NACK 请求是一个值得斟酌的事情。除此之外，WebRTC 还考虑到了瞬间突发丢包的快速重传机制和基于关键帧的队列收缩等，这些都凸显了 WebRTC 对细节的掌控和重视。
WebRTC系列-Qos系列之音频设置丢包重传nack
HOSTEN的博客
01-06 1209
在目前的WebRTC各个版本中音频的重传目前都是默认处于关闭的，也就是音频的sdp里默认是没有NACK；Feedback的subtype是205就是nack的的rtcp包；
WebRTC系列-Qos系列之RTP/RTCP协议分析rtcp-1
HOSTEN的博客
01-08 690
上一篇文章介绍了RTP协议，通常RTP负责传输数据，RTCP一起工作，RTCP负责对RTP的通信和会话进行控制（如流量控制、拥塞控制、会话源管理等）；同rtp协议一样，协议由 IETF（http://www.ietf.org/）定义在和3551中；
WebRTC的NACK和RTX简述
sunxiaopengsun的专栏
06-26 358
https://blog.youkuaiyun.com/sonysuqin/article/details/82021185
webrtc 添加音频重传(NACK)功能
RTC hacker
10-28 7162
本文原创自 http://blog.youkuaiyun.com/voipmaker  转载注明出处。 webrtc的音频丢包处理部分，目前谷歌默认带PLC.FEC, 但是没有添加重传的协商能力，重传的rtcp标准协商属性是 在sdp里面增加针对某个codec 的一个sdp属性， 格式为 a=rtcp-fb:ocdec_pt nack  这里的codec_pt是具体音频codec的payload值，
webrtc源码阅读之NACK
qq_36383272的博客
07-17 678
NACK（Negative Acknowledgement）机制是WebRTC中用于处理数据包丢失的重要机制。用于在数据包丢失时通知发送方重新发送丢失的数据包。当接收方检测到数据包丢失时，它会发送一个NACK消息给发送方，请求重新发送丢失的数据包。这种机制可以帮助提高通信质量和可靠性，尤其在不可靠的网络环境下。本文将从webrtc源码分析nack的实现，版本m98。
WebRTC之视频NackModule
123456789
02-25 926
NackModule 一个包的最大请求次数是10次，最大请求时间是10*rtt，在这个时间内还没有获取到丢失的包则不再请求 对外提供的接口如下，源码 int OnReceivedPacket(const VCMPacket& packet); void ClearUpTo(uint16_t seq_num); void UpdateRtt(int64_t rtt_ms); void Cle...
WEBRTC 的RTP/RTCP的 NACK, PLI，SLI,FIR
thehunters的专栏
08-23 1383
在网络环境不是太好的情况下，比如网络拥塞比较严重，丢包率可能比较高，简单实用NACK重传的机制，这样就会有大量的RTCP NACK报文，发送端收到相应的报文，又会发送大量指定的RTP报文，反而会增加网络的拥塞程度，可能导致更高的丢包率，导致接收端解码失败，导致花屏等马赛克现象。
WebRTC源码分析 nack详解
m0_60259116的博客
08-10 2701
WebRTC源码分析 nack详解
WebRTC 的音频弱网对抗之 NACK
tq08g2z的专栏
06-08 1496
本文梳理 WebRTC 的音频弱网对抗中的 NACK 机制的实现。音频的 NACK 机制在 WebRTC 中默认是关闭的，本文会介绍开启 NACK 机制的方法。
【webrtc】视频包/音频包 接收测触发 nack
突围
12-27 631
nack
【粗读webrtc】NACK 重传 :RtpPacketHistory NackList
突围
06-26 509
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.
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

简简单单lym

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

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

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

打赏作者

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

抵扣说明：

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

余额充值