Inside WebRTC’s Pacer: How It Smooths Video Transmission

Background

When only audio is sent, a pacer is unnecessary because a single RTP packet can carry the small, fixed‑size audio frame. Video frames, however, can be much larger than the Ethernet MTU and must be split across multiple RTP packets; sending them all at once would cause network congestion, packet loss, and jitter, especially on Wi‑Fi.

Purpose of the Pacer

The Pacer smooths video transmission by distributing packets according to the estimated bitrate, as shown in the diagram.

Implementation Overview

The module solves three problems: how to send packets, when to send them, and how much data to send each time.

1. How to send packets

All media (audio, video, NACK, FEC, padding) are queued in a priority‑sorted pacer queue. The queue is not a simple FIFO; it orders packets by priority, retransmission flag, and video timestamp.

Higher‑priority packets are placed at the front.

Priority is determined by a numeric level: lower number = higher priority.

Retransmissions outrank new media.

Earlier video timestamps have higher priority.

When the pacer triggers a send event, it dequeues the highest‑priority packet first, minimizing video latency and ensuring fast delivery of retransmissions.

<code>int GetPriorityForType(RtpPacketMediaType type) {
  // Lower number takes priority over higher.
  switch (type) {
    case RtpPacketMediaType::kAudio:
      return kFirstPriority + 1;
    case RtpPacketMediaType::kRetransmission:
      return kFirstPriority + 2;
    case RtpPacketMediaType::kVideo:
    case RtpPacketMediaType::kForwardErrorCorrection:
      return kFirstPriority + 3;
    case RtpPacketMediaType::kPadding:
      return kFirstPriority + 4;
  }
  RTC_CHECK_NOTREACHED();
}
</code>

<code>bool RoundRobinPacketQueue::QueuedPacket::operator<(const RoundRobinPacketQueue::QueuedPacket& other) const {
  if (priority_ != other.priority_)
    return priority_ > other.priority_;
  if (is_retransmission_ != other.is_retransmission_)
    return other.is_retransmission_;
  return enqueue_order_ > other.enqueue_order_;
}
</code>

2. When to send packets

PacingController::ProcessPackets is invoked periodically according to PacingController::NextSendTime. Two modes exist: kPeriodic (fixed 5 ms interval) and kDynamic. The article focuses on kPeriodic, where the controller calls the send task every 5 ms.

3. How much data to send each time

After each trigger, the controller computes the elapsed time since the last call and feeds it to

media_budget_

. The budget calculates the number of bytes that can be transmitted in the current time slice based on the target bitrate.

Key terms:

delta time : time difference between the current and previous checks.

target bitrate : reference bitrate provided by the probing module.

remain_bytes : remaining bytes that can be sent; sending continues while > 0.

If the pacer queue is empty but the budget still allows more data, padding packets are generated.

Max Pacing Delay Mitigation

Because the pacer buffers packets, it introduces latency. A global

max_pacing_delay

limits this buffer time; exceeding the limit forces the pacer to adjust its target bitrate to keep latency under control.

Interaction with Encoder Bitrate Control

The pacer must work together with the video encoder’s bitrate controller. The probing module supplies a target bitrate, and the encoder must converge to this rate within a controllable period; otherwise, the pacer’s accumulated delay grows. I‑frame size also needs to stay reasonable to avoid large transmission delays.

All parameters should be tuned according to the specific deployment scenario.