How to speed up only part of a video

Almost every free online video tool that offers “change speed” offers exactly one speed, applied to the entire file. That is the wrong shape for the most common reason people want it. Nobody wants their whole tutorial at 4×. They want the ninety seconds where an installer is grinding away at 4×, and everything either side of it left alone.

This is what that operation actually is, what it costs, and two ways to do it.

Why “one speed for the whole file” is the wrong tool

Think about the recordings people actually try to speed up:

• A screen recording with a long build, install or render in the middle.
• A tutorial where a step is mechanical and slow but the explanation around it is not.
• A demo where you walk from one thing to another and nothing happens in between.
• A meeting recording where one segment is worth keeping at normal pace and the rest is skimmable.

In every case the video has a shape: normal, fast, normal. A global multiplier flattens that shape. Speed the whole thing to 2× and your narration is now 2× too, which is exactly the part you needed intelligible.

The workaround people are usually pushed into — split into three files, speed up the middle one, re-join — works, but it means three exports and therefore three generations of re-compression on footage that only needed one.

What “speeding up” actually does

Under the hood, changing playback speed is not a change to the pictures. It is a change to when each picture is supposed to be shown.

Every frame in a decoded video carries a presentation timestamp (PTS) saying when to display it. To play a segment twice as fast, you halve every timestamp in it. In FFmpeg that is one filter:

setpts=(PTS-STARTPTS)/2

PTS-STARTPTS rebases the segment so it begins at zero — necessary, because a segment that starts 30 seconds into the source still believes it starts at 30 seconds, and a player handed that will sit on a black frame waiting. Dividing by 2 is, quite literally, the whole speed-up.

Frames are dropped, not blended

The output still has a frame rate to hit. If you compress 60 seconds of 30 fps footage into 15 seconds, you have 1,800 source frames to fit into 450 slots — so roughly three out of every four frames are discarded.

They are discarded, not averaged together into new intermediate frames. This is the correct behaviour for a time-lapse and it is what you want almost all of the time. It is also why a heavily sped-up camera pan looks slightly steppy rather than smoothly fast: you are seeing a genuine sampling of the original motion, not a synthesised one.

(Frame interpolation — inventing plausible in-between frames — is a different, much more expensive operation, and it is the thing you want for slow motion on low-frame-rate source, not for speed-ups.)

The audio problem, and why it is not a chipmunk

Naively speeding up audio means playing the samples faster, which raises the pitch. That is the tape-on-fast-forward sound, and it makes speech unusable above about 1.3×.

FFmpeg’s atempo filter solves this properly. It changes tempo while holding pitch constant, so sped-up speech sounds like the same person talking faster rather than a cartoon. It is the difference between a 2× section you can still follow and one you have to mute.

The classic constraint on atempo is that a single instance handles a factor between 0.5 and 2.0. Anything beyond that is done by chaining instances, because the factors multiply:

atempo=2.0,atempo=2.0            → 4×
atempo=2.0,atempo=2.0,atempo=2.0 → 8×
atempo=2.0,atempo=1.5            → 3×

The editor on this site builds that chain for you from whatever multiplier you type, so 6.4× is as valid an input as 2×.

Practically, atempo starts to sound clipped and artefacty somewhere around 3×. That is a property of the technique, not a bug. Past that point, consider whether you want the audio at all — muting a sped-up section is often the better call, and if the section is genuinely worthless, cutting it out entirely is cheaper than compressing it.

Doing it in the browser

The editor here treats speed as a property of a range, not of the file:

1. Open your video. MP4, MOV, MKV, WebM and AVI are all read directly off your disk — there is no upload.
2. Scrub to where the slow part starts, right-click the timeline and choose Speed up. A green band appears.
3. Drag the band’s handles, or type start and end seconds, until it covers exactly the stretch you want accelerated.
4. Pick a multiplier — 1.5×, 2×, 4×, 8×, or any value from 1.1× to 16×.
5. Add more bands if the recording has more than one slow patch. You can mix them with cuts and slow-downs on the same timeline.
6. Apply. Every band becomes part of one filter graph and the file is encoded once, not once per edit.

That last point is the reason to do it this way rather than as three separate exports: stacking edits into a single pass means a single generation of re-compression no matter how many sections you touched.

Doing it in FFmpeg

Same operation on the command line. Say you want 0:00–0:30 normal, 0:30–1:30 at 4×, and everything after 1:30 normal again:

ffmpeg -i input.mp4 -filter_complex "\
[0:v]trim=0:30,setpts=PTS-STARTPTS[v0]; \
[0:a]atrim=0:30,asetpts=PTS-STARTPTS[a0]; \
[0:v]trim=30:90,setpts=(PTS-STARTPTS)/4[v1]; \
[0:a]atrim=30:90,asetpts=PTS-STARTPTS,atempo=2.0,atempo=2.0[a1]; \
[0:v]trim=90,setpts=PTS-STARTPTS[v2]; \
[0:a]atrim=90,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

Three segments, cut with trim / atrim, each rebased to zero, the middle one retimed, then all three concatenated back into a single stream. Extending it to more sped-up sections is a matter of adding more trim pairs and raising n=.

Note what is not in that command: -c copy. You cannot stream-copy a stream you are filtering, so this always re-encodes. There is no lossless way to change speed — the timestamps live inside the compressed stream, and rewriting them means rebuilding it.

Picking a multiplier

A useful rule: if you would still like viewers to hear the sped-up section, stay at or below 2×. If it exists only so the viewer knows time passed, go as high as you like and drop the audio.

What this does to file size

A sped-up section is shorter, so it contains fewer seconds of content and the file usually shrinks roughly in proportion. But speed is a poor size-reduction tool if size is what you actually care about — capping the output resolution does far more, far faster, because the encoder has a quarter of the pixels to deal with at 720p versus 4K.

And if a section is not worth watching at any speed, removing it is strictly better than compressing it: a cut takes it to zero seconds rather than to a fraction of them.

The machinery for all of this — the WebAssembly build of FFmpeg, the filter graph construction, why the first edit takes a moment to start — is described in how browser video editing works. Or just open a file and try it; nothing is uploaded either way.