Device diagnostics research
Why a Browser Frame Count Is Not a Camera Hardware Rate
What mechanisms in BeanNest's derived device-definition set can make a browser delivery count differ from a camera's hardware output?
Counting delivered frames is a browser-side observation, not a direct sensor measurement. The BeanNest definition set records a media path and four mechanisms that can separate delivered frames from hardware output. These are derived mechanism definitions, not four camera benchmark results.
Reviewed 2026-09-20 by BeanNest Studio
The definition set starts with the browser delivery path
The recorded path is getUserMedia to MediaStreamTrack and then to a video element or ImageCapture. A page observes what reaches that path; it does not read a sensor counter directly.
Duplication can make delivery count exceed fresh-image count
The definition set includes an example in which a 15 fps sensor requested at 30 fps can deliver fresh images at 15 while duplicating frames to 30 deliveries. The example defines a mechanism; it is not a measurement from a named camera.
Requested constraints are not the negotiated result
The definitions record that a driver can adjust requested constraints and that the page should read track.getSettings() for the negotiated value. Reporting only the requested number describes the request rather than the stream setting returned after negotiation.
Hidden-tab throttling can change a timer-based observation
The definition set records that hidden tabs throttle timers and requestAnimationFrame. A test that relies on those callbacks can therefore observe the throttled scheduling path instead of treating the callback count as a direct camera-rate measurement.
Adaptive rate changes are conditional, not universal
The definition set says some drivers may drop rate under low light or thermal load. It does not measure how many drivers do so, which devices do so, or how large the change will be.
One delivered-frame count cannot identify the mechanism
Duplication, negotiated constraints, throttled callbacks, and adaptive delivery affect different parts of the path. A single count by itself does not say which mechanism contributed, so the method and returned settings belong with the result.
Frame intervals for common rates
A delivery rate of 15, 24, 30 and 60 frames per second means a new frame about every 66.7, 41.7, 33.3 and 16.7 milliseconds on average. Those are arithmetic, not measurements from a camera. A stream can show 30 on the counter while half of those frames are repeats of the previous image, which is the duplication case in the definition set.
A worked example with illustrative numbers
If a page counted 300 delivered frames in 10 seconds, it could report 30 frames per second delivered. If the sensor were producing 15 fresh images per second and the driver repeated each one, 150 of the 300 would be fresh, and the count alone would look identical. These numbers are an illustration of the mechanism, not a result for any camera.
What Webcam Test reports
Webcam Test shows the camera name, resolution and the frame rate the browser reports for the track's current settings, and shows Not reported when the browser gives no value. It stops the camera when the tab is hidden, so it does not keep counting under the throttled timers the definition set describes. The reported rate is the negotiated setting, not a hardware specification.
The supportable claim is a delivery measurement
The definition set's honest claim is that a track delivered N frames in T seconds at the negotiated settings. A defensible report can also state the sampling method and visibility state. The same evidence does not support calling that number the camera hardware frame rate.
Scope of this guide
This research explains mechanisms encoded in a derived definition set. It does not report measured results for a named camera, estimate how often any mechanism occurs, diagnose a driver, or claim a specific browser version's throttling policy.
Method and evidence
We derived the mechanism set from documented protocol limits, Web platform scheduling behaviour, and the electrical model of a keyboard matrix, then encoded each constant with its reason in a generator script kept with the evidence files. The definitions file is regenerated by running that script. For this guide we traced the recorded media-capture path and described only the four mechanisms encoded in the derived definition set. We do not present the definitions as camera measurements or infer how frequently the mechanisms occur.
Environment: Node.js on a desktop workstation. The evidence is a definition set with recorded reasons, not a hardware measurement on a specific device.
Captured: 2026-09-20. Re-review trigger: Re-review when the definitions file changes or when media capture constraint handling changes in a target browser.
Evidence files: kept in BeanNest's source repository, not published on this site.
docs/research-evidence/device/definitions-2026-09-20.jsondocs/research-evidence/device/README.md
What this guide does not claim
- frame-rate values for any named camera
- claims that a driver is defective
- frequency claims about how often a mechanism occurs
- hardware specification claims
- statements about a specific browser version's throttling policy