Why your clip shimmers, and how to stop it
Shimmer is usually a frame-rate problem: too many frames starve temporal context. Rates that hold, where the deflicker pass goes, and how to spot compression.
A shimmering clip is one where the picture is fine but the surfaces will not sit still. Brick crawls. Hair sparkles at the edges. A grass field boils. Nothing is obviously wrong in any single frame, which is what makes it maddening — pause the video and it looks clean, play it and the whole image is faintly alive in a way it should not be.
The instinct is to reach for an upscaler, on the theory that a sharper image will be a more stable one. That makes it worse. Shimmer is a temporal problem, and the fixes are a generation-side choice about frame rate and a post-side pass that has to happen before any resolution work.
What shimmer actually is
Every frame of a generated video is produced with some amount of context from its neighbours. That context budget is finite. Ask a model to produce more frames per second of screen time and each frame gets a thinner slice of it, which means the model has less information about what the previous frame decided a surface looked like. It re-decides. Slightly differently. Twenty-five to sixty times a second.
The result is that fine detail, meaning anything with repeating texture at close to pixel scale, becomes unstable frame to frame. Big shapes hold, because the scene constrains them heavily. Detail at the resolution limit does not, because nothing constrains it except the previous frame, and the previous frame is exactly what the model is short of context about.
This is why the standard advice is counterintuitive: generate at a moderate frame rate, not a high one. 24 to 30 fps holds together. 60 starves the temporal context and buys smoothness at the cost of stability. Higher is not better here, and the extra frames are exactly what makes the surfaces move.
The property being described has a name worth knowing, because it is what models are benchmarked on: temporal consistency.
Shimmer versus compression: telling them apart
Before changing anything, work out which of the two you have, because they have opposite fixes and they look superficially similar on a phone.
| Signal | Shimmer (generation) | Compression |
|---|---|---|
| Where it lives | Fine texture: fabric, hair, foliage, brick, water | High-contrast edges, flat gradients, dark areas |
| What it looks like | Detail crawling or sparkling; surfaces boiling | Blocky squares, banding in skies, a fuzzy halo around edges |
| Motion behaviour | Present in still shots as much as moving ones | Worse during fast motion and at scene changes |
| Does it survive re-encode | Yes. It is in the source frames | Changes with bitrate and codec |
| Where you first see it | In the raw generation, before upload | After export, or after the platform transcodes |
The single most useful test: look at the original file, not the uploaded version. If the crawl is present in the raw generation on a local player, it is shimmer and it is yours to fix. If the raw file is clean and the artifact appeared after export or after upload, it is compression, and the fix is bitrate, codec settings and export resolution rather than anything in the generation.
The second test: pause on a still section. Compression artifacts on a static shot largely disappear once the encoder has a stable image to sit on. Shimmer does not — a locked-off shot of a brick wall with nothing moving in it will still crawl, because each frame is being re-decided regardless of whether anything happened.
There is a third category that is neither, and it is worth ruling out early: structural failures that are stable across frames, such as wrong hand geometry, text that is not letterforms, or a face that changed. Those are not shimmer, they do not respond to deflicker, and the tour of which artifacts belong to which family is in why AI video artifacts happen.
Choosing a rate that holds
Most models will not let you choose. Of the 146 video models in Versely's catalog, 48 declare a selectable frame rate at all: 29 of those offer 24 and 30 only, 18 add 60, and exactly one offers 24 and 48. The remaining models render at whatever their pipeline settled on, which means for most of the catalog the rate is a property to know rather than a knob to turn.
Where you do have the choice:
- Default to 24 or 30. This is the stable band. Both are also delivery-standard rates, so you are not creating a conform problem to solve a shimmer problem.
- Reach for 60 only when the motion genuinely needs it, and expect to pay for it in surface stability. Fast sport-like motion is the case that justifies it. A talking head is not.
- Watch for advertised rates that were interpolated up. Some generators produce a modest number of real frames and interpolate to the rate in the header, which means a clip labelled 60 has not necessarily had sixty moments per second decided for it. That matters if you plan to retime later, because you would be interpolating over guesses. Interpolation versus native frame rate has the full comparison.
Two prompt-side habits also reduce shimmer, and they are free:
Avoid asking for texture the model cannot hold. A close-up of chainmail, a field of long grass in wind, a crowd in the mid-distance, water with fine surface detail — these are the shots that shimmer, and specifying them harder does not stabilise them. Wider shots and larger shapes are more stable at any rate.
Do not add unrequested camera movement. Models have a strong prior toward adding motion, and drift across a locked-off frame drags fine detail through the sampling grid, which is a reliable way to make texture crawl. If you want the camera still, say the camera is entirely motionless — omitting movement language does not give you a static shot, as the camera instructions models silently ignore covers in more detail.
Deflicker before upscale, always
If the clip already exists and it shimmers, the fix is a temporal cleanup pass, and its position in the finishing order is not negotiable: deflicker first, then scale.
The reason is mechanical. A spatial upscaler works largely on one frame at a time. Given an unstable texture it solves a slightly different problem on each frame and produces a slightly different answer, so the instability comes out the other side larger and more legible. Shimmer that was mildly irritating at source resolution becomes the most visible thing in the shot at 4K. Every pass you run downstream amplifies what is upstream of it, and shimmer is the artifact this hurts most.
The working order for a shimmering clip:
- Confirm it is shimmer, using the raw-file and still-section tests above.
- Deflicker at source resolution. Cheap, and its input is the cleanest version of the footage that will ever exist.
- Colour match across clips if the piece is a sequence, before any resolution change.
- Scale, if the destination genuinely uses the resolution. Upscaling video to 4K is the one-step version, and the upscaling glossary entry is clear that the operation does not recover detail that was never rendered.
- Sharpen last, and lightly. Sharpening amplifies frame-to-frame differences, so it is entirely possible to reintroduce shimmer at the final step on a clip you successfully cleaned at the first. If that happens, sharpen less rather than deflickering again.
The assembly and the finishing passes sit on one EDL-based timeline in the AI video editor, so this is a sequence of decisions on a re-renderable object rather than a stack of intermediate exports.
One thing the 480p preview pass will not settle: shimmer lives in fine detail, and fine detail is the first thing a downscale removes. The free preview is excellent for timing, drift and structure, and it is the wrong tool for judging whether a texture is stable. Judge shimmer on the source file at full resolution before you commit to a finishing plan.
FAQ
Will upscaling fix a shimmering clip?
No, and it reliably makes it worse. Upscalers amplify what they are given without distinguishing detail from instability, and because most of them work largely frame by frame, an unstable texture gets a slightly different treatment on every frame. Run the temporal cleanup at source resolution first; then scale, if the destination actually needs it.
Is 60 fps always a bad idea for generated video?
Not always, but it is a trade rather than an upgrade. More frames per second of screen time means less context per frame, which is what destabilises fine texture. Reach for it when the motion genuinely benefits — fast movement where you can see the strobe at 24 — and stay at 24 or 30 otherwise. Most models do not expose the choice anyway, so for the majority of the catalog this decision is made for you.
How do I know whether it is shimmer or my export settings?
Play the raw generation from a local file before it has been exported or uploaded. Shimmer is baked into the source frames, so it is present there. Compression artifacts are not — they appear at export or after a platform transcodes the upload, they cluster on high-contrast edges and flat gradients rather than on fine texture, and they change when you change bitrate. A locked-off shot with a textured surface in it is the best single test clip, because compression settles on a static image and shimmer does not.
Does a deflicker pass cost me detail?
Some, and that is the trade. Temporal cleanup works by reconciling each frame against its neighbours, which necessarily softens detail that genuinely changes frame to frame along with the detail that should not have. Run it at the lowest strength that stabilises the surface rather than the highest setting available, and check a moving section as well as a static one — an over-strength pass shows up first as smearing behind anything that moves quickly.