Metric v6.9 (iOS) and v1.2 (Android): faster video processing and improved tracking accuracy
Two things changed in v6.9 and v1.2: how fast Metric processes imported video, and how accurately it measures barbell velocity — especially peak velocity. Here is the data behind both.
We shipped v6.9 on iOS and v1.2 on Android this month. Two things improved: how fast Metric processes your imported sets, and how accurately it measures what matters.
This post covers both with the actual numbers. We have run a permanent regression and benchmarking suite against these changes, so the numbers below are measured, not estimated.
Faster video processing
Import processing time is what you feel when you finish a set, import the video, and wait for results. Before v6.9, a standard 17-second deadlift set at 1080p60 took around 41 seconds to analyse on iOS. That is 2.4× the clip length.
Before and after
| Video | Length | iOS before | iOS after | iOS gain | Android before | Android after | Android gain |
|---|---|---|---|---|---|---|---|
| Deadlift set, 1080p60 | 17 s | 41.2 s | 25.5 s | −38% | 55.1 s | 46.0 s | −17% |
| Deadlift set 2, 1080p60 | 20 s | 44.6 s | 28.6 s | −36% | 59.6 s | 52.6 s | −12% |
| Long set, 13 reps, 1080p60 | 43 s | 50.3 s | 34.2 s | −32% | 102.5 s | 87.8 s | −14% |
| 4K low-light set | 20 s | ~unchanged | ~unchanged | — | 36.2 s | 35.4 s | −2% |
In throughput terms, iOS now processes 39.5 frames per second on a standard deadlift set, up from 23 — roughly 1.7× faster. Android moved from 18.3 to 21.9 frames per second.
Note on iOS figures: these were measured on the iOS Simulator on an M-series Mac. The relative improvement (−32–38%) reflects what the code change delivers; absolute seconds on your iPhone will differ by device generation. Android figures are from a real-device Samsung Galaxy S23 Ultra. 4K imports are limited by video decoding, not our processing pipeline — already fast and unchanged.
On Android, the changes also freed approximately 190MB of GPU memory — previously held by dead allocations that were never being used. That headroom matters most on mid-range devices.
What we actually changed
Profiling every stage of the pipeline on both platforms showed that processing cost was not driven by video resolution. It was driven by scene complexity — a busy gym frame produces thousands of edge fragments, and the code that tests which fragments combine into a plate-shaped ellipse was doing far more work than necessary.
Three fixes delivered nearly all the gain:
1. Stopped repeating identical geometry work. The candidate-matching step compared every fragment trio, recomputing the same fragment-pair overlap thousands of times per frame. We cache each pair result and compute it once — same answer, a fraction of the work. This alone made the hottest stage 40% faster.
2. Replaced a brute-force scan with a lookup table. Detecting the concentric rings printed on weight plates compared every point of every fragment against every other point. A hash-table lookup gives the identical result 64% faster.
3. Deleted work nobody used. Every imported frame ran a full-image pixel scan whose only purpose was one diagnostic log line per second. On Android that wasted 13–16ms per frame — roughly a quarter of the real-time budget.
The GPU experiment we built and killed
We also built and fully tested a GPU-accelerated contour extractor. It worked correctly, and in simulation it halved CPU load. Then we measured it on real hardware — and it made imports 35% slower. Mobile chips are bottlenecked by the GPU pipeline, not the CPU. We removed it and documented why, so the effort does not get repeated. Every change in this work, kept or killed, was decided by measurement on real workloads.
Accuracy improvements
The accuracy work targeted peak velocity specifically, while holding mean velocity flat. Mean velocity was already strong; the problem was peak.
Headline before and after
The numbers below cover the full 234 Metric recordings in our June 2026 internal validation session (bench, deadlift, squat, cleans, jumps; multiple phone setups per set), compared against a GymAware tether unit as ground truth.
| Metric | Before | After | Change |
|---|---|---|---|
| Mean velocity CCC | 0.970 | 0.977 | +0.007 |
| Mean velocity MAE | 0.067 m/s | 0.061 m/s | −9% |
| Peak velocity CCC | 0.910 | 0.957 | +0.047 |
| Peak velocity MAE | 0.202 m/s | 0.142 m/s | −30% |
| Peak velocity bias | −0.19 m/s | −0.09 m/s | −53% |
At gold-standard positioning (perpendicular, 1080p60), peak velocity improved further: CCC 0.984 → 0.993, bias −0.078 → −0.010 m/s — statistically indistinguishable from the tether unit.
Per-condition improvement: peak velocity
| Condition | n reps | MAE before | MAE after | Change |
|---|---|---|---|---|
| Gold standard (perpendicular, 1080p60) | 63 | 0.080 m/s | 0.052 m/s | −35% |
| 45° camera angle | 48 | 0.189 m/s | 0.156 m/s | −17% |
| Low angle (phone on floor) | 13 | 0.317 m/s | 0.105 m/s | −67% |
| 30fps recordings | 45 | 0.353 m/s | 0.292 m/s | −17% |
| 720p / 4K resolution | 39 | 0.350 m/s | 0.242 m/s | −31% |
| Dim / backlit / glare | 30 | 0.147 m/s | 0.111 m/s | −24% |
| Distance extremes + clutter | 22 | 0.045 m/s | 0.043 m/s | — |
| Jumps | 30 | 0.149 m/s | 0.124 m/s | −17% |
Per-condition improvement: mean velocity
Mean velocity was already near its ceiling across most conditions. The biggest gain was in low-angle recording, which had a specific geometric cause that is now corrected.
| Condition | n reps | MAE before | MAE after | Change |
|---|---|---|---|---|
| Gold standard (perpendicular, 1080p60) | 63 | 0.045 m/s | 0.041 m/s | −9% |
| 45° camera angle | 48 | 0.042 m/s | 0.045 m/s | — |
| Low angle (phone on floor) | 13 | 0.106 m/s | 0.043 m/s | −59% |
| 30fps recordings | 45 | 0.092 m/s | 0.088 m/s | — |
| 720p / 4K resolution | 39 | 0.108 m/s | 0.090 m/s | −17% |
| Dim / backlit / glare | 30 | 0.043 m/s | 0.045 m/s | — |
| Distance extremes + clutter | 22 | 0.034 m/s | 0.033 m/s | — |
What we changed
1. Peak velocity recovery. The motion smoothing that makes bar paths stable was also shaving the top off every velocity peak — roughly 4% on slow lifts, and up to 25% on explosive movements at 30fps. Peaks are now re-measured from a second, lighter-smoothed reconstruction of the bar path, blended in proportion to how trustworthy the sharper estimate is at the video’s frame rate. The smoothed path still drives everything else; only peak measurement uses the secondary estimate.
2. 30fps undersampling. Imported 30fps footage was having its frame gaps filled by straight-line interpolation before analysis — which flattens genuine peaks. Peak measurement now works from the actual camera samples only. 30fps is still worse than 60fps for peak velocity (as the per-condition table shows), but the previous approach was making it worse than it needed to be.
3. Camera-tilt correction for imported video. A phone placed on the floor angled up at the bar compresses all vertical motion by the cosine of the tilt. Live recording corrects this automatically using the phone’s IMU. Imported video has no sensor data, so low-angle imports were under-reading mean velocity by 10–12%. The tilt is now estimated from the shape of the plate itself — how elliptical it appears in frame and in which direction — and the vertical axis is rescaled. Peak velocity on low-angle imports dropped from 0.317 m/s MAE to 0.105 m/s. Mean velocity dropped from 0.106 to 0.043 m/s.
This correction is import-only by design. Side-angle (45°) recordings are correctly left alone — the plate ellipse distinguishes vertical tilt from horizontal angle.
4. Rep ordering fix. When the detector recovered a quieter rep after its louder neighbours in a set, it could file that rep out of chronological order — corrupting rep numbers, eccentric pairing, and velocity-loss calculations. Reps are now always chronological. This affects rep numbering, per-rep trends, and any coaching metric that depends on rep sequence.
What is still a known limitation
30fps explosive peaks. At 0.292 m/s MAE, 30fps remains the weakest condition for peak velocity tracking. The frame rate simply cannot capture the true peak on a fast movement. If peak velocity is important to your training data, use 60fps.
Jump mean velocity. Mean velocity on jump training reads approximately 10% below GymAware across all conditions, including gold standard — and this did not change in v6.9. We believe this reflects a definitional difference in how GymAware windows the concentric phase on jumps rather than a Metric tracking error: the reading is internally consistent across reps and conditions, but it diverges from the tether measurement. We are not making changes to jump MV until we can isolate the definitional question.
Live-recording validation. All accuracy figures above are for the import pipeline (video recorded and imported via camera roll). Live recording shares the peak velocity recovery and rep ordering fixes, but the camera-tilt correction is import-only. A live-recording validation session against GymAware is planned.
What is next
We are not done. The permanent benchmarking and regression suite we built for this work — 39 ground-truth videos, one command, 28 minutes — now gates every future tracking change on real output rather than theory. If it does not show up in the measured numbers, it does not ship.
The next targets: better 30fps explosive peak measurement, full 1080p processing for sharper bar-path tracking, and live-recording validation.
If you are running a training study and want to measure alongside the next round of improvements, see the research page.