WebRTC: framesDecoded, framesDropped, and framesReceived are almost identical, but video freezes every second — Why?

[bkrmz]

Hi everyone,
I'm debugging a WebRTC video stream and noticed something strange in the stats.

In the inbound-rtp stats for the video track:

• framesDecoded ≈ framesReceived

• framesDropped ≈ framesDecoded

• All three values increase almost equally

• No packet loss, no jitter spikes

Yet, the remote video freezes for about 0.5–1s every second, even though frames are clearly being received and decoded.

Questions:

1. How is it possible for framesDropped to be almost equal to framesDecoded while the video still "plays"?

2. Does this indicate an internal decoder backlog or timing issue (e.g., congestion control, render queue stall, jitter buffer reset)?

3. Could this be caused by the sender pushing frames too fast, mismatched timestamps, or hardware acceleration problems?

Any insights on what typically causes this pattern would be appreciated.
Thanks!

[Philipp Hancke]

until very recently, framesReceived was miscounting framesDecoded, see https://issues.webrtc.org/issues/461543467 which might explain what you saw.

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/f7e7565c-61ab-44b6-a7ba-24dd47874bfdn%40googlegroups.com.