An AI Reads My FPS Benchmarks Now
July 2026 · Method · BenchmarkingEvery benchmark table on the internet has the same quiet problem: the numbers are typed by a human, from memory, some time after the footage was shot. Mine were no exception. So I pointed Gemini 2.5 Flash at nine of my own Mac gaming videos and told it to read the FPS counter in the actual frames — no estimating, only numbers visible on screen.
It cost $0.44. It corrected more of my published table than it confirmed. This is how it works, what it found, and — the part most write-ups skip — what it cannot do.
The short version
An AI reading my own HUD overlays disagreed with my own site. The footage was right; the table was wrong. Six pages were corrected. If you publish benchmark numbers, the audit costs about five cents per video — which is the whole reason it is worth doing.
Why Bother — Tables Drift
A number gets published from a note scribbled during a session. A later video re-tests the same game on a newer OS, and the table never catches up. A "conservative estimate" gets typed into a cell as a placeholder and then hardens into a fact. None of that is dishonesty; it is just what happens when the evidence lives in an hour of video and the table lives in an HTML file.
The fix everyone knows is "go re-watch the footage and check." Nobody does it, because re-watching nine videos with a notepad is a full day of tedium. That is exactly the shape of job worth automating.
The Method
The key capability: Gemini accepts a YouTube URL directly as file data and reads the real video frames — not the title, not the description, not the transcript. The request is genuinely this small:
| Piece | Value |
|---|---|
| Model | gemini-2.5-flash |
| Video input | fileData.fileUri = the YouTube watch URL |
| Output format | responseMimeType: application/json |
| Temperature | 0.1 — this is transcription, not creativity |
The prompt does the real work. For each distinct benchmark segment it asks for the game, the Mac model, the method (Native / CrossOver / GPTK / Parallels), the visible settings, and then the line that matters most:
The load-bearing instruction: "fps_readings: list of {timestamp, fps} for values READABLE on the on-screen FPS/HUD counter. 4–8 readings per segment, spread across it. ONLY numbers actually visible in frames — never estimate."
Without that constraint a language model will happily produce plausible-looking FPS numbers, because plausible-looking text is what language models do. The whole pipeline lives or dies on forcing it to transcribe rather than infer. I also ask for an issues field (freezes, crashes, anti-cheat blocks) and an overall_notes field for things a table editor needs to know — beta OS versions, battery vs AC — which turned out to matter more than expected.
The first probe was the confidence check: on a 154-second clip it read the Metal HUD moving from 30.70 to 60.62 FPS as frame generation was toggled, and read back the settings-menu values in the same clip. Exact, to two decimals. That is when it stopped being a toy.
The Receipts
Nine full videos, metered per run. No estimates here either — this is the actual ledger:
| Metric | Actual |
|---|---|
| Videos processed | 9 |
| Input tokens | 1,249,887 |
| Output tokens | 24,770 |
| Rate (2.5 Flash, paid tier) | $0.30 / M in · $2.50 / M out |
| Total cost | ~$0.44 |
| Average per full video | ~$0.05 |
| Short 154-second clip | ~45,500 tokens · ~$0.014 |
Video burns input tokens fast — a long benchmark video ran about 236,000 tokens on its own. Even so, auditing an entire back catalogue cost less than a coffee. The script carries a hard token-budget cap that aborts the run rather than letting a loop bill me into oblivion, which I recommend to anyone doing this.
What It Found
This is the uncomfortable part, and the reason the post exists. The AI disagreed with me far more often than it agreed, and the footage backed the AI every time.
| Row | I had published | HUD actually showed | Direction |
|---|---|---|---|
| Marvel Rivals · M5 Air | 60 (High + DLSS) | 30 stable, all-low, DLSS off | Down |
| Marvel Rivals FG · M5 Air | 75 | 60 with frame gen | Down |
| Spider-Man Remastered · M5 Air | 45 | 30 stable | Down |
| Dota 2 CrossOver · M5 Air | 95 (High) | 60 low / 40 high | Down |
| Dota 2 native · M5 Air | 80 (High) | 59–60 stable (display cap) | Down |
| League of Legends · M5 Air | 120 (High) | 60 (cap) | Down |
| Dota 2 · M5 Pro | 110 (Ultra) | 120 through team fights | Up |
| League of Legends · M5 Pro | 90 (Very High) | 199 (frame cap) at 4K | Up |
| Cyberpunk · M1 Max | 35–45 (my estimate) | 74.1 avg native benchmark | Up |
M5 Air and M5 Pro rows are from my own footage. M1 Max Cyberpunk figures come from community benchmark overlays, labeled as such on the relevant pages.
Six pages got corrected. Two patterns stand out.
My optimistic errors clustered on the cheap machine. Nearly every inflated number was an M5 Air row. The likely cause is embarrassing and structural: the M5 Air has a 60Hz display. Numbers like 80 and 95 FPS were not just wrong, they were physically impossible on that panel — a sanity check I could have run at any point without an AI, and never did. The machine I most wanted to be good was the machine I was least accurate about.
It corrected me upward too. That is what convinced me it was reading rather than flattering. My "conservative" M1 Max Cyberpunk estimate of 35–45 was hiding a real 74 FPS native average. A pessimistic guess is still a guess. The Cyberpunk on Mac page exists in its current form because of that correction — and it inverted the site's assumed narrative, since native Metal (~74) beat CrossOver (~64) on that title, the opposite of what I expected.
What It Cannot Do
An honest limits section, because this tool has a sharp edge.
- It reads the overlay, not reality. If the FPS counter is misconfigured or lying, the AI transcribes the lie faithfully. It is a transcription tool for footage you already trust.
- It cannot tell you whose machine you are watching. This one bit me. One Cyberpunk video in the batch turned out to be a competitor's bench — the speaker daily-drives a Snapdragon X Elite laptop. The HUD numbers were real; the attribution was not. Anything sourced that way is now labeled "community-verified" on this site, and "our test" is reserved for hardware I actually own.
- It cannot resolve configuration ambiguity. It reports the Mac model if it is on screen or spoken. It cannot tell a 24GB M5 Pro from a 48GB one when nothing says so, and that distinction changes conclusions.
- It does not know what a cap is. It faithfully reported 199 FPS and 60 FPS. Recognizing one as a frame cap and the other as a panel limit — rather than as performance results — is still a human judgment call.
What would make this wrong: if the model silently misread blurry or compressed frames and I accepted the output without spot-checking, the pipeline would launder bad numbers into a table that looks more rigorous than hand-typed ones — worse than the problem it fixes, because it wears the costume of evidence. That is why every correction above links to the source video, and why the numbers it produces get a HUD-verified label rather than a claim of authority.
The Workflow This Unlocks
The obvious next step is to stop doing this after publishing. There is no need for a public video at all: the same API accepts a raw capture file uploaded before editing. That reorders the whole process:
- Record the raw benchmark capture.
- Extract the FPS table from the footage while the clips are fresh.
- Write the voiceover around the real numbers instead of around remembered ones.
- Publish the video and the site table row the same day, from one source of truth.
The table stops being a retelling of the footage and becomes a readout of it. Which is what a benchmark table was always supposed to be.
Should You Do This?
If you publish performance numbers of any kind, yes — the economics are absurd in your favor. Five cents to check a video against its own footage is not a hard call. What you should not do is let it grade itself: prompt it to transcribe only, spot-check its output against the frames yourself, and keep the source link next to every number.
The real finding was not that AI can read an FPS counter. It was that my published numbers had drifted from my own evidence, in a consistent direction, on the machine I liked most — and that a $0.44 audit caught what months of good intentions did not.
FAQ
Can AI read FPS from a gaming video? Yes — Gemini 2.5 Flash reads the actual frames from a YouTube URL and transcribes visible HUD values. It read 30.70 → 60.62 FPS off a Metal HUD exactly.
What does it cost? About $0.05 per full-length video. Nine videos ran ~$0.44 total at 2.5 Flash paid-tier rates; a 154-second clip was ~$0.014.
Is the data trustworthy? For reading a number that is on screen, yes. It cannot verify whose machine it is, which RAM configuration, or whether the overlay itself is honest.
Did it find real mistakes? Yes — six pages corrected. Marvel Rivals M5 Air 60→30 and Dota 2 M5 Air 95→60, but also M1 Max Cyberpunk 35–45→74.
Why not just read it yourself? You can, for one clip. At nine videos it becomes a day of tedium that never actually happens — which is exactly why the errors survived.
Every number on this site now traces back to a HUD you can watch yourself — the benchmark table links its evidence video per row, and the by-model pages carry the corrected figures. If you want the raw footage behind any of them, it is all on YouTube. Building something similar, or think I got a reading wrong? Come argue with me in the Discord — corrections welcome, that is rather the point.