CallMeter Docs

Keyframes Received

Understand the keyframes received metric in video streams — how CallMeter tracks inbound I-frames, and how to use the count to assess video recovery and remote encoder behavior.

Keyframes Received counts the total number of keyframes (I-frames) your video decoder has received from the remote side. Each keyframe is a complete picture that allows the decoder to fully reconstruct the video without depending on any previous frame. Keyframes are essential for joining a stream, recovering from packet loss, and resynchronizing after errors.

Think of it as receiving a "refresh" of the full picture. In between keyframes, the video updates incrementally. When a keyframe arrives, the decoder gets a clean slate.

How It Works

The remote encoder generates keyframes periodically (at a configured interval), in response to your keyframe requests (PLI/FIR), or when the video content changes dramatically. CallMeter counts each keyframe that arrives at the decoder.

This metric is especially useful when compared with Keyframe Requests Sent. The relationship between requests and received keyframes reveals how responsive the remote encoder is:

  • Requests sent = Keyframes received — The remote encoder responds to every request promptly
  • Requests sent > Keyframes received — Some requests are not being honored, possibly due to rate limiting or the requests being lost on the network
  • Keyframes received > Requests sent — The remote encoder is producing periodic keyframes beyond what you requested, which is normal behavior

Why It Matters

Keyframes received directly affects video recovery time. When your decoder loses synchronization (due to packet loss), it cannot display correct video until the next keyframe arrives. Faster keyframe delivery means shorter periods of visible corruption.

For enterprise VoIP testing, this metric helps validate:

  • Remote encoder responsiveness — How quickly keyframe requests are honored
  • Recovery time — The gap between requesting a keyframe and receiving one
  • Bandwidth planning — Keyframes are large; their frequency impacts bandwidth requirements

Common Causes of Low Keyframe Reception

CauseExplanation
Long keyframe intervalRemote encoder configured with infrequent periodic keyframes
Keyframe requests lostPLI/FIR messages dropped on the network path
Remote encoder overloadedEncoder unable to produce keyframes quickly enough
Keyframes lost in transitLarge keyframe packets lost due to fragmentation or congestion
Rate limitingRemote encoder throttling keyframe production to save bandwidth

How to Fix It

  1. Compare requests vs received — If Keyframe Requests Sent is high but keyframes received is low, the requests may be lost or the remote encoder may be throttling.
  2. Check for keyframe fragmentation — Keyframes are large and may be split across multiple RTP packets. Loss of any fragment renders the entire keyframe useless.
  3. Verify remote encoder configuration — Ensure the remote side's periodic keyframe interval is not excessively long (2-4 seconds is typical for video calls).
  4. Monitor bandwidth — If keyframe reception drops during congestion, the large keyframe packets may be the first casualties of bandwidth pressure.
  5. Review RTCP path — Keyframe requests travel via RTCP. If the RTCP path is blocked or rate-limited, requests may not reach the remote encoder.

RFC Reference

The keyframe request mechanisms that drive keyframe generation are defined in RFC 4585 (PLI, Section 6.3.1) and RFC 5104 (FIR, Section 3.5.1). Keyframe packetization into RTP follows the respective codec payload formats: RFC 6184 for H.264 and RFC 7741 for VP8.

On this page