【webrtc】视频包/音频包 接收测触发 nack

原创 已于 2023-08-28 19:34:19 修改 · 694 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#webrtc

于 2022-12-27 10:50:09 首次发布
本文详细介绍了WebRTC中音频和视频在接收端如何触发NACK机制。音频部分，NackTracker是NetEQ的一部分，通过NetEq创建和管理，用于追踪丢失的音频包并估算time-to-play。视频部分，VideoReceiveStream继承自NackSender，通过OnReceivedPayloadData接收到数据包后，调用SendNack发送NACK请求。NACK机制主要用于处理丢失的包，但不包括迟到的包。
  • 视频包会使用nack module
  • 音频使用nack tracer ，参考hanpfei大神
  • 音频默认是关闭的，音频nack用于音质比延迟更重要的场景。

音频包接收测触发nack

  • webrtc NackTracker 是属于NetEQ的。
  • 在这里插入图片描述

//
// NackTracker 类跟踪丢失的数据包，
// 还给出了每个数据包的播放时间（time-to-play）的估算值。

NetEq 创建

在这里插入图片描述

音频nack元素

在这里插入图片描述</

了解本专栏 订阅专栏 解锁全文
WebRTC中的视频RTP包接收及NACK触发流程解析
syntax_bug719的博客
09-12 308
本文将详细解析视频RTP包接收及NACK触发的流程，并提供相应的源代码。本文详细解析了WebRTC中视频RTP包的接收流程和NACK触发流程，并提供了相应的源代码示例。视频RTP包接收和NACK触发是保证实时视频传输质量的重要环节，在实际应用中需要进行合理的配置和处理。检测丢包情况：通过统计接收到的视频RTP包的序列号，检测是否有丢包现象。如果发现有丢包，就需要通过NACK请求重传丢失的视频RTP包。通过以上的流程，可以实现视频RTP包的接收和NACK触发，从而提高实时视频传输的质量。
【webrtc】RTX 重传包和NACK包
突围
11-12 452
总结 NACK 是反馈机制，用于告知丢失的具体包，触发发送端的重传行为。 RTX 是一种重传实现，以特殊方式重传数据包，便于接收端识别和处理。 两者常结合使用：NACK 请求 -> RTX 重传，在 WebRTC 和视频会议中广泛应用。
WebRTC NACK
音视频学习专栏
06-29 1511
WebRTC NACK 在WebRTC中，前向纠错(FEC)和丢包重传(NACK)是抵抗网络错误的重要手段。FEC在发送端将数据包添加冗余纠错码，纠错码连同数据包一起发送到接收端；接收端根据纠错码对数据进行检查和纠正。RFC5109[1]定义FEC数据包的格式。NACK则在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接...
Webrtc nack
fdsafwagdagadg6576的专栏
04-11 683
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源码走读（十）-QOS系列2-RTT
最新发布
qq_31065851的博客
10-23 1067
WebRTC中的RTT（环路延时）及其作用 RTT（Round-Trip Time）是数据从发送端到接收端再返回确认的时间，单位为毫秒（ms）。WebRTC通过解析RTCP协议的RR报告计算RTT，核心流程涉及多模块协作，最终由RTCPReceiver提取字段并计算。RTT直接影响抗丢包策略：低RTT（<100ms）优先使用NACK重传；中RTT（100-300ms）混合NACK和FEC；高RTT（>300ms）依赖FEC冗余。RTT还会动态调整FEC的冗余量，优化网络适应性。
webrtc源码阅读之NACK
qq_36383272的博客
07-17 763
NACK（Negative Acknowledgement）机制是WebRTC中用于处理数据包丢失的重要机制。用于在数据包丢失时通知发送方重新发送丢失的数据包。当接收方检测到数据包丢失时，它会发送一个NACK消息给发送方，请求重新发送丢失的数据包。这种机制可以帮助提高通信质量和可靠性，尤其在不可靠的网络环境下。本文将从webrtc源码分析nack的实现，版本m98。
WebRTC QoS方法一（NACK实现）
热门推荐
CrystalShaw的博客
07-26 1万+
一、概念 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。 NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。 在rfc4585协议中定义可重传未到达数据的类型有二种： 1）RTPFB：r...
WebRTC 的音频弱网对抗之 NACK
tq08g2z的专栏
06-08 1693
本文梳理 WebRTC 的音频弱网对抗中的 NACK 机制的实现。音频的 NACK 机制在 WebRTC 中默认是关闭的，本文会介绍开启 NACK 机制的方法。
WebRTC NACK机制详解
程序猿老樊的博客
09-21 1166
WebRTC中的NACK技术是应对网络丢包的关键机制。本文深入解析了NACK的工作原理、RTCP报文格式及其在WebRTC中的实现优化。NACK通过接收端主动反馈丢包信息，发送端快速重传，在保证低延迟的同时提升音视频质量。文章详细介绍了NACK的紧凑PID/BLP报文结构、发送端缓冲区管理、接收端丢包检测策略，以及与其他技术的协同配合。相比FEC，NACK具有带宽效率高的优势，适用于中低延迟网络，但对高RTT或突发丢包场景效果有限。理解NACK机制对优化实时音视频通信质量具有重要意义。
WebRTC音频 05 - 音频采集编码
Ziwubiancheng的博客
10-18 811
本文主要介绍了音频数据采集线程、编码线程如何配合完成音频数据从采集到编码发送的流程。涉及到引擎层的AudioState（包括其中的adm），以及ACM模块，还有Call模块，如果不了解这几个模块，可以看我的WebRTC音频 03 - 实时通信框架-优快云博客。
WebRTC源码分析 nack详解
m0_60259116的博客
08-10 2861
WebRTC源码分析 nack详解
【音视频】WebRTC-NACK
Antonio915的博客
09-02 922
WebRTC中的NACK（Negative Acknowledgment）机制用于处理实时通信中的网络丢包问题。当接收端检测到数据包丢失时，会发送NACK请求通知发送端重传丢失的包。发送端通过RtpPacketHistory缓存已发送的包，以便快速响应重传请求，同时根据网络延迟和容量限制动态管理缓存队列。接收端的NackRequester负责判断丢包并及时请求重传。该机制通过权衡延迟和重传效率，确保通信的连续性和质量。
深入浅出WebRTC—NACK
程序员老六的专栏
07-20 3269
WebRTC NACK 的实现简单明了，发送端缓存报文，接收端请求重传。但发送端和接收端实现关注重点不太一样。发送端是被动接收 NACK 请求，实现相对简单一些，重点关注缓存队列的长度。接收端需要主动发送发送 NACK 请求，实现会相对复杂一些，由于存在报文乱序，什么时候发起 NACK 请求是一个值得斟酌的事情。除此之外，WebRTC 还考虑到了瞬间突发丢包的快速重传机制和基于关键帧的队列收缩等，这些都凸显了 WebRTC 对细节的掌控和重视。
WebRTC的NACK和RTX简述
流媒体巅峰之路
08-18 1146
背景 在丢包 10%下测试WebRTC，发现丢包导致的卡顿，需要一些开启一些机制来保证丢包重传。 摘要 简述WebRTC中NACK、RTX的功能和联系。 正文 NACK、RTX是WebRTC里丢包重传策略，两个策略之间有一定的联系。 NACK：接收端通过RTCP将丢包的序列号通知给发送端，让发送端重传该包。 RTX：发送端在新的SSRC上发送重传包或者冗余包。 两者均需要通过sdp协商开启，在支持的服务端(例如Janus)修改SDP即可开启。 要点 重传包不一定通过RTX发送； RTX包不
webrtc 添加音频重传(NACK)功能
RTC hacker
10-28 7243
本文原创自 http://blog.youkuaiyun.com/voipmaker  转载注明出处。 webrtc的音频丢包处理部分，目前谷歌默认带PLC.FEC, 但是没有添加重传的协商能力，重传的rtcp标准协商属性是 在sdp里面增加针对某个codec 的一个sdp属性， 格式为 a=rtcp-fb:ocdec_pt nack  这里的codec_pt是具体音频codec的payload值，
WebRTC之视频NackModule
123456789
02-25 962
NackModule 一个包的最大请求次数是10次，最大请求时间是10*rtt，在这个时间内还没有获取到丢失的包则不再请求 对外提供的接口如下，源码 int OnReceivedPacket(const VCMPacket&amp;amp;amp;amp;amp; 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 1633
在网络环境不是太好的情况下，比如网络拥塞比较严重，丢包率可能比较高，简单实用NACK重传的机制，这样就会有大量的RTCP NACK报文，发送端收到相应的报文，又会发送大量指定的RTP报文，反而会增加网络的拥塞程度，可能导致更高的丢包率，导致接收端解码失败，导致花屏等马赛克现象。
webrtc NACK
03-09
- **延迟控制**：为了避免过度频繁地触发重传操作而导致额外开销甚至恶化拥塞状态，通常会对NACK消息的应用设置一定的阈值条件，比如仅针对连续丢失超过一定数量以上的包才发起请求。 - **优先级管理**：考虑到...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

等风来不如迎风去

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

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

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

打赏作者

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

抵扣说明：

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

余额充值