Two filters reverse a video: reverse for the picture and areverse for the sound. The command fits on one line. But reverse has to hold every input frame in memory before it can output the first frame. A long clip or a 4K clip can use several gigabytes of RAM, and on many computers the process is killed when memory runs out.

Basic: reverse video and audio together

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

-vf reverse reverses the video and -af areverse reverses the audio. With only -vf reverse, the picture runs backwards while the sound still plays forwards. When you keep the sound, always use both.

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

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

You can’t use -c copy (copying without re-encoding) here. Changing the order of frames always needs a re-encode.

Reverse only part of a clip

Cut out the part you want first, then pass it to reverse. If you trim on the input side with -ss (start) and -t (length), only the trimmed frames are held in memory. That also avoids 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.

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 documentation only says “This filter requires memory to buffer the entire clip, so trimming is suggested” and gives no numbers. The table shows the peak memory use (peak working set) of the ffmpeg process with a 1920×1080, 30 fps, 10-second H.264 clip (300 frames).

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 machine: 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.

  • One 1080p yuv420p frame is 1920×1080×1.5 bytes ≈ 3.1 MB. 300 frames come to about 0.9 GB, close to the measured increase (1.7 − 1.0 = 0.7 GB).
  • So memory use grows with resolution × number of frames. 60 seconds of 1080p needs 6 GB, and 10 seconds of 4K needs 7 GB. A one-minute 4K 60 fps phone clip would need more than 40 GB, which fails on most PCs.
  • The 1 GB used without reverse comes from libx264’s lookahead and per-thread buffers. It is larger here because the CPU has 32 threads.

Two things reduce memory: trim first (-ss/-t), or shrink first (put scale before reverse). The order of the filters matters. reverse,scale=... stores full-size frames and shrinks them only afterwards, so it saves no memory.

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 longer than a minute, splitting the file is more reliable than adding RAM.

1. Split into 10-second segments (no re-encode, so it takes a few hundred milliseconds)

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

The cuts fall on keyframes (frames that can be shown on their own), so the pieces won’t be exactly 10 seconds each. This does not 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

Each piece uses about as much memory as the 1080p 10-second row in the table (1.7 GB).

3. Build the list in reverse order and concatenate

seg000 is the start of the original, so it must come last. Sort the files with the highest number 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

All the pieces were encoded with the same settings, so -c copy joins them without trouble. See Join videos with concat for details.

Reversed GIF

For a GIF, lower the frame rate and resolution with fps and scale first. This saves memory and keeps the GIF small.

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

For a “boomerang” that plays forwards and then backwards, split the stream into two copies, reverse one, and join 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

Loop and boomerang videos covers boomerang videos and compares GIF and MP4 sizes. For better-looking GIFs with an optimised palette, see Create GIFs.

Reverse and speed up

Add setpts and atempo for a rewind effect.

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 also holds every sample in memory, but audio is far smaller than video. An MP3 decodes to 32-bit float, so one minute of 44.1 kHz stereo is about 21 MB. Memory is not a real concern here.

FAQ

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

As the table shows, every frame passed to reverse stays in RAM. Trim with -t or put scale before reverse. If that is still not enough, use the split method. If the computer falls back on swap (disk space used as memory), the job will not finish in any reasonable time.

The reversed audio sounds wrong

If the source fades in at the start, the reversed version fades out at the end. That is expected. If the picture runs backwards but the sound still plays forwards, -af areverse is missing.

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

No. Inter-frame codecs such as H.264 store most frames as differences from other frames. To change the order, FFmpeg has to decode everything and encode it again.

The Reverse video tool runs reverse and areverse in your browser, and your file never leaves your device. FFmpeg.wasm has the same memory limit, so the tool is meant for short clips.