Reversing a video takes exactly two filters — reverse for the picture and areverse for the sound — and the command fits on one line. The catch is what happens behind it. reverse has to hold every input frame in memory before it can emit the first output frame, so pushing a long clip or a 4K clip through it eats several gigabytes of RAM and, on many machines, kills the process. This article covers the basic commands, then the peak-memory figures we measured on real hardware, and a split-based procedure for long sources.

Verified: FFmpeg 8.1 on Windows — all 10 commands in this article were executed by the verification script and passed (2026-09-06).

Basic: reverse video and audio together

ffmpeg -i input.mp4 -vf reverse -af areverse output.mp4

-vf reverse handles the video, -af areverse the audio. If you specify only one, you get reversed picture over forward audio — always write them as a pair when you keep the sound.

If you don’t need the audio, dropping it with -an is simpler:

ffmpeg -i input.mp4 -vf reverse -an output.mp4

-c copy is not an option here. Reordering frames means re-encoding, no exceptions.

Reverse only part of a clip

Cut the section you want first, then feed it to reverse. Trimming on the input side with -ss / -t means only the trimmed frames are ever buffered, which also solves the memory problem described in the next section.

ffmpeg -ss 00:00:05 -t 5 -i input.mp4 -vf reverse -af areverse output.mp4

You can also trim inside the filter chain. Use this form when you can’t put -ss on the input (multi-input filter graphs, for example).

ffmpeg -i input.mp4 -vf "trim=0:3,reverse" -af "atrim=0:3,areverse" output.mp4

How much memory does reverse actually use? (measured)

The official docs say only “This filter requires memory to buffer the entire clip, so trimming is suggested” — no numbers. So we took a 1920×1080 / 30 fps / 10-second H.264 clip (300 frames) and measured the ffmpeg process’s peak working set.

Condition Peak RSS Time
No reverse (same settings, re-encode only) 1.0 GB 1.1 s
1080p, 10 s, reverse 1.7 GB 1.5 s
1080p, first 3 s only (-t 3) 1.2 GB 0.7 s
Downscaled to 720p before reverse 0.7 GB 1.2 s
1080p, 30 s (-stream_loop 2, 3 passes) 3.5 GB 4.5 s
1080p, 60 s (6 passes) 6.3 GB 9.4 s
Upscaled to 4K (3840×2160), 10 s 7.3 GB 4.7 s

Test rig: Core i9-14900KF (32 threads) / 128 GB RAM / Windows 11 / FFmpeg 8.1 (gyan.dev full build), encoder libx264 -preset veryfast -crf 23. Measured 2026-09-02.

How to read it:

  • A 1080p yuv420p frame is 1920×1080×1.5 bytes ≈ 3.1 MB. 300 frames ≈ 0.9 GB, which matches the measured increase (1.7 − 1.0 = 0.7 GB) closely.
  • Memory therefore scales with resolution × frame count. 60 seconds costs 6 GB; 4K costs 7 GB for 10 seconds. A one-minute 4K 60 fps phone clip works out to nearly 30 GB and will fail on most PCs.
  • The 1 GB used with no reverse at all is libx264’s lookahead and per-thread buffers — inflated here by a 32-thread CPU.

There are two remedies: trim first (-ss/-t) or shrink first (put scale before reverse). Filter order matters — reverse,scale=... buffers full-resolution frames and only then shrinks them, which achieves nothing.

ffmpeg -i input.mp4 -vf "scale=-2:720,reverse" -af areverse output.mp4

Reverse a long video end to end: split → reverse each piece → concat in reverse order

For anything over a minute, splitting is more reliable than buying RAM.

1. Split into 10-second segments (no re-encode, finishes in a few hundred milliseconds)

ffmpeg -i input.mp4 -c copy -f segment -segment_time 10 -reset_timestamps 1 seg%03d.mp4

Cuts land on keyframes, so segments won’t be exactly 10 seconds each. That doesn’t affect the reversed result.

2. Reverse each segment in a shell loop

for f in seg*.mp4; do ffmpeg -i "$f" -vf reverse -af areverse "rev_$f"; done

Memory per piece caps at 10 seconds’ worth (about 1 GB at 1080p).

3. Build the list in reverse order and concatenate

seg000 is the start of the original, so it must come last. Sort the highest numbers first.

ls rev_seg*.mp4 | sort -r | sed "s/^/file '/; s/$/'/" > list.txt
ffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4

Every piece was encoded with identical parameters, so -c copy joins them cleanly. See Join videos with concat for the details.

Reversed GIF

For a GIF, drop the frame rate and resolution with fps and scale first. That both limits memory and keeps the GIF small.

ffmpeg -i input.mp4 -vf "fps=15,scale=320:-1,reverse" output.gif

A forward-then-backward “boomerang” splits the stream in two with split, reverses one branch, and joins them with concat:

ffmpeg -i input.mp4 -vf "fps=15,scale=320:-1,split[a][b];[b]reverse[r];[a][r]concat=n=2:v=1" output.gif

Boomerang videos and a GIF-vs-MP4 size comparison are covered in Loop and boomerang videos; palette optimisation for better-looking GIFs is in Create GIFs.

Reverse and speed up

Combine with setpts and atempo for a rewind effect. Put them after reverse.

ffmpeg -i input.mp4 -vf "reverse,setpts=0.5*PTS" -af "areverse,atempo=2" output.mp4

See Change video speed for the speed-change details.

Reverse an audio file only

ffmpeg -i input.mp3 -af areverse output.mp3

areverse buffers every sample too, but audio is orders of magnitude smaller than video (one minute of 44.1 kHz 16-bit stereo ≈ 10 MB), so memory is not a practical concern.

FAQ

It dies with “Killed” or “Cannot allocate memory”

As the table shows, every frame handed to reverse sits in RAM. Trim with -t, place scale before reverse, and if that’s still not enough switch to the split procedure. Relying on swap will not finish in any reasonable time.

The reversed audio has a harsh burst in it

If the source fades in at the start, the reversed version fades out at the end — that is expected. A genuinely wrong sound usually means the video was reversed but the audio was left forward (a missing -af areverse).

Can’t I speed this up with -c:v copy?

No. Inter-frame codecs like H.264 store each frame as a difference from the previous one, so changing the order requires a full decode and re-encode.

The Reverse video tool runs this article’s reverse / areverse in your browser; the file never leaves your device. FFmpeg.wasm has the same memory constraint, so it’s meant for short clips.