Discarded Frames

What It Measures

Discarded Frames counts the number of video frames that were dropped before they could be displayed, for any reason other than decoding errors. This includes frames that were dropped because the render pipeline was congested, the decoder output buffer was full, the frame arrived too late for its display window, or the video pipeline deliberately dropped frames to maintain real-time rendering under CPU pressure.

Discarded frames sit between network delivery and the final Video Decoder Errors metric in the video pipeline: they were received, they may have been decoded, but they were never shown to the viewer.

Why It Matters

Discarded frames are a leading indicator — they rise before Video Freeze Events become visible and before Video FPS visibly drops. They measure pipeline stress, not pipeline failure.

Think of the video rendering pipeline as a series of queues: network buffer → jitter buffer → decoder → render queue → display. At each stage, frames can be discarded if the downstream queue is full. Discarded frames are what happens when one of those queues overflows — the system is working, but it is dropping frames to stay real-time rather than accumulating latency.

The distinction from decoder errors matters:

• Video Decoder Errors: The frame was received but could not be decoded — a data corruption or reference frame problem.
• Discarded Frames: The frame was decoded (or could have been) but was dropped — a throughput or timing problem.

For SIP and WebRTC video calls, the most common discard scenarios are:

Jitter buffer overflow: The receive buffer fills faster than the decoder can consume it. Frames are discarded to prevent unbounded latency growth. High discarded frames with high Jitter points here.

Decoder overload: The decoder cannot keep up with the incoming frame rate. Frames are dropped from the input queue to prevent the decoder from falling further behind. High discarded frames without high jitter, especially on high-resolution or high-fps streams, points here.

Late frame discards: Frames that arrive late for their display window are discarded rather than displayed out-of-time. This is the render-time manifestation of network jitter.

For capacity planning, discarded frames at scale reveal whether your receiving endpoint infrastructure (CPUs, render threads, decoder capacity) can handle the target concurrent call count.

Thresholds

How to Fix It

1. Identify the discard stage. Correlate with jitter and CPU metrics. Discards rising with jitter = jitter buffer overflow. Discards rising with resolution or fps = decoder CPU pressure.
2. Reduce video bitrate or resolution. If decoder overload is the cause, lowering the video bitrate or capping resolution reduces the decoder's per-frame processing load.
3. Increase jitter buffer depth. For jitter buffer overflow discards, a larger buffer absorbs delivery variation without dropping frames. This trades latency for smoothness.
4. Check for bandwidth competition. Discards that spike transiently often coincide with competing traffic bursts. Apply QoS and verify bandwidth headroom.
5. Correlate with Keyframe Requests Sent. A high discard rate that triggers frequent keyframe requests creates a feedback loop: discards → degraded display → keyframe request → large frame → more discards. Break the cycle by addressing the root discard cause.

Related Metrics

• Video Decoder Errors — Decoder failures; precede discards in the pipeline when corruption is the cause
• Video Freeze Events — Visible outcome of sustained high discard rates
• Video FPS — FPS drops when discard rate exceeds the target render rate
• Jitter — Network jitter is the primary cause of jitter-buffer-stage frame discards