WebRTC之NACK、RTX 在什么时机判断丢包发送NACK请求和RTX丢包重传

最新推荐文章于 2022-08-28 02:50:21 发布
最新推荐文章于 2022-08-28 02:50:21 发布
阅读量1.1k 收藏 6
点赞数 2
分类专栏： WebRTC源码探秘 文章标签： webrtc
本文为博主原创文章，未经博主允许不得转载。
本文链接：https://blog.csdn.net/Poisx/article/details/125038945
版权

WebRTC之NACK、RTX 在什么时机判断丢包发送NACK请求和RTX丢包重传

WebRTC之NACK、RTX 在什么时机判断丢包发送NACK请求和RTX丢包重传

WebRTC专题开嗨鸭 ！！！

一、 WebRTC 线程模型

1、WebRTC中线程模型和常见线程模型介绍

2、WebRTC网络PhysicalSocketServer之WSAEventselect模型使用

二、 WebRTC媒体协商

三、 WebRTC 音频数据采集

四、 WebRTC 音频引擎(编解码和3A算法)

五、 WebRTC 视频数据采集

六、 WebRTC 视频引擎( 编解码)

七、 WebRTC 网络传输

1、WebRTC的ICE之STUN协议

2、WebRTC的ICE之Dtls/SSL/TLSv1.x协议详解

八、 WebRTC服务质量(Qos)

1、WebRTC中RTCP协议详解

2、WebRTC中RTP协议详解

3、WebRTC之NACK、RTX 在什么时机判断丢包发送NACK请求和RTX丢包重传

九、 NetEQ

十、 Simulcast与SVC

前言

NACK 是判断网络是否丢包重传， 和网络情况

一、NACK与RTX的作用

1、NACK用于通知丢失了哪些包
2、RTX用于重传丢失的包

在发送offer和answer中是否正常Nack和RTX的协议

···
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
···

1、NACK/RTX的工作机制的流程图

在这里插入图片描述

2、NACK/RTX涉及到的几个问题

1、如何判定算法发送了丢包
Sequence Number 不连续的时候是丢包了哈
2、NACK什么时候发送
3、NACK的格式是怎样的，当发送端收到NACK时如何处理？
4、RTX格式是怎样的，RTX与NACK如何配合的？

二、判断包位置的关键算法

1、一个关键的函数：AheadOf

在这里插入图片描述

1、 AheadOf(a,b), 比较a与b的顺序关系
2、a与b必须是无符号整数
3、如果吧排在a前面，则返回真，否则返回false
4、需要注意的是，他们不是简单的数值大小的比较

三、WebRTC中NACK的处理流程图

在这里插入图片描述

1、NackMoudle的创建时机

在RtpVideoStreamReceiver中构造函数中创建NackMoudle类哈

RtpVideoStreamReceiver是在VideoReceiveStream类的构造函数创建哈

1、NACK调用栈

在这里插入图片描述

四、WebRTC如何判断是否丢包的逻辑

在这里插入图片描述

1、NackModule::OnReceivedPacket 函数

moudle/video_codeing/nack_module.h


int NackModule::OnReceivedPacket(uint16_t seq_num,
                                 bool is_keyframe,
                                 bool is_recovered) {
  rtc::CritScope lock(&crit_);
  // TODO(philipel): When the packet includes information whether it is
  //                 retransmitted or not, use that value instead. For
  //                 now set it to true, which will cause the reordering
  //                 statistics to never be updated.
  bool is_retransmitted = true;
  // 1. 判断是否第一次， 初始化  完成就退出
  if (!initialized_) {
    newest_seq_num_ = seq_num;
    if (is_keyframe)// 这个包是否关键帧===》》 为什么要识别关键帧？？？
      keyframe_list_.insert(seq_num);
    initialized_ = true;
    return 0;
  }

  // Since the |newest_seq_num_| is a packet we have actually received we know
  // that packet has never been Nacked.
  // 2. 如果这次来的seq与上次一样，是重复包， 退出
  if (seq_num == newest_seq_num_)
    return 0;
  // 即不是第一个包和重复包就判断包顺序哈 seq_num在newest_seq_num之前就要删除了哈  
  // 3. 如果是上次处理前面的包， 这个包已经失效了， 如果还在nack列表中， 需要删除的
  // 说明这个包晚到达了 
  if (AheadOf(newest_seq_num_, seq_num)) {
    // An out of order packet has been received.
    auto nack_list_it = nack_list_.find(seq_num);
    int nacks_sent_for_packet = 0;
    if (nack_list_it != nack_list_.end()) {
      nacks_sent_for_packet = nack_list_it->second.retries;
      nack_list_.erase(nack_list_it);
    }
    if (!is_retransmitted)
      UpdateReorderingStatistics(seq_num);
    return nacks_sent_for_packet;
  }

  // Keep track of new keyframes.
  // 4. 如果判断是否是key帧？？？ 哈
  if (is_keyframe)
    keyframe_list_.insert(seq_num); // 如果该报属于key帧， 保持起来

  // And remove old ones so we don't accumulate keyframes.
  // 5. 找到最小边界点，   超出10000个就要删除之前的数据 ， 这个是实时系统
  auto it = keyframe_list_.lower_bound(seq_num - kMaxPacketAge);
  if (it != keyframe_list_.begin())
    keyframe_list_.erase(keyframe_list_.begin(), it);
  // 6. 如何判断是否找回来的包？？？  恢复包
  if (is_recovered) {
    recovered_list_.insert(seq_num); // 如果该包是属于key帧，保持起来

    // Remove old ones so we don't accumulate recovered packets.
	//  是否超出项 超出项也删除了  ， 最大项也是10000哈
    auto it = recovered_list_.lower_bound(seq_num - kMaxPacketAge);
    if (it != recovered_list_.begin())
      recovered_list_.erase(recovered_list_.begin(), it);

    // Do not send nack for packets recovered by FEC or RTX.
    return 0;
  }
  // 7. 什么情况会走到这边呢 
  //     1、不是第一个包
  //     2. 不是一个重复的包
  //     3、 不是在new_seq_num之前的包
  //     4、 不是一个恢复包
  //   有两种情况会走到这边
  //     1、  上一次处理的包的后面的一个包哈   有序的包
  //     2、  上一次处理的包 后面隔好几个包   
  AddPacketsToNack(newest_seq_num_ + 1, seq_num);
  newest_seq_num_ = seq_num;

  // Are there any nacks that are waiting for this seq_num.
  // 8. 哪些包是真真丢包的  就告诉对方从新发送包哈
  std::vector<uint16_t> nack_batch = GetNackBatch(kSeqNumOnly);
  if (!nack_batch.empty()) 
    nack_sender_->SendNack(nack_batch);  //  需要重传哈   放到缓冲区了 ??????

  return 0;
}

2、 NackModule::AddPacketsToNack初步判断有哪些包丢包了

void NackModule::AddPacketsToNack(uint16_t seq_num_start,
                                  uint16_t seq_num_end) {
  // Remove old packets.
  auto it = nack_list_.lower_bound(seq_num_end - kMaxPacketAge);
  nack_list_.erase(nack_list_.begin(), it);

  // If the nack list is too large, remove packets from the nack list until
  // the latest first packet of a keyframe. If the list is still too large,
  // clear it and request a keyframe.
  // 1. 开始到结束之间有多大距离 
  uint16_t num_new_nacks = ForwardDiff(seq_num_start, seq_num_end);
  if (nack_list_.size() + num_new_nacks > kMaxNackPackets) {
    while (RemovePacketsUntilKeyFrame() &&
           nack_list_.size() + num_new_nacks > kMaxNackPackets) {
    }
	// 1.1、 极端情况  没有删除， 就要清除nack， 然后发送请求关键帧给对方  让解码器从新工作哈
    if (nack_list_.size() + num_new_nacks > kMaxNackPackets) {
      nack_list_.clear();
      RTC_LOG(LS_WARNING) << "NACK list full, clearing NACK"
                             " list and requesting keyframe.";
      keyframe_request_sender_->RequestKeyFrame();
      return;
    }
  }
  // 2、 遍历seq_num_start 到seq_num_end 之间 是否有丢包 有的话 就放到nack_list_中哈
  for (uint16_t seq_num = seq_num_start; seq_num != seq_num_end; ++seq_num) {
    // Do not send nack for packets that are already recovered by FEC or RTX
	// 2.1 是否已经通过FEC或者RTX恢复了 该包 恢复了 就不需要放到nack_list_列表中去哈
    if (recovered_list_.find(seq_num) != recovered_list_.end())
      continue;
    NackInfo nack_info(seq_num, seq_num + WaitNumberOfPackets(0.5),
                       clock_->TimeInMilliseconds());
    RTC_DCHECK(nack_list_.find(seq_num) == nack_list_.end());
    nack_list_[seq_num] = nack_info;
  }
}

3、 GetNackBatch （真真判定丢包的函数）

// 遍历所有可疑包 如果包符合条件 就插入nack_batch中
std::vector<uint16_t> NackModule::GetNackBatch(NackFilterOptions options) {
	// 1. 标识以seq_num为判断条件
  bool consider_seq_num = options != kTimeOnly;
  // 2. 标识以timestamp为判断条件 
  bool consider_timestamp = options != kSeqNumOnly;
  int64_t now_ms = clock_->TimeInMilliseconds();
  std::vector<uint16_t> nack_batch;
  auto it = nack_list_.begin();
  while (it != nack_list_.end()) {
	  // 1. send_nack_delay_ms_ 默认为0 ， 可修改
    bool delay_timed_out = now_ms - it->second.created_at_time >= send_nack_delay_ms_;
	// 2. 从一次发送开始到现在， 是否超过了一个RTT的回路的时长 时间  
	// 需要得到一个RTT防止重复传送的情况 
    bool nack_on_rtt_passed = now_ms - it->second.sent_at_time >= rtt_ms_;
	// 3、 第一次发送和最后处理包之前的
    bool nack_on_seq_num_passed = it->second.sent_at_time /*如果是第一次发送*/== -1 &&
        AheadOrAt(newest_seq_num_, it->second.send_at_seq_num)/*该包在最后处理的包之前*/;
	// 符合条件
    if (delay_timed_out && ((consider_seq_num && nack_on_seq_num_passed) ||
                            (consider_timestamp && nack_on_rtt_passed))) {
      nack_batch.emplace_back(it->second.seq_num);
      ++it->second.retries;
      it->second.sent_at_time = now_ms;
	  // 尝试10次 在nack_list列表中没有发现 就要删除了
      if (it->second.retries >= kMaxNackRetries/*kMaxNackRetries= 10*/) {
        RTC_LOG(LS_WARNING) << "Sequence number " << it->second.seq_num
                            << " removed from NACK list due to max retries.";
        it = nack_list_.erase(it);
      } else {
        ++it;
      }
      continue;
    }
    ++it;
  }
  return nack_batch;
}

其中要的判断条件

在这里插入图片描述

4、周期性执行的函数NackModule::Process


void NackModule::Process() {
  if (nack_sender_) {
    std::vector<uint16_t> nack_batch;
    {
      rtc::CritScope lock(&crit_);
      nack_batch = GetNackBatch(kTimeOnly);
    }

    if (!nack_batch.empty())
      nack_sender_->SendNack(nack_batch);
  }

  // Update the next_process_time_ms_ in intervals to achieve
  // the targeted frequency over time. Also add multiple intervals
  // in case of a skip in time as to not make uneccessary
  // calls to Process in order to catch up.
  int64_t now_ms = clock_->TimeInMilliseconds();
  if (next_process_time_ms_ == -1) {
    next_process_time_ms_ = now_ms + kProcessIntervalMs;
  } else {
    next_process_time_ms_ = next_process_time_ms_ + kProcessIntervalMs +
                            (now_ms - next_process_time_ms_) /
                                kProcessIntervalMs * kProcessIntervalMs;
  }
}

5、Process函数和OnReceivedPacket函数都有有发送nack函数目的

  1. 一个是时间查找丢失的包
  2. 一个seq_num的顺序查找丢失包

这个WebRTC在m74版本中设计怎么样哈 ， 给你会怎么设计这个丢包重传哈

五、WebRTC中VP8关键帧的判断

1、VP8 RTP结构图

在这里插入图片描述

2、 VP8 Payload 结构图

在这里插入图片描述

3、 VP8 Payload描述符两种结构

在这里插入图片描述

3.1、VP8 Payload 区别和字段含义

1、 两者的区别

pictureID： 第一个7位第二种15位

2、 字段含义

X：代表是否下面一行有扩展 [I|L|T|K|RSV]
R：预留的字段
N:  1：代表是非参考帧，0：是参考帧
S：是否属于视频帧分片  1：视频帧的第一个分片 0：其他分片
R：预留位
PID：表示分片的序号 ， 最大不超过8
3.2、 描述符中的扩展字节

1、I，该位置1， 表示存在PictureID，且其紧跟在扩展字节之后
2、L， 该位置1， 表示存在TLOPICIDX，它跟在PictureID之后，且T位必须置1
3、T，该位置1或者（T=0其K=1），TID/Y/KEYIDX字节存在，否则不存在
4、K，置1，TID/Y/KEYIDX字节存在；T=1且K=0，KEYIDX域被忽略；否则TID/Y/KEYIDX字节不存在
5、SRV，保留，必须设置为0

需要注意的点
1、PictureID域由M和PictureID组成。
M=1 ：PictureID占15位；
M = 0 : 占7位
2、 TID= 0 ， TLOPICIDX表示的是时间基础层帧的运行索引
视频的分层
3、TID> 0 ： TLOPICIDX表示的是当前图像所依赖的基础层帧
4、TID/Y/KEYIDX域中，TID占两位，Y占1位，KEYIDX占5位
TID：代表时间层，基础层为0，层级越高，值越大
Y： 层同步位，置1，表示当前帧仅依赖基础层帧（TIDO）；置0表示当前帧不依赖基础帧
KEYIDX：key帧索引值

4、VP8 Payload Header

在这里插入图片描述

4.1、VP8 Payload header 字段含义

一、 Header
1、对于内部帧，该域占3字节；对于key帧，该域占10字节
2、其中前3个字节的结构是通用的
3、该Header只有在上面的S位置位且PID=0时才存在
二、字段含义
1、P，1位，表示帧类型： 0-key, 1-infterframe 关键帧
2、VER，3位，1-3定义了4种不同的解码复杂度的profile
3、SIze， 19位，第一个分片字节的大小

5、KeyFrame Header 乘下的7个字节 含义

1、 3字节起始码： 固定值： 0x9D，0x01,0x2A
2、接下来的16位：（2bit Horizontal Scale << 14） | Width (14bits)
3、最后16位： （2bits Vertical Scale << 14）| Height (14bits)

总结：

WebRTC源码分析地址：https://github.com/chensongpoixs/cwebrtc

chen_song_
关注
  • 2
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【WebRTC---源码篇】（十二）WebRTC/RTX协议
用可见的方式来记录和分享每一次收获
10-07 365
WebRTC RTX
WebRTC视频数据统计之延时、抖动与丢包
04-25
WebRTC视频数据统计之延时、抖动与丢包，包含WebRTC如何更新、客户端如何获取等流程结构图
WebRTC的NACK和RTX简述
sonysuqin的专栏
08-24 7763
背景 在丢包 10%下测试WebRTC，发现丢包导致的卡顿，需要一些开启一些机制来保证丢包重传。 摘要 简述WebRTC中NACK、RTX的功能和联系。 正文 NACK、RTX是WebRTC里丢包重传策略，两个策略之间有一定的联系。 NACK：接收端通过RTCP将丢包的序列号通知给发送端，让发送端重传该包。 RTX：发送端在新的SSRC上发送重传包或者冗余包。 两者均需要通过sdp协商...
简述WebRTC中的丢包重传Nack的实现
chenquangobeijing的专栏
03-04 768
RTCP FB Nack包如上图所示：pt=205，fmt=1，PID是丢包的起始序列号-2字节，BLP表示起始序列号后面16位丢包情况，1是丢包，0是没丢包。这是WebRTC中的SDP，原视频流PT是96，重传RTX PT是97， ssrc-group是原视频流ssrc和RTX ssrc。sender ssrc是发送RTCP NACK包这端发送视频rtp包的ssrc，media ssrc是随机生成的。接收端发现序列号不连续，发送RTCP FB Nack包，发送端从历史队列中查找该包，再发送RTP包，
NACK & RTX
weixin_30810239的博客
08-21 261
目录 NACK & RTX 概述 NACK Sender NACK Receiver RTX 概述 协商 WebRTC 中的RTX特性 NACK & R...
webrtc源码之nack&&rtx详解
老衲不出家
09-24 1721
1、nack协商 m=video 9 RTP/AVPF 96 97 98 99 100 101127 122 108 109 123 a=rtpmap:96 H264/90000 a=rtcp-fb:96 goog-remb a=rtcp-fb:96 transport-cc a=rtcp-fb:96 ccm fir a=rtcp-fb:96 nack a=rtcp-fb:96 na...
SRS WebRTC拉流抓包分析
最新发布
07-04
SRS WebRTC拉流抓包分析
peertransfer：•使用WebRTC发送在浏览器中加密的文件p2p和e2e
02-02
由服务器中继以启动p2p WebRTC连接的消息是经过加密的（以防止在启动WebRTC时遭受IP泄漏和中间人攻击）。 安装 可在获得Peertransfer的托管实例。 git clone https://github.com/pguth/peertransfer.git cd ...
observer-js:用于提取和处理WebRTC统计数据示例的开发工具包
03-28
Wobserver WebRTC提取器用于WebRTC示例的Extractor开发工具包在本地构建库安装依赖项确保我们在系统中安装了类型脚本npm install -g typescript` 安装软件包依赖项npm ci 建立图书馆npm run build （开发人员版本） ...
webrtc源码zip包
01-17
4. **示例和应用**：`src/examples`目录提供了使用WebRTC API的示例代码，这些示例可以帮助开发者快速理解和学习如何在自己的项目中集成WebRTC。 5. **文档**：WebRTC的文档可能分布在多个地方，包括源码注释、API...
WebRTC的丢包计算方法
sonysuqin的专栏
09-06 5241
本文介绍了WebRTC内部计算丢包的算法，其跟RTT的计算有紧密联系，在Janus等服务优化丢包逻辑时可以作为参考。
webrtc nack重传包判定
10-13 541
webrtc SequenceNumber 比较 IsNewerSequenceNumber inline bool IsNewerSequenceNumber(uint16_t sequence_number, uint16_t prev_sequence_number) { // Distinguish between elements that are exactly 0x8000 apart. // If s1>s2
WebRTC 之 RTX
温故而知新
08-28 1799
Abstract WebRTC RTX 笔记 Authors Walter Fan Category learning note Status v1.0 Updated 2020-08-28 License CC-BY-NC-ND 4.0 什么是 RTX RTX 就是重传 Retransmission, 将丢失的包重新由发送方传给接收方。 Webrtc 默认开启...
WebRTC NACK
音视频学习专栏
06-29 1302
WebRTC NACK 在WebRTC中，前向纠错(FEC)和丢包重传(NACK)是抵抗网络错误的重要手段。FEC在发送端将数据包添加冗余纠错码，纠错码连同数据包一起发送到接收端；接收端根据纠错码对数据进行检查和纠正。RFC5109[1]定义FEC数据包的格式。NACK则在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接...
mediasoup丢包重传机制的实现
椛茶的博客
12-21 2125
在音视频通话中，我们常常使用 RTP 协议包荷载音视频数据，底层经常使用 UDP 作为其传输层协议，而 UDP 并不保证数据可靠性，因此当 RTP 产生丢包时，接收端需要告知源端哪些序号的包认为丢失了，请重传一遍过来。
WebRTC源码分析 nack详解
m0_60259116的博客
08-10 2364
WebRTC源码分析 nack详解
[webrtc] rtcp模块中rtt时间计算
ywa037的博客
09-16 726
<div class="col-lg-8"> <ul class="list-group"> <li class="list-group-item ul-li-title"> <h1>[webrtc] rtcp模块中rtt时间计算</h1> <hr> <span class="pre-scrollable"><div id="cnblogs_...
webrtc详解
wangbuji的博客
11-09 5644
获取媒体流第一步：获取视频源videoSource String frontCameraName = VideoCapturerAndroid.getNameOfFrontFacingDevice(); VideoCapturer videoCapturer = VideoCapturerAndroid.create(frontCameraName); VideoSource videoSource = factory.createVideoSource(videoCapturer,videoConstr
Webrtc 测丢包率
05-30
要测量 WebRTC 的丢包率，可以使用 RTCPeerConnection 对象的 getStats() 方法来获取有关当前连接的统计信息。该方法将返回一个 Promise，其中包含一个 RTCStatsReport 对象，该对象包含有关连接的各种统计信息，例如丢包率、网络延迟、带宽等。 以下是一个简单的示例代码，用于获取并显示当前 WebRTC 连接的丢包率： ``` // 获取当前 RTCPeerConnection 对象 var pc = new RTCPeerConnection(); // 获取统计信息 pc.getStats().then(function(stats) { stats.forEach(function(report) { if (report.type === 'inbound-rtp' || report.type === 'outbound-rtp') { // 输出丢包率 console.log(report.type + ' packets lost rate:', report.packetsLost / report.packetsReceived); } }); }); ``` 注意，该方法获取的是连接的实时统计信息，因此需要持续调用以获取最新的数据。另外，该方法返回的统计信息可能因浏览器而异，因此建议在不同浏览器中进行测试以确保统计信息的准确性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值