Fundamentals 5 min read

How WebRTC Implements Video NACK: A Deep Dive into RTP Retransmission

This article provides a comprehensive walkthrough of WebRTC's video sender NACK implementation, covering the underlying ACK/NACK concepts, RFC4585 retransmission types, and the three-step process of storing RTP packets, handling RTCP NACK messages, and retransmitting lost media with priority handling.

Tencent Architect
Tencent Architect
Tencent Architect
How WebRTC Implements Video NACK: A Deep Dive into RTP Retransmission

This article explains the implementation of NACK on the WebRTC video sending side, based on the master branch code (commit f412945f05ce1ac372a7dad77d85498d23deaae).

Concept Overview

ACK is an acknowledgment that confirms receipt of data, while NACK is a negative acknowledgment that notifies the sender of missing packets. RFC4585 defines two types of retransmission for lost data, and the commonly used RTP packet loss retransmission offers a short recovery cycle with minimal bandwidth impact.

Key Implementation Steps

1. Send RTP packets and store them in the packet_history_ queue

Each time the pacer sends a packet, the media packet is stored in the packet_history_ queue.

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

The RtpPacketHistory::PutRtpPacket method stores RTP packets indexed by sequence number.

The queue length is configured via SetStorePacketsStatus. Video streams are configured in CreateRtpStreamSenders->SetStorePacketsStatus, and audio streams in

RegisterSenderCongestionControlObjects->SetStorePacketsStatus

.

2. Handle received RTCP NACK packets

The call chain is:

RTCPReceiver::HandleNack -> push packet_information->nack_sequence_numbers into loss queue

Then ModuleRtpRtcpImpl::OnReceivedNack updates RTT and forwards the NACK sequence numbers to RTPSender::OnReceivedNack.

3. Retransmit RTP packets in response to NACK

RTPSender::OnReceivedNack

triggers retransmission. Three important points:

NackModule2::AddPacketsToNack decides whether a packet should be placed into the NACK queue.

Retransmission modes : either via a separate RTX channel or mixed with regular media; using a dedicated RTX channel is recommended to avoid interference with bitrate estimation and FEC configuration.

RTPSender::ReSendPacket enqueues the retransmitted packet with high priority using set_packet_type and the kRetransmission type.

Priority configuration is performed in GetPriorityForType, which assigns a high priority to retransmission packets, and the packet is then added to the pacer queue by PacingController::EnqueuePacket.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Video Streamingreal-time communicationRTPWebRTCretransmissionNACK
Tencent Architect
Written by

Tencent Architect

We share technical insights on storage, computing, and access, and explore industry-leading product technologies together.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.