How to make a timelapse from a video you already recorded

Two different things get called a timelapse. One is shot as a timelapse: the camera takes a single frame every few seconds for an hour and the frames are assembled into a short clip. The other is a normal recording played back very fast. If you have a video file and want a timelapse out of it, you are making the second kind, and it is worth understanding how it differs from the first before you decide how fast to go.

Mechanically it is a speed-up of somewhere between 8× and 16× with the audio dropped. This guide covers what that does to the frames, the FFmpeg command, how to do it in a browser, and what to expect from the file that comes out.

What a real timelapse is, and why yours is different

A camera shooting an interval timelapse exposes one frame every N seconds. One frame every two seconds for an hour is 1,800 frames, which plays back as a minute at 30 fps. Each frame is a proper exposure, and because it can be a long exposure, moving things blur smoothly between frames. Clouds streak; headlights turn into ribbons.

A recording sped up 16× starts from continuous 30 fps footage and keeps one frame in sixteen. Each surviving frame is a 1/30-second-ish snapshot with no blur bridging the gap to the next one. The subject jumps rather than flows. Whether that looks fine or looks wrong depends entirely on how far the subject moves between the frames you kept.

The frame arithmetic

Speeding video up does not change any picture. It changes when each picture is scheduled to be shown, by dividing every frame’s presentation timestamp. At 16× the timestamps are divided by 16, so sixteen source frames now claim to belong in the slot of one output frame, and the encoder keeps one and discards the other fifteen.

They are discarded, not blended. What you see is a genuine sample of the original motion, one frame every so often:

Now apply that to the subject. A cloud, a shadow crossing a floor, a tide, a wall being painted, a plant over a day: these barely move in half a second, so consecutive output frames are close to each other and the motion reads as smooth. A person walking through the shot covers a metre or more in half a second, so they teleport from frame to frame. Traffic strobes. A camera pan stutters.

That is the rule for choosing a factor: a timelapse looks good when the subject moves slowly relative to the interval between the frames you keep. For slow subjects, 16× is fine and often still too slow. For anything with people or vehicles in it, 8× is usually the ceiling before the stepping becomes the thing viewers notice, and for a recording that is mostly people, a timelapse may be the wrong effect altogether.

The slow-motion guide has the same arithmetic from the other direction: slowing down holds frames longer instead of dropping them, and the choppiness has the same cause.

Why not blend the frames?

FFmpeg can average groups of frames together, and motion-interpolation filters can synthesise in-between frames. Both are expensive and neither is what a sped-up timelapse usually needs. Averaging fakes the long-exposure blur of a real timelapse and can look good on traffic and water; it is a stylistic choice, not a fix, and it is out of scope for the tools here.

The audio

At 8× or above there is nothing worth keeping. Pitch-corrected speed-up via atempo is usable up to about 3×, and past that it is usually better to drop the audio; chained to 16× it is noise. Drop it. It also makes the output smaller and removes a stream the encoder would otherwise have to process.

Doing it in FFmpeg

For the whole file at 16×, no audio:

ffmpeg -i input.mp4 -filter:v "setpts=PTS/16" -an -c:v libx264 -crf 23 output.mp4

setpts=PTS/16 is the entire speed change: every timestamp divided by sixteen. -an drops the audio. The encoder receives frames whose timestamps are far too close together for the output frame rate and drops the extras itself, which is the “1 in 16” from the table above.

To scale down at the same time, which you probably want on a 4K source, extend the filter:

ffmpeg -i input.mp4 -filter:v "setpts=PTS/16,scale=-2:1080" -an -c:v libx264 -crf 23 output.mp4

For a factor beyond 16×, just change the divisor. setpts=PTS/60 turns an hour into a minute.

To speed up only a section — the ninety minutes of a build in the middle while the intro and outro stay at normal pace — you need the trim-and-concat filter graph rather than a single filter. The per-section speed guide has that command written out.

There is no -c copy in any of these. The timestamps live inside the compressed stream, so changing speed always re-encodes.

Doing it in the browser

The speed-up tool treats speed as a property of a range:

1. Open the file. It is read from disk into the tab; nothing is uploaded.
2. Add a Speed up band. Drag its handles to cover the whole timeline, or just the stretch that should be a timelapse.
3. Set the multiplier. The maximum per band is 16×. For a classic timelapse pick 8× or 16× according to the table above.
4. Switch on Mute audio. The remove-audio page describes what that toggle does; here it simply leaves the audio out of the output.
5. Set the max resolution to 1080p or 720p if the source is 4K. The encoder then has a quarter or less of the pixels to handle.
6. Apply. One pass, one encode.

If you need more than 16×, run the output through a second time at 2× or 4×. That is a second generation of compression, which is a real cost, but timelapse material tends to hide it well because every frame is already so different from its neighbours.

Two limits worth stating. The encoder runs on your CPU inside the browser, so an hour-long source takes a while even though the output is short — the work is in decoding all the input frames, not in writing the few that survive. And the entire input has to fit in the tab’s memory, so a multi-gigabyte recording is better handled with the FFmpeg command above. Where that memory ceiling actually sits is covered here.

What to expect from the file

The output is one sixteenth as long, so it is much smaller than the source. It is not one sixteenth of the size, for a reason that follows from the frame arithmetic: video compression works by describing each frame as a change from the previous one, and in a timelapse consecutive frames are far apart in time and therefore far apart in content. The encoder has less to reuse, so each second of timelapse costs more bits than a second of the original.

The browser tool’s encoder is tuned for speed rather than efficiency (ultrafast, CRF 28), which pushes the same direction. If the file size matters, capping the resolution does far more than any other setting, and the resize page explains what that cap does and does not change.

The short version

• A timelapse from a recording is an 8×–16× speed-up that keeps one frame in eight to sixteen and drops the rest.
• It looks smooth when the subject moves little between kept frames, and stepped when it moves a lot. Pick the factor by the subject, not by the runtime you want.
• Drop the audio. Nothing survives 8× intact.
• setpts=PTS/16 with -an is the whole thing in FFmpeg; the browser tool does the same with a band on a timeline and no install.