We Analyzed 2,039 Shaky Videos. Almost All of Them Were Under a Minute.

Every figure below is measured on VidClean's own traffic and hardware. Quote any of them with attribution.

• 87.7% of stabilized videos are under one minute long (1,789 of 2,039 jobs). Not one ran past five minutes.
• One upload in seven is 4K or larger (173 of 1,210 measured jobs, 14.3%), because phones record that way by default, not because the footage is cinematic.
• Stabilizing 4K costs about 3.3 times what 1080p costs: a median 8.52 seconds of compute per second of 4K video, against 2.61 seconds at 1080p, measured across 760 production jobs.
• Frame rate matters nearly as much as resolution. 1080p at 60fps costs more to stabilize than 1440p at 30fps. Cost tracks pixels per second, not pixels: the correlation is 0.92.
• When people change the default strength, they turn it up, not down, by about 7 to 1 (617 chose strong, 91 chose subtle).
• 64.5% of shaky footage is 30fps and only 12.0% is 60fps, across 39 distinct frame rates.

Job counts and strength cover July 20 to August 17, 2026 (n=2,039). Resolution and frame rate cover August 5 to 17 (n=1,210). Cost figures come from production logs, August 11 to 17 (n=760). The three samples are different sizes and are never mixed. See methodology.

Of the 2,039 videos stabilized in the window, 1,789 were under one minute long.

87.7%

of videos people stabilize are under one minute long

1,789 of 2,039 jobs, July 20 to August 17, 2026

Camera stabilization exists because of tripods, gimbals, dollies and Steadicams: the equipment of long takes. The demand we see is the opposite. It is a handful of seconds shot while walking, one-handed, with no rig, and noticed only afterwards. The median job in the production logs is 17 seconds of video.

The remaining 250 videos all fall between one and five minutes. Nothing longer exists in the data, and the obvious objection is that this is the product's doing, since stabilization currently caps at five minutes on the free tier and nine on Pro. But that cap was 30 minutes until July 28, which covers the first eight days of this window, and not one video over five minutes was uploaded even then. The ceiling is where people already were.

Short clips are also the least efficient case per second of footage. Both passes carry fixed overhead: fetching the file, probing it, writing the output. On a 17-second clip that overhead is a meaningful share of the job. The absolute numbers stay small, so nobody notices, but the typical stabilization job is not just short, it is short in the way that wastes the most work per second delivered.

The tool offers three strengths: subtle, normal and strong. Normal is preselected when the page loads.

Normal (default)

1,331 · 65%

Strong

617 · 30%

Subtle

91 · 4%

Bar length is the share of all 2,039 jobs. Percentages are rounded and sum to 99.

The honest way to read this chart is to ignore the top bar. Normal is what the radio button was already set to, so 65% measures a default, not a preference, and plenty of those 1,331 people never looked at the control.

The informative number is the comparison between the two deliberate choices. 708 people changed the setting, and of those, 617 went stronger against 91 who went gentler: a ratio of about 7 to 1. That is the one figure here no default can explain, because reaching either option takes the same single click. It is also the figure least exposed to our own test traffic, which always runs at the default and therefore cannot touch it.

It runs against how the setting is usually described. Stabilization documentation tends to warn about overcorrection: too much smoothing crops the frame harder, warps straight lines, and produces the floating look people call the jello effect. The standard guidance is to use the least correction that works. What people actually do, when they touch the control at all, is ask for more.

My read, and the data cannot confirm this, is that the two groups are answering different questions. Someone who reaches for subtle is protecting deliberate camera movement they want to keep. Someone who reaches for strong has already watched the normal result and found it insufficient. With handheld phone footage, which is most of what arrives, the second situation is simply more common.

On August 5 we started recording the resolution and frame rate of each incoming video. Over the 1,210 jobs measured since:

Below 720p

126 · 10%

720p

202 · 17%

1080p

675 · 56%

1440p

34 · 3%

4K

172 · 14%

Above 4K

1 · under 1%

Bar length is the share of all 1,210 measured jobs. Resolution is bucketed by the short side of the frame, so a vertical 1080 by 1920 phone video counts as 1080p. Percentages are rounded and sum to 100.

1080p being the plurality surprises nobody. The interesting figure is near the bottom: 173 of these videos, 14.3%, were 4K or larger. Roughly one upload in seven.

Those two findings sit oddly together. The same dataset says the typical stabilization job is a sub-minute handheld clip, and that a seventh of those clips arrive at 4K. Both are true, and the explanation is mundane: modern phones default to recording at high resolution. Nobody chose 4K for its cinematography. It is what the camera app was already set to.

Frame rates say the same thing from another angle. 780 of the measured videos are 30fps, 64.5%, against 145 at 60fps, 12.0%. We logged 39 distinct frame rates in total, and the tail is full of values no camera produces: 28, 29, 31, 32, a couple at 1fps, one file claiming 500. Those are bad container metadata rather than real footage, which is its own signal about where these files have been.

Because vidstab reads every frame twice, stabilization is one of the more expensive things you can do to a video on a CPU. To find out how expensive, we parsed 760 completed jobs out of the production worker's own logs, covering August 11 to 17. Cost below is the ratio of processing time to video length: 2.61 means a one-minute video took two minutes and thirty-seven seconds of compute.

Resolution	Share of uploads	Median cost	Jobs timed
Below 720p	10%	0.54	68
720p	17%	1.03	124
1080p	56%	2.61	439
1440p	3%	4.16	15
4K and above	14%	8.52	114

Cost is median seconds of processing per second of video. Upload shares come from the usage counters (n=1,210); costs come from production logs (n=760). They are different samples and should not be cross-multiplied. Hardware is a shared 24-core container running two jobs at a time, so these include real-world contention.

Each step up the ladder roughly doubles the cost, and 4K lands at about 3.3 times 1080p. In practical terms, a 30-second 4K clip needs a little over four minutes of compute; the same clip at 1080p needs about 80 seconds. Across the whole sample the spread between the cheapest and most expensive job is roughly a thousandfold.

But resolution alone turns out to be a mediocre predictor, and this is the finding I did not expect. Frame rate matters nearly as much:

	30fps or below	55fps or above
1080p	2.36	4.64
4K	7.87	14.76

Median seconds of processing per second of video. Cell sample sizes are 322 and 78 for 1080p, 96 and 13 for 4K. The 4K high-frame-rate cell is small.

Doubling the frame rate costs about as much as a large step up in resolution. A 1080p clip at 60fps is more expensive to stabilize than a 1440p clip at 30fps. The cleanest way to state it: cost tracks pixels per second, not pixels. Regressed against width times height times frame rate, the correlation is 0.92 across all 760 jobs, which is far tighter than resolution or duration alone gives.

That is a more useful rule than the usual advice, and it is actionable in the wrong direction from what people expect. If a clip is too expensive to process, halving the frame rate helps roughly as much as dropping a resolution tier, and it is usually the less visible sacrifice on handheld footage.

One optimization mattered a lot here. The measuring pass does not need full resolution to track camera motion accurately: it can analyze a downscaled copy, as long as the resulting motion data is scaled back up to the original frame size before the second pass applies it. On 4K footage that cut the measuring pass by about 94%, from a median 4.23 seconds of compute per second of video to 0.263, while retaining between 93% and 107% of the shake reduction that full-resolution analysis achieved.

There is a trap in that technique worth writing down, because it cost us a day. If you hand ffmpeg's vidstabtransform a motion file measured at the wrong resolution, it does not complain. It exits successfully, prints no warning, and writes a video that is not stabilized at all. Combined with the sharpening the second pass applies, the output can look worse than the input while every status code reports success. Any pipeline doing downscaled analysis needs an explicit assertion that the rescale happened, and a fallback to full-resolution analysis if it did not.

The second pass is where the remaining time goes: it is 79% of total job time at the median, and unlike the measuring pass it cannot be cheated with a downscale, because it has to touch every real output pixel. That sets a hard ceiling on high-resolution work. With a 25-minute processing budget and 4K running between 8 and 15 times realtime depending on frame rate, the budget covers roughly one to three minutes of 4K footage, so any video whose short side is 1440 pixels or more is capped at 90 seconds. Free and Pro get the same limit there, because the constraint is arithmetic rather than a product decision.

VidClean deletes uploaded files within an hour of processing and keeps no per-file records, so the usage half of this analysis is built on aggregate counters. When a stabilization job completes, the backend increments a few running totals: one for the strength chosen, one coarse duration bucket, one resolution bucket, the integer frame rate, and one bucket for how long the measuring pass took. No filenames, no user identifiers, no timestamps, and no per-video rows exist anywhere. No individual upload can be reconstructed from the data, and the analysis is limited to exactly the cuts shown above.

There are three different windows above and they are not interchangeable. Job counts, strength and duration cover July 20 to August 17, 2026, which is when the job counters shipped, and total 2,039 jobs. Resolution and frame rate cover August 5 to August 17, because that instrumentation shipped later, and total 1,210 jobs. Every resolution and frame-rate percentage in this post is a share of 1,210, never of 2,039.

The cost figures are a separate measurement again, and a different kind of data: 760 job records parsed from the production worker's logs between August 11 and August 17, each carrying a job identifier, the source dimensions and frame rate, the video length, and the time each pass took. August 11 is when per-job identifiers were added to those log lines; before that, with two jobs running at once, timings could not be attributed to the right job reliably, so earlier records were excluded rather than guessed at. All cost figures are medians unless stated, measured after the downscaled-analysis change described above, on a shared 24-core container running two stabilization jobs at a time. A different machine would give different absolute numbers. The ratios between resolutions and frame rates are the transferable part.

Two disclosures. First, VidClean's own automated production tests run through the same pipeline, roughly one synthetic 11-second 640 by 360 clip at the default strength per test run. They inflate the sub-minute bucket, the below-720p bucket, the 30fps bucket and the default-strength bucket. Excluding a deliberately generous estimate of that test volume, more test runs than we actually performed, the sub-minute share is 87.3% and the 4K share rises to 14.7%, so both headline figures survive. The 7-to-1 strength ratio is untouched, because test jobs only ever use the default. The log sample also contains some of our own quality-assurance jobs, which is why upload shares in this post come from the counters and never from the logs; a test 4K job costs what a user's 4K job costs, so the per-job cost figures are unaffected.

Second, stabilization caps file length at five minutes on the free tier and nine minutes on Pro, with a 90-second cap above 1440p that applies identically to both tiers. The duration distribution should be read as a distribution over videos that fit those caps, with the caveat noted earlier that the cap was 30 minutes for the first eight days of the window and nothing over five minutes appeared even then.

The full counter dump behind this post is available as a CSV file, with the applicable window and sample size on every row.

This data is licensed CC BY 4.0. Feel free to reuse the numbers with credit to VidClean.

This is VidClean's user base, not a random sample of anyone's video. People who upload to a free web stabilizer already believe they have a shake problem, and they skew toward exactly the phone-clip case the data shows. Someone stabilizing a long handheld take in Resolve or Premiere never appears here. I make no claim that these proportions describe all shaky footage.

The counters pool things this post would like to split. Resolution, duration, frame rate and strength are each counted independently and never together, so I cannot tell you whether 4K uploads are shorter than 1080p uploads, or whether people pick strong more often on phone footage. That also means no figure for 4K's share of total compute is possible from the counters, only the per-second ratio from the logs. The joins do not exist in the data, by design.

Duration is bucketed coarsely enough that "under one minute" hides a lot. A three-second clip and a fifty-second clip land in the same bucket, and given how much fixed overhead a short job carries, that distinction matters for cost. A finer bucket would be worth having.

The cost table's thin cells deserve care. Only 15 timed jobs sit in the 1440p row and only 13 in the 4K high-frame-rate cell, so those two numbers are indicative rather than settled. The 1080p and 4K rows, at 439 and 114 jobs, are solid.

And a four-week window is what it is: long enough for 2,039 jobs, short enough that the resolution figures, drawn from under two weeks, and the cost figures, drawn from one, deserve a re-check once they have a longer run behind them. The counters keep running. When they say something new, we will write it down.

If the data suggests anything practical, it is that your footage is probably typical: a short handheld clip, shot at whatever resolution and frame rate your phone defaulted to, and normal is a reasonable first try. If the result still moves too much, the 7-to-1 ratio above says most people who reached for strong were right to.

You can stabilize a video here, free in the browser, with no account needed. Videos above 1440p are limited to 90 seconds for the timing reasons described above, so if you have a long 4K clip, exporting a 1080p copy first will let it through and will finish more than three times faster. If it was shot at 60fps and the motion allows it, halving the frame rate buys you about as much again.

VidClean is a solo project. Questions about the data or the methodology are welcome at hello@vidclean.net.