WebRTC系列-Qos系列之发送NACK

最新推荐文章于 2023-06-19 17:29:54 发布
最新推荐文章于 2023-06-19 17:29:54 发布
阅读量1.3k 收藏 1
点赞数
分类专栏： WebRTC进阶 文章标签： webrtc
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lym594887256/article/details/128700581
版权
本文深入探讨WebRTC中的NACK机制，用于处理视频传输中的丢包问题。NACK通过RTCP反馈告诉发送端哪些包未收到，发送端再通过RTX重传丢失的包。文章介绍了NACK的基本原理、包位置的判断算法以及WebRTC中的处理流程，包括是否丢包的判断、乱序包的处理等。
摘要由CSDN通过智能技术生成

文章目录


在之前的文章 WebRTC系列-Qos系列之音频设置丢包重传nack介绍了音频开启对包重传的方式及验证是否开启的成功的方式；在文章 WebRTC系列-Qos系列之RTP/RTCP源码分析-RTP/RTCP包解析-3的2.3.3章节介绍了NACK包在WebRTC中解析方式及RFC规定协议的定义。
在WebRTC中是支持音频和视频的NACK，本文只分析NACK及其重点相关的 RTX机制，不分析jitterbuffer或者neteq的相关知识及实现，这些将会有其他的文章重点介绍。

1. NACK简述

WebRTC里视频默认是开启nack，然后使用RTX进行重传(音频的实现不一样，如果开启NACK也是使用原来的ssrc重新传递包)；对于RTX本文也会介绍到,RTX不会使用原来的SSRC重传这个丢失的包，而是会使用一个新的ssrc去重传这个包，一般情况下这个包的ssrc是媒体payload的ssrc+1，例如视频H264是96，那么对应的RTX就是RTX=97；
NACK的全称是Negative Acknow

了解本专栏 订阅专栏 解锁全文 超级会员免费看
WebRTC系列-Qos系列之RTP/RTCP协议分析rtcp-1
HOSTEN的博客
01-08 654
上一篇文章介绍了RTP协议，通常RTP负责传输数据，RTCP一起工作，RTCP负责对RTP的通信和会话进行控制（如流量控制、拥塞控制、会话源管理等）；同rtp协议一样，协议由 IETF（http://www.ietf.org/）定义在和3551中；
WebRTC系列-Qos系列之接收NACK
HOSTEN的博客
01-23 1296
在文章 WebRTC系列-Qos系列之RTP/RTCP源码分析-RTP/RTCP包解析-3的2.3.3章节介绍了NACK包在WebRTC中解析方式及RFC规定协议的定义。这篇文章开始，详细分析其接受RTCP包到解析nack的处理流程；
WebRTC QoS方法之视频发送端NACK实现
m0_60259116的博客
04-19 321
概念简介 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。 NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。 在rfc4585协议中定义可重传未到达数据的类型有二种： 目前大家普遍使用RTP报文丢失重传，这种方式恢复周期短，相对于另外三种，对带宽影响小。 本文首先介绍WebRTC发送
借助rtcp实现NACK丢包重传
好记性不如写博客！
10-10 5053
Qos.NACK 一、RTP/RTCP RTP/RTCP协议是流媒体通信最基本协议。RTP协议定义流媒体数据在互联网上传输的数据包格式，而RTCP协议则负责可靠传输、流量控制和拥塞控制等服务质量保证。在很多项目中，如WebRTC中，RTP/RTCP模块作为传输模块的一部分，负责对发送端采集到的媒体数据进行进行封包，然后交给上层网络模块发送；在接收端RTP/RTCP模块收到上层模...
WEBRTC浅析（五）视频Nack包的发送判断逻辑以及数据流
muwesky的专栏
07-11 541
这篇文章是对webrtc 中Nack包发送机制的梳理，主要包括三个部分： 第一部分，介绍RTCP包中，Nack包的规范。 第二部分，介绍在WEBRTC中，Nack发送机制的数据流程图。 第三部分，介绍在WEBRTC中，Nack处理的一些关键的代码。 一：RTCP Nack报文解析 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 1673
首先来看看整体的处理流程(上图)。 处理过程主要包括两个： 1、判断收到的RTP 的seq num与最近最大的seq num的差值。根据差值不同，做不同的处理。 2、判断每个seq num的重发次数是否超过指定次数，如果超过，则不再重发。 下面是主要逻辑的代码： synchronized private boolean received(int seq) { if (lastReceivedSeq == -1) { lastReceivedSeq = seq; ret...
WebRTC系列-Qos系列之NetEQ-NetEqImpl
HOSTEN的博客
03-27 598
在文章介绍了抖动消除的基本概念，以及在WebRTC中的实现等；这篇文章降围绕NetEqImpl，展开源码分析，本文不会分析具体算法，主要是看起核心处理逻辑；
WebRTC系列-Qos系列之音频设置丢包重传nack
HOSTEN的博客
01-06 1158
在目前的WebRTC各个版本中音频的重传目前都是默认处于关闭的，也就是音频的sdp里默认是没有NACK；Feedback的subtype是205就是nack的的rtcp包；
WebRTC系列-Qos系列之接收方RTX处理
HOSTEN的博客
02-13 763
在上一篇文章中分析了接收到nack后解析的主要流程。在WebRTC里NACKRTXRTX协议是一种针对实时音视频通信的传输协议。RTX协议主要解决了丢包问题，以提高实时音视频通信的质量。RTX协议的详细规定可以在以下的文档中找到，该文档规定了RTX协议的用于视频数据的具体实现方式；需要注意的是，以上文档仅规定了RTX协议在视频数据中的应用，RTX协议在音频数据中的应用并未在此列举。但是，RTX协议的原理与应用是相通的，因此在音频数据中的应用方式与在视频数据中类似。
webrtc QOS笔记二 音频buffer数据不足生成很多gap的问题
靑い空゛
02-23 376
webrtc QOS笔记二 音频buffer数据不足生成很多gap的问题
Qos之丢包重传NACK
Swallow_he的博客
10-27 4058
Qos.NACK 一、前言         RTP/RTCP协议是流媒体通信最基本协议。RTP协议定义流媒体数据在互联网上传输的数据包格式，而RTCP协议则负责可靠传输、流量控制和拥塞控制等服务质量保证。在很多项目中，如WebRTC中，RTP/RTCP模块作为传输模块的一部分，负责对发送端采集到的媒体数据进行进行封包，然后交给上层网络模块发送；在接收端RTP/RTCP模块收到上层模块的数据
WebRTC系列分享 第五期 | WebRTC QoS方法之Sender Side BWE实现
Lce的专栏
09-01 492
BWE（Bandwidth Estimation）可能是WebRTC视频引擎中最关键的模块了。BWE模块决定视频通讯中可以发送多大码率视频不会使网络拥塞，防止视频通讯质量下降。早期的带宽评估算法比较简单，大多是基于丢包来估计，基本的策略是逐步增加发送的数据量，直到检测到丢包为止。为了让发送端获悉网络上的丢包信息，可以使用标准的RTCP的RR来发送周期性的报告。现代的带宽评估算法则可以在网络链路发生丢包以前就监测到网络拥塞，它可以通过侦测数据包接收的时延来预测未来可能的拥塞。
谈谈网络通信中的 ACK、NACK 和 REX
最新发布
u013921164的博客
06-19 3829
ACK：Acknowledgement，它是一种正向反馈，接收方收到数据后回复消息告知发送方。 NACK：Negative Acknowledgement，则是一种负向反馈，接收方只有在没有收到数据的时候才通知发送方。 REX：Retransmission，重传，当发送方得知数据丢失后，重新发送一份数据。
WebRTC 的音频弱网对抗之 NACK
tq08g2z的专栏
06-08 1404
本文梳理 WebRTC 的音频弱网对抗中的 NACK 机制的实现。音频的 NACK 机制在 WebRTC 中默认是关闭的，本文会介绍开启 NACK 机制的方法。
usb学习笔记414（二）
chch414的博客
08-24 459
usb学习笔记
WebRTC QoS方法（汇总篇）
CrystalShaw的博客
05-24 1万+
目前总结出webrtc用于提升QOS的方法有： NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR（动态帧率调整策略）。 这几种方法在webrtc架构分布如下： 具体实现原理如下： 一、NACK 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收......
i2c信号的ACK与NACK
热门推荐
luckywang1103的专栏
12-25 9万+
我们平时在调试I2C的时候可能很少去关注NACK信号，只知道如果Master发送数据，MSB先发，LSB后发，连续发送一个字节(8个bit)，之后Slave会回复一个ACK信号，但是有时I2C slave可能会发出NACK信号，下面让我们来看看NACK信号存在的情况。 1、从spec下摘取一段： 2、翻译：         每个字节后会跟随一个ACK信号。ACK bit使
WebRTC QoS方法一（NACK实现）
CrystalShaw的博客
07-26 1万+
一、概念 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。 NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。 在rfc4585协议中定义可重传未到达数据的类型有二种： 1）RTPFB：r...
音视频传输(RTP/RTCP)丢包重传(NACK)，以及I帧申请(PLI，FIR)
qq_41681715的博客
11-19 7527
学过TCP通信原理的同学都知道，TCP没法送一个TCP报文，TCP协议栈都要等对端的ACK确认，才能确定是否进行报文重传或者发送下一包数据；然而RTCP的NACK重传机制与TCP的确认机制整好相反，当RTP接收端发现某一包数据或者N包数据确实没有收到，即在经过中间网络设备时丢掉了，接收端才会向发送端发送RTCP的NACK报文，向发送端要求重传相应的RTP包，NACK报文如下： 特别注意，使用NACK重传机制的收发双发，RTP都有一个发送缓冲区和接收缓冲区，缓冲区有缓冲区大小，发送太迟的NACK申请报文
深入探索WebRTCDemo-iOS在Objective-C中的实践
资源摘要信息: "WebRTCDemo-iOS" WebRTC是一个开源项目，旨在通过网页浏览器实现点对点的视频通话和数据共享。它提供了实时通信的能力，使得开发者能够将语音通信、视频聊天和点对点文件共享等实时通信功能集成到...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

简简单单lym

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

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

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

打赏作者

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

抵扣说明：

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

余额充值