Why slowed-down video looks choppy (and what to do about it)

You slow a clip to a quarter speed, expecting the smooth, weighty look of proper slow motion, and instead you get something that stutters. Nothing is broken. You have just run into the one piece of arithmetic that governs every slow-motion effect, and it is worth understanding because it tells you exactly what is and is not achievable after the fact.

The arithmetic

A video has a frame rate: 30 frames per second is typical for a phone or a screen recording, 24 for cinema-style footage, 60 for smoother capture.

Slowing a clip down does not manufacture new pictures. It stretches the existing ones over more time. Each frame is simply displayed for longer.

So if you take 30 fps footage and slow it to 0.25×, you now have thirty frames spread across four seconds instead of one. The effective rate of new information is:

30 fps × 0.25 = 7.5 new frames per second

Seven and a half distinct pictures per second is around the threshold where human vision stops reading motion as continuous and starts reading it as a sequence of stills. That is the choppiness. It is not an artefact of the tool — it is the source footage, honestly stretched.

Here is the same calculation across the settings you are likely to use:

Read that table as “distinct pictures per second in the result”. Above about 24 it looks like video. Between 12 and 24 it looks deliberate and slightly filmic. Below 12 it looks broken.

The useful conclusion: the frame rate you shot at sets a hard budget for how far you can slow the footage down. A 30 fps recording has a comfortable floor around 0.5×. A 240 fps recording can go to 0.1× and still look like real video, which is precisely why phones offer a high-frame-rate slow-motion capture mode.

What the tool actually does

Mechanically, slowing down is the same operation as speeding up with a factor below one.

Every decoded frame carries a presentation timestamp saying when to display it. Dividing those timestamps by 0.5 doubles them, so each frame is shown twice as far into the clip as before, and the segment lasts twice as long:

setpts=(PTS-STARTPTS)/0.5

The output still has a frame rate to fill. Since there are not enough distinct frames to fill it, frames are repeated — held on screen across multiple output frames. Nothing is invented; existing pictures are duplicated.

Audio is handled separately, by atempo, which stretches tempo without dropping the pitch. That is why slowed speech sounds like someone talking slowly rather than a record played at the wrong speed. A single atempo instance handles down to 0.5×, so lower factors are produced by chaining instances — 0.25× is atempo=0.5,atempo=0.5. The editor here builds that chain automatically for whatever factor you type.

Be aware that heavily stretched audio develops a distinctive smeared, reverberant quality. Below about 0.5× it is usually better to mute the section and let the picture carry it.

Why frame interpolation is not a free fix

There is a technique that does invent new frames: motion-compensated frame interpolation. It estimates how each part of the picture moved between two real frames and synthesises the in-between pictures. FFmpeg has it as the minterpolate filter; commercial editors sell versions of it under names like optical flow.

It is not offered here, and the reasons are worth stating rather than hiding.

It is extraordinarily slow. Motion estimation over every pixel of every frame pair is orders of magnitude more expensive than decoding and re-encoding. In a browser tab running a WebAssembly build on your own CPU, a clip that currently takes thirty seconds would take a very long time indeed.

It fails visibly on ordinary footage. Interpolation works well on smooth, predictable, well-lit motion. It produces warping and smearing artefacts around occlusion — where one object passes in front of another — around fast small objects, on motion blur, and on cuts. A lot of real footage is full of exactly those things.

It does not recover information that was never captured. A frame that was not recorded contains no data. Interpolation makes a plausible guess. Sometimes the guess is convincing and sometimes it invents something that was not there.

If you need genuine, smooth slow motion, the reliable answer is still to capture it: shoot at 120 or 240 fps and slow it afterwards. Every phone made in the last several years can do this, it is one setting, and the result is real frames rather than estimated ones.

Getting the best result from footage you already have

Stay at 0.5× or above for 24–30 fps source. This is the single most useful rule. At 0.5× a 30 fps clip still delivers 15 distinct frames per second, which reads as deliberate rather than broken.

Slow a short moment, not a long stretch. The choppiness is much more forgivable over one second than over fifteen. Mark a tight range on the timeline rather than slowing the whole clip — everything outside the band keeps playing normally.

Choose the section for its motion. A slow, smooth movement — a hand reaching, a door closing, a face turning — survives being stretched. A fast pan, a whip, a bounce, or anything with heavy motion blur does not.

Mute below 0.5×. Stretched audio stops helping well before the picture does.

Do not slow footage that is already slow motion. Phone slow-mo clips are usually stored at a normal frame rate with the slowdown already baked in, so slowing them again is stretching an already-stretched clip. Check the properties before assuming you have 240 fps to spend.

Combine, do not stack. If you want to slow one part and speed up another, put both bands on the same timeline and apply once. One pass means one generation of re-compression instead of two.

In FFmpeg

The same operation on the command line, slowing 0:10–0:15 to half speed and leaving the rest alone:

ffmpeg -i input.mp4 -filter_complex "\
[0:v]trim=0:10,setpts=PTS-STARTPTS[v0]; \
[0:a]atrim=0:10,asetpts=PTS-STARTPTS[a0]; \
[0:v]trim=10:15,setpts=(PTS-STARTPTS)/0.5[v1]; \
[0:a]atrim=10:15,asetpts=PTS-STARTPTS,atempo=0.5[a1]; \
[0:v]trim=15,setpts=PTS-STARTPTS[v2]; \
[0:a]atrim=15,asetpts=PTS-STARTPTS[a2]; \
[v0][a0][v1][a1][v2][a2]concat=n=3:v=1:a=1[v][a]" \
-map "[v]" -map "[a]" output.mp4

Note the absence of -c copy. Speed changes rewrite timestamps inside the stream, so there is no lossless version of this operation — unlike an end trim, which can be done without re-encoding at all.

To try it without installing anything, slow a section of your own video here. Nothing is uploaded; the work happens in the tab, and the mechanism is documented in full.