Slow motion video: how to shoot it and export it smoothly

What frame rate do you need for slow motion?

Four different rates are involved, and mixing them up is what makes slow motion confusing. The capture rate is what the camera sensor recorded. The file rate is what the file stores, which for a slow motion clip is usually the playback rate already baked in. The playback rate is the rate the clip is meant to run at, and it is the rate you export at. The upload rate is what the platform asks for.

Play a capture of C frames per second back at P frames per second and the slowdown is C divided by P. What is left over is the number of genuinely captured frames in each second of the finished clip, and that is what your eye reads as smoothness.

Slowing down is a retime, not an export setting. In an editor it is the speed control, or telling the editor to play the 240 fps clip at 30 fps (often called conforming or interpreting the footage); in ffmpeg it is the setpts filter. We checked what happens without it: a 2 second, 240 fps test clip exported at 30 fps with no retime stayed 2 seconds long and kept 62 of its 480 frames, while the same clip retimed 8x became 16 seconds with all 480 frames and no repeats.

So the rule is not "shoot slow motion at 60 fps". It is: pick the slowdown first, multiply it by the frame rate you want to watch at, and that is the frame rate you must capture.

The last two columns are computed by the frame-math block in our test script from the capture rates in the first column, with the 240 fps and 120 fps rates taken from the Apple support page in the sources. The 30 fps and 23.976 fps rows are the file rates we measured on the two real files in the test; both clips had already been slowed in camera, so their capture rates were higher, and these rows show what happens when you slow such a file again. The percentages in the last column are what the file looks like if you export it at 30 fps, which is the case we are measuring below.

How to shoot it

On an iPhone, Apple publishes the modes and the steps. From the iPhone guide: "Slo-mo is set to record at 1080 HD at 240 fps from the back camera and 1080 HD at 120 fps from the front camera." and "To change the back camera to 120 fps, go to Settings > Camera > Record Slo-mo." So the short version is to open the Camera app, switch to Slo-mo, and record, and to change the back camera rate in Settings > Camera > Record Slo-mo.

A higher capture rate is not free. Each frame can be exposed for at most 1/240 of a second at 240 fps, so indoors the picture gets darker or noisier, and Apple lists 240 fps Slo-mo at 1080 HD rather than 4K. Shoot slow motion in daylight or under bright light, and choose the lowest capture rate that gives the slowdown you need.

On Android there is no single rule we can stand behind. The slow motion modes are made by each phone maker, we did not test any of them, and the rates differ from one model to the next. What you can do is check what you actually got, and the tag in our test file shows where the answer lives.

That is the command we ran on both test files. On the CC0 phone clip it prints the playback rate of 30/1 and, among the container tags, COM.ANDROID.CAPTURE.FPS: 240.000000. The tag is what the recording app wrote, so treat it as what the phone reported rather than as proof about the sensor.

ffprobe -v error -select_streams v:0 -show_entries stream=r_frame_rate,avg_frame_rate -show_entries format_tags -of default=noprint_wrappers=1 clip.mp4

What a slow motion file actually looks like

Apple also publishes what happens to the file. From the iPhone guide on recording video: "Faster frame rates and higher resolutions result in larger video files. Videos you record at faster frame rates can be played back at slower speeds in the Photos app."

That is why a slow motion clip on a phone is usually not a high frame rate file. The slow motion is applied, and what you get is a 30 fps file that plays slowly. We found that exact pattern in a real file. The CC0 clip we tested carries the container tag COM.ANDROID.CAPTURE.FPS set to 240.000000 and COM.ANDROID.VERSION set to 12, while its video stream is 30 fps at 1920x1080 and 37.133 seconds long.

Two consequences follow, and the second one is the trap. First, the rate you read with ffprobe is the playback rate, so it cannot tell you how much slow motion the clip already contains. Second, the captured frames are all still in the file, but they are already spread over the 30 fps timeline: there are no spare frames between them, so slowing the file further can only repeat frames or invent new ones.

How slow can you go before it judders?

We measured this on real footage rather than estimating it. We took a 3 second excerpt from the CC0 phone clip, retimed it, and hashed every decoded frame of the result. A frame that is identical to the frame before it is a held frame, and that is what judder is made of.

The control comes first. The same excerpt exported at its native rate and with no retiming gave 90 frames and zero repeats, which tells us the measuring setup is honest before we use it on the slowed versions.

Our measurements, October 27, 2026, with ffmpeg 6.1.1 on Linux. We exported losslessly with FFV1 so that a repeated source frame decodes to genuinely identical pixels, then hashed each frame with the framemd5 muxer and counted the frames equal to the frame before. The 30 fps file was recorded on an Android phone and is the CC0 titmouse clip from Wikimedia Commons; the second file is the CC BY 3.0 Sony FS700 salad clip, also from Wikimedia Commons. The script and the log are linked in the sources.

Read the repeat rate as the share of the clip that the editor had to hold still. A 2x slowdown of 30 fps footage repeats half its frames, and 4x repeats three quarters of them. All 90 captured frames survive in every case, which is why the output gets longer rather than blurrier.

The video shows the difference. The middle row is the plain 4x retime and steps from one held frame to the next; the bottom row is the same 4x with synthesized frames and moves smoothly. Our script for it is linked in the sources.

How to export it

Export at the playback rate you want the clip to run at. If you did not retime the clip, that is the frame rate the file already has. If you did retime it, that is the rate you retimed it to, which in our test was 30 fps.

YouTube publishes its own upload encoding settings, and the frame rate rule is the first line: "Content should be encoded and uploaded in the same frame rate it was recorded. Common frame rates include: 24, 25, 30, 48, 50, 60 frames per second (other frame rates are also acceptable)." The same page asks for an MP4 container with "moov atom at the front of the file (Fast Start)", the H.264 video codec, progressive scan, "Chroma subsampling: 4:2:0", 48kHz audio and 384 kbps for stereo, and it lists 8 Mbps at 1080p for uploads at 24, 25 or 30 fps and 12 Mbps at 1080p for 48, 50 or 60 fps.

We did not test how any platform handles a slowed file, so check the result you get back rather than assuming the speed survived. For the same steps inside one app, see our guide to slow motion in CapCut, linked below.

The setpts filter changes the timing and minterpolate synthesizes the frames between the captured ones, as the ffmpeg filter documentation describes. Our test wrote lossless FFV1 files instead of H.264 so that the frame hashes could be compared exactly, and it used the 3 second excerpt starting at 5 seconds that the commands above reproduce.

ffmpeg -ss 5 -t 3 -i input.webm -vf "setpts=4*PTS" -r 30 -c:v libx264 -crf 18 -movflags +faststart output.mp4

ffmpeg -ss 5 -t 3 -i input.webm -vf "setpts=4*PTS,minterpolate=fps=30:mi_mode=mci" -r 30 -c:v libx264 -crf 18 -movflags +faststart output.mp4

What to do when the footage is already 30 fps

You have three honest options and no fourth one.

First, use a milder slowdown. At 1.5x a 30 fps clip repeats one frame in three (33.33%) and still keeps 20 captured frames in each second of output, the mildest slowdown in our table. A speed ramp over a short section reads better than a long uniform slowdown.

Second, interpolate. We ran the same 4x slowdown with in-between frames synthesized, and the result had no repeated frames at all: 352 frames, 0 identical to the frame before. The cost is that those frames were never captured. They are an estimate of what the camera might have seen, and on fast motion they can bend or smear, and the slow motion becomes a reconstruction rather than a recording. On our 3 second excerpt the interpolation took 129.60 s of encode time and produced a 284,748,133 byte lossless file, next to 292,688,521 bytes for the plain retime.

Third, go back and shoot it again in a slow motion mode. Only a camera that captured those frames gives you real frames at that speed, and a phone is not the only thing that can do it.

What does not work is expecting the platform to fill the gaps. Repeats appear when the retimed clip holds fewer uniquely captured frames in each second of output than the frame rate you export at, and no upload step can undo that.

• Milder slowdown: 1.5x on 30 fps footage keeps 20 captured frames per second of output and repeats 33.33% of the frames.
• Interpolated frames: smooth on screen, synthesized by the tool, and they bend on fast motion. Our 3 second excerpt took 129.60 s to encode.
• Reshoot in a slow motion mode: the option that adds real captured frames.

Limits and what we did not test

• We did not test a phone camera in Slo-mo mode. The 240 fps and 120 fps capture rates are the published figures from the Apple support pages in the sources, quoted on this page, and the 240 fps figure in our test file comes from a metadata tag the recording app wrote.
• We did not test how Instagram, TikTok or Facebook handle a slow motion upload. Those help pages are rendered in the browser and we could not read a published frame rate rule from them on October 27, 2026, so we make no claim about what they do to a slow motion file.
• We did not test the file after an upload to any platform. We measured the files we produced, not what a server returns.
• We tested two files, one recorded on an Android phone and one shot on a Sony FS700 camera. Both are slow motion clips that were already retimed before we got them, so neither is a raw high frame rate capture.
• The frame counts, repeat rates and lengths come from our own excerpts of those two files, at the settings in our script. A different clip, a different codec or a different editor will give different numbers.
• Frame interpolation quality is a judgement call that depends on the motion. We measured that it removes repeated frames and what it cost in encode time and file size, not that it looks good.
• We ran the free speed tool on this site in headless Chromium with the same 3 second clip on October 27, 2026. At 0.5x it returned a 5.966667 second H.264 file with 179 frames at 1920x1080 and 30 fps, twice as long as the input; at 1.5x it returned 2.066667 seconds. The tool repeats frames and does not interpolate, so its 0.5x output behaves like our plain 2x retime.