23.976 vs 24 fps: the difference and when it matters

23.976 fps is the NTSC-film version of 24 fps: exactly 24000/1001 frames per second, which is 0.1% slower than 24. In the time a 24 fps video shows 1,001 frames, a 23.976 fps video shows 1,000. The gap matters for timing, not for how a single frame looks: when you convert one rate to the other, count frames, or mix both in one edit. 29.97 and 30 fps differ in exactly the same way.

The exact rates come from FFmpeg's utilities and filters documentation, and Sume's behavior from the Timeline 1.0, Video trim, Video filter, and Video inspect docs, read on 2026-09-28. Anything described as current behavior is read from Sume's code.

Why 23.976 and 29.97 instead of 24 and 30?

Both fractional rates come from NTSC color television, which runs at 30000/1001 frames per second instead of 30; 23.976 is 24 slowed by the same 1000/1001 factor. The rounded numbers people write stand for exact fractions, and FFmpeg's video rate syntax has an abbreviation for most of them:

Does the 0.1% difference matter?

Each frame stays on screen for 41.708 ms instead of 41.667 ms. The difference shows up when something counts frames or seconds exactly:

• Converting by repeating frames. FFmpeg's fps filter converts video to a constant rate by duplicating or dropping frames as necessary. Taking 23.976 footage to 24 that way repeats one frame in every 1,001 output frames, about once every 42 seconds, and the running time stays the same.
• Converting by retiming. Playing every 23.976 frame at 24 fps keeps all the frames but runs 0.1% fast, so an hour of footage ends about 3.6 seconds early. Its sound has to be sped up by the same amount, or it drifts out of sync.
• Counting time from frames. Timecode at 23.976 counts 24 frames per timecode second, so it falls behind the clock by the same 3.6 seconds an hour. How to convert frames to seconds works through the math.
• For 29.97 and 30, the numbers are the same, except that a repeat lands about once every 33 seconds. Drop-frame timecode, a 29.97 variant, skips frame numbers (not frames) to stay close to the clock, so it doesn't drift the same way.

Is mixing 24 and 30 fps a bigger problem?

Yes. Rendering 24 fps footage at 30 repeats one frame in five, and 25 fps footage repeats one in six, which shows as judder on motion. Sume's Timeline warns about that case (output_fps_resamples_sources), and Change a video's frame rate or resolution explains how it picks the rate.

What does Sume do with 23.976 footage?

Sume's editing tools read only your workspace's media.sume.com files, such as an earlier Sume job's output; which URLs each endpoint accepts explains the rule. For a 23.976 source:

• The free probe shows it. POST /v1/video-inspect with frames: false returns fps, which in current code is the stream's average frame rate rounded to three decimals, so a 24000/1001 clip reads 23.976. Get a video's duration, resolution, and fps shows the call.
• Trim and filter keep it. An exact trim without output.fps inherits the source's rate, and a filter output inherits the source's frame rate unless the program changes it.
• Timeline renders at a whole rate. Its output.fps takes only 24, 25, 30, or 60, and so does trim's. Omit it, and the render uses the rate the sources run at. In current code, a source within 0.05 fps of an output rate counts as a match, so 23.976 footage renders at 24 and 29.97 footage at 30, with no warning.
• A match is still a conversion. In current code, every segment runs through FFmpeg's fps filter at the output rate, which for 23.976 footage at 24 means one repeated frame in 1,001.