WebRTC系列分享 第三期 | WebRTC QoS方法之视频发送端NACK实现

导语 | 本文为大家详细解读一下WebRTC中视频发送端NACK的实现。文章中引用的WebRTC代码基于master，commit：f412945f05ce1ac372a7dad77d85498d23deaae源码分析。

概念简介

与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。

NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。

在rfc4585协议中定义可重传未到达数据的类型有二种：

目前大家普遍使用RTP报文丢失重传，这种方式恢复周期短，相对于另外三种，对带宽影响小。

本文首先介绍WebRTC发送端NACK实现流程：

具体实现

重点流程有三步：

1. 发送RTP报文，实时存储报文到packet_history_队列

ProcessThreadImpl::Process->PacedSender::Process    ->PacingController::ProcessPackets->PacketRouter::SendPacket->ModuleRtpRtcpImpl2::TrySendPacket->RtpSenderEgress::SendPacket

每次pacer发送报文的时候，都会把媒体报文储存在packet_history_队列。

RtpPacketHistory::PutRtpPacket以SequenceNumber为索引，把rtp保存在packet_history_队列。

SetStorePacketsStatus配置队列长度。

视频在CreateRtpStreamSenders->SetStorePacketsStatus配置。

音频在RegisterSenderCongestionControlObjects->SetStorePacketsStatus配置。

2. 处理接受到的RTCP NACK报文

函数调用关系如下：

RTCPReceiver::HandleNack

• 压栈packet_information->nack_sequence_numbers丢包队列

ModuleRtpRtcpImpl::OnReceivedNack

• 将RTT延时时间及nack_sequence_numbers队列更新到RTPSender::OnReceivedNack

3. 重发NACK反馈的RTP报文

RTPSender::OnReceivedNack

重发报文这里有3点需要注意：

1 ）NackModule2::AddPacketsToNack：决定是否将该报文放入NACK队列。

RtpPacketHistory::VerifyRtt 

2 ）NACK重新发送媒体数据有两种方式：单独RTX通道发送、与媒体数据混在一起发送。

两种形式对单纯的NACK抗性影响不太大，但是与媒体数据混在一起发送模式，接收端无法区分是NACK重传报文，还是正常媒体数据，会导致接收端反馈的丢包率低于实际值，影响gcc探测码率，及发送端FEC冗余度配置。所以建议还是以RTX通道单独发送。

RTX通道单独发送重传报文，需要配置参数有如下三个：

3 ）RTPSender::ReSendPacket在将重传数据加入pacer队列，会设置报文优先级，为了保证实时性，NACK重传报文需要按照高优先级重传。

优先级配置在set_packet_type，发送报文时，会根据kRetransmission获取发送优先级。

PacingController::EnqueuePacket

GetPriorityForType

关于云架构平台部

云架构平台部是腾讯规模最大的技术部门之一，长期深耕音视频、存储、接入和计算服务等技术领域，通过海量的存储和数据库平台，世界级的CDN&音视频服务，先进的操作系统和视频编解码技术，助力腾讯云以技术的力量持续赋能客户，帮他们提升效率，降低成本。

腾讯云音视频在音视频领域已有超过21年的技术积累，持续支持国内90%的音视频客户实现云上创新，独家具备 RT-ONE™ 全球网络，在此基础上，构建了业界最完整的 PaaS 产品家族，并通过腾讯云视立方 RT-Cube™ 提供All in One 的终端SDK，助力客户一键获取众多腾讯云音视频能力。腾讯云音视频为全真互联时代，提供坚实的数字化助力。