RunTheTests
/

Frame-Drop Detector

Count the frames your camera actually delivers against the rate it promised.

Live previewNever uploaded
Camera not started
Five seconds. Move around a little so the camera has something to track.

How this test works

Frames are counted with requestVideoFrameCallback, which fires once per decoded video frame. That distinction carries the whole test: counting animation frames instead measures how fast the page paints, so on a 60 Hz display it reports a confident 60 for a camera managing 12. Where the browser has no requestVideoFrameCallback the page says so and stops rather than falling back to the repaint count and presenting it as the same measurement. Over five seconds it records every inter-frame gap, then compares the measured rate against the rate the camera declared when it negotiated the stream — not against an assumed 30 or 60, because a camera that declares 15 and delivers 15 is not dropping anything. Steadiness is reported as a median absolute deviation of the gaps, so one long pause while the page was busy does not become the headline. Where the browser exposes its own presented-frames counter, the difference between that and the callbacks received shows frames that arrived while the page itself was too busy to be told.

What the results mean

Measured frame rate
Frames actually presented per second, counted one at a time. This is the real delivery rate, independent of how fast your screen refreshes.
Camera declared
The rate the camera negotiated for this stream. It is an intention rather than a promise, and the gap between it and the measured rate is the finding.
Shortfall
How far delivery fell below the declared rate, as a percentage. Under 5% is normal variation; above 15% is visible as stutter on movement.
Frames the page missed
Frames the browser presented but never reported to this page, because the page was busy. A large number here points at the machine's load rather than at the camera.

Common problems and fixes

The rate is far below what the camera is advertised to do
Check the light before anything else. In a dark room a camera lengthens its exposure, and a longer exposure mathematically cannot produce as many frames per second — a 60 fps camera in a dim room legitimately delivers 15. Add light and re-run; the rate rises immediately.
The frame rate is fine here but video stutters on calls
Then the loss is happening after the camera. Call software encodes, adapts to bandwidth and drops frames deliberately when the network is tight. This test having passed is genuinely useful information — it rules out the camera.
Delivery is steady but the rate is low and the room is bright
Look at the USB connection. A camera sharing bandwidth on a hub drops frames before it drops resolution. Try a port directly on the machine, ideally on a different side from other devices.
The browser cannot count frames
requestVideoFrameCallback is missing. Chrome, Edge and recent Safari all have it. Rather than report your display's refresh rate as if it were the camera's frame rate, the page declines to measure.

Frequently asked questions

Why does counting repaints not work?

Because a repaint happens whether or not a new camera frame arrived. A page repainting at 60 Hz in front of a camera delivering 12 frames per second counts 60, because it is counting itself. requestVideoFrameCallback fires once per actual decoded frame, which is the only way a page can distinguish the two.

Why compare against the declared rate rather than 30 fps?

Because plenty of cameras legitimately negotiate 15 or 24, and telling their owners they are dropping half their frames would be wrong and alarming. The camera states its intention when the stream opens, and the honest question is whether it delivered what it said it would.

Is a low frame rate a fault?

Usually not. The overwhelming majority of low frame rates are a camera adapting correctly to a dark room, and the fix is a lamp rather than a new camera. A rate well below declared in good light with the machine otherwise idle is the case worth pursuing.

What is a usable frame rate for video calls?

Around 24 and above looks natural. At 15 it is noticeably less smooth but perfectly usable for conversation. Below about 10 it reads as a slideshow and movement smears. Call software will happily transmit any of these, which is why the number is worth measuring rather than guessing at from how it feels.

More in Device