videocalling
glossary.backToGlossary

Packet Loss

技術

When data packets fail to reach their destination across a network

What is Packet Loss?

Packet loss occurs when one or more data packets traveling across a network fail to reach their destination. Imagine sending 100 letters through the mail, but only 95 arrive—the 5 that never made it represent packet loss. In video calling, those lost packets could be parts of your voice, video frames, or control signals.

Every WebRTC call sends thousands of packets per second. Your camera and microphone generate continuous streams of data, broken into small packets (typically 1000-1500 bytes each) and sent over the internet. When network conditions are perfect, every packet arrives. But in reality, some packets get lost along the way.

Unlike downloading a file (where lost packets can be retransmitted without you noticing), real-time video calls must continue playing. When packets are lost, you hear audio dropouts, see video freezes, or experience pixelation. WebRTC employs sophisticated techniques to minimize packet loss impact, but beyond certain thresholds, quality degrades unavoidably.

How Packet Loss Happens

Network Congestion

The most common cause. When routers, switches, or network links are overloaded with traffic, they have finite buffer space. When buffers fill up, new arriving packets are simply dropped (discarded). This is like a highway traffic jam—when too many cars try to use the same road, some have to be turned away.

Congestion is worse during peak usage times, on shared networks (public WiFi, cellular), and when multiple applications compete for bandwidth on the same connection.

Faulty Hardware

Malfunctioning network equipment (routers, switches, cables, WiFi access points) can corrupt or drop packets. A damaged Ethernet cable, overheating router, or failing network card causes random packet loss unrelated to congestion.

WiFi Issues

Wireless connections are inherently lossy compared to wired:

  • Interference: Other WiFi networks, microwave ovens, Bluetooth devices, cordless phones
  • Signal attenuation: Walls, distance, obstacles weaken the signal, causing transmission errors
  • Collisions: Multiple devices transmitting simultaneously on the same channel
  • Hidden node problem: Devices that can't hear each other both transmit, causing collisions at the access point

Quality WiFi (strong signal, 5GHz band, WiFi 6) might have 0.1-0.5% packet loss. Poor WiFi can easily reach 5-10%+ packet loss.

Software Bugs

Buggy network drivers, firewall misconfigurations, or operating system issues can cause packet drops. Less common than physical layer problems, but still occurs.

Intentional Dropping (QoS)

Quality of Service (QoS) systems sometimes intentionally drop lower-priority traffic during congestion. If WebRTC traffic isn't prioritized, it might be dropped in favor of other traffic.

Impact on Call Quality

Audio Impact

Audio is extremely sensitive to packet loss:

  • <1% loss: Imperceptible or barely noticeable
  • 1-2.5% loss: Acceptable quality, occasional minor glitches
  • 3-5% loss: Noticeable quality degradation, frequent dropouts
  • 5-10% loss: Significant quality issues, speech becomes difficult to understand
  • >10% loss: Severe degradation, communication becomes very difficult

Lost audio packets cause gaps in speech, robotic or distorted sound, or complete dropouts if consecutive packets are lost.

Video Impact

Video is even more sensitive to packet loss due to inter-frame dependencies:

  • <1% loss: Good quality, rare artifacts
  • 1-3% loss: Occasional pixelation or brief freezes
  • 3-5% loss: Frequent artifacts, noticeable degradation
  • 5-10% loss: Severe pixelation, long freezes, blocky video
  • >10% loss: Video becomes mostly unusable

Lost video packets cause pixelation (blocky artifacts), freezing (when keyframes are lost), color distortion, or complete frame drops. Because video codecs rely on previous frames, losing one packet can corrupt multiple subsequent frames until the next keyframe.

Why WebRTC Uses UDP

WebRTC primarily uses UDP (User Datagram Protocol) rather than TCP (Transmission Control Protocol). Understanding why requires understanding the difference:

TCP: Reliable but Slow

TCP guarantees packet delivery through acknowledgments and retransmissions. If a packet is lost, TCP detects this and resends it. This ensures 100% reliability—every packet eventually arrives in the correct order.

The problem: retransmission takes time (often 100-300ms for a round trip). By the time the retransmitted packet arrives, it's too late—the video has already moved on. Playing old audio or video packets out of sequence causes worse quality than just skipping them.

UDP: Fast but Lossy

UDP provides no retransmission, no acknowledgments, no guarantees. Packets are sent and forgotten. If they arrive, great. If not, they're lost forever.

For real-time communication, this is actually better. UDP has minimal overhead, low latency, and avoids the "head-of-line blocking" problem where one lost packet delays all subsequent packets (as happens with TCP).

WebRTC accepts that some packet loss will occur and uses application-level techniques to mitigate it, rather than relying on transport-level retransmission.

How WebRTC Handles Packet Loss

Since UDP doesn't retransmit, WebRTC implements its own error resilience mechanisms:

1. Forward Error Correction (FEC)

FEC adds redundant data before transmission, allowing receivers to reconstruct lost packets without retransmission. Think of it like sending multiple copies or parity information.

Audio FEC (Opus): The Opus codec includes built-in FEC. When enabled, it adds 20-30% redundancy, allowing reconstruction of individual lost packets. Highly effective for isolated packet loss.

Video FEC: Less commonly used because adding 20%+ redundancy reduces video quality (that bandwidth could have been used for higher resolution instead). Modern WebRTC uses selective FEC—only protecting the base layer in SVC (Scalable Video Coding), reducing overhead by ~35%.

Trade-off: FEC increases bandwidth usage and adds latency (20-50ms). Only activate FEC when packet loss is high or perfect quality is essential.

2. Packet Loss Concealment (PLC)

When packets are lost, PLC synthesizes plausible replacement data to mask the loss.

Audio PLC: WebRTC's NetEQ jitter buffer includes sophisticated PLC that:

  • Repeats or stretches the last received audio segment
  • Synthesizes speech-like sounds based on preceding audio
  • Gradually fades to comfort noise for extended losses

PLC can conceal losses up to 60-80ms with reasonable quality. Beyond that, the concealment becomes noticeable.

Video PLC: Repeats or freezes the last successfully decoded frame. Some implementations use motion estimation to synthesize intermediate frames, though this is computationally expensive.

3. Retransmission (RTX)

WebRTC can selectively request retransmission of important lost packets—typically keyframes (I-frames) for video. RTX differs from TCP retransmission by being selective and time-aware: only retransmit if the packet is still useful when it arrives.

For example, a lost keyframe might be worth retransmitting even if it arrives 100ms late, because without it, all subsequent frames are undecodable. But a lost delta frame (P-frame or B-frame) is often not worth retransmitting—by the time it arrives, we've moved on.

4. Redundancy Encoding (RED)

RED (Redundant Encoding) sends lower-quality versions of previous packets along with current packets. If the current packet is lost, the receiver can use the redundant (lower quality) version from a later packet.

Particularly effective for audio where sending a low-bitrate copy (8 kbps) of the previous frame (64 kbps) adds minimal overhead but provides recovery from isolated losses.

5. Adaptive Bitrate

When packet loss is detected, WebRTC's congestion control reduces encoding bitrate. Lower bitrate means fewer packets sent, reducing congestion and therefore reducing future packet loss. This is reactive but effective—trading quality for reliability.

6. Reference Frame Selection

Video encoders can be configured to use error-resilient reference patterns. Instead of each frame depending on the immediately previous frame (where one loss corrupts many frames), encoders can periodically reference older frames or use multiple reference frames. This limits error propagation from packet loss.

Measuring Packet Loss

WebRTC Stats API

Use getStats() on RTCPeerConnection to access:

  • packetsLost: Total packets that failed to arrive
  • packetsReceived: Total packets successfully received
  • packetsSent: Total packets sent
  • Calculate loss percentage: (packetsLost / (packetsReceived + packetsLost)) * 100

Browser Developer Tools

  • Chrome: chrome://webrtc-internals shows packet loss graphs in real-time
  • Firefox: about:webrtc displays packet loss statistics per track

Network Testing Tools

Tools like iperf or mtr can measure packet loss on the network independently of WebRTC, helping identify whether loss is network-level or application-level.

Preventing and Reducing Packet Loss

1. Use Wired Connections

Ethernet has dramatically lower packet loss than WiFi. For critical calls, use a wired connection. Typical packet loss: Wired <0.1%, WiFi 0.1-5%.

2. Optimize WiFi

  • Use 5GHz band (less interference)
  • Position close to access point (strong signal)
  • Change to less congested channel
  • Upgrade to WiFi 6/6E (better handling of multiple devices)
  • Replace old/failing hardware

3. Reduce Network Congestion

  • Close bandwidth-heavy applications (streaming, downloads, cloud backup)
  • Limit other users on the network during calls
  • Upgrade internet bandwidth if consistently congested

4. Quality of Service (QoS)

Configure routers to prioritize WebRTC traffic (UDP ports, DSCP marking). This ensures video call packets get through even when the network is busy with other traffic.

5. Check Hardware

Test Ethernet cables, replace failing routers/switches, update network drivers. Faulty hardware causes random packet loss that QoS can't fix.

6. Enable WebRTC Error Resilience

  • Enable Opus FEC for audio
  • Use RED (Redundant Encoding) when needed
  • Configure RTX for keyframe retransmission
  • Tune jitter buffer to handle bursty loss

Bursty vs. Random Packet Loss

Not all packet loss is equal:

  • Random loss: Isolated packets lost unpredictably. 2% random loss is fairly well tolerated by FEC and PLC
  • Bursty loss: Consecutive packets lost together. 2% bursty loss (e.g., 10 packets lost in a row, then 490 arrive) is much worse than 2% random loss. Bursty loss defeats most recovery mechanisms

Bursty loss typically indicates severe congestion, route changes, or WiFi interference. It's harder to mitigate than random loss.

The Bottom Line

Packet loss is the enemy of real-time communication. While bandwidth determines maximum quality and latency determines delay, packet loss directly destroys call quality by removing pieces of the audio and video stream.

WebRTC's error resilience mechanisms—FEC, PLC, RTX, RED—are remarkably effective at masking low levels of packet loss (<3%). But beyond certain thresholds, no amount of clever engineering can reconstruct lost data. Prevention is always better than mitigation.

Understanding packet loss helps you diagnose "choppy audio" or "pixelated video" complaints, optimize network infrastructure, and set realistic quality expectations. Wired connections, QoS prioritization, and adequate bandwidth are your best defenses against packet loss.

References

相關術語

BandwidthLatencyJitter
glossary.backToGlossary