29.97 fps and 30 fps are different frame rates, about 0.1% apart. Whether that matters depends on what you do with the difference. Leave a file alone and nothing changes. Relabel its frames as 30 fps and the clip plays 0.1% faster and ends slightly early. Keep the clock time fixed while changing the rate and the editor or encoder has to repeat, drop, blend, or synthesize pictures. Those are different operations with different side effects, and the number on a label doesn’t tell you which one you’re about to perform.
So before changing a setting, name three rates: the source rate (how the file’s frames are timed), the timeline rate (what your editor treats as one frame), and the export rate (what the output file will contain). Then decide what you must preserve: elapsed duration, and anything locked to it such as separately recorded audio, or the original sequence of frames, every captured picture once and in order. When the rates differ by a non-integer ratio, as these do, you generally can’t keep both.
Use the table below to identify the mismatch before choosing a conversion.
Step 1: Identify the source, timeline, and export rates
| Rate | What it is | Where to look |
|---|---|---|
| Source | How the recorded file’s frames are timed | File metadata, your editor’s clip information, per-frame timestamps |
| Timeline | The rate of the sequence or project | Sequence or project settings |
| Export | The rate written into the output | The export dialog, then the exported file itself |
These can disagree, and an editor’s display often hides it. Check the file with FFprobe or another metadata viewer. To get a quick estimate in the browser first, the video FPS checker reports a sampled frame-rate estimate plus metadata. It samples packets rather than analyzing the whole file, so it can’t confirm an exact rational rate or classify a file as constant or variable.
A typical FFprobe check:
ffprobe -v error -select_streams v:0 -count_frames -show_entries stream=r_frame_rate,avg_frame_rate,time_base,nb_read_frames -of default=nw=1 clip.mp4Read the fields with their limits in mind:
avg_frame_rate is an average. r_frame_rate is described in FFmpeg’s AVStream documentation as the lowest frame rate at which all timestamps can be represented accurately, with a note that the value is a guess. Neither proves the spacing of individual frames.
nb_read_frames (from -count_frames) counts the frames FFprobe reads, which is slower than reading metadata but closer to the file.
Container duration and stream timing are different references. Specify whether you are measuring the complete playback interval, the first-to-last frame-start span, or a reported header duration.
Rate fields alone do not establish a timestamp schedule. Inspect decoded presentation intervals when the difference affects your decision; the CFR/VFR guide shows that workflow.
Step 2: Read “29.97” and “30” carefully
The usual “29.97” label abbreviates 30000/1001, which is 29.97002997… frames per second. One frame lasts 1001/30000 s (about 33.367 ms) instead of 1/30 s (about 33.333 ms). A literal 29.97 (2997/100) differs from 30000/1001 by about 0.00003 fps, which is why exact-rate tools show the fraction.
For this workflow, the important distinction is the exact fraction rather than the rounded display label.
A “30” label is ambiguous. It can be a rounded display of 30000/1001, or an actual 30/1. Forum threads assert both “most 30 is really 29.97” and “there is no true 30”; neither replaces checking the file in front of you.
A fractional rate is also not automatically variable frame rate. 30000/1001 can be perfectly constant. Variable frame rate describes timestamp spacing that changes from frame to frame, a separate question.
Step 3: The same frames at two playback rates
Duration is frames divided by frame rate. Take 30,000 frames, where each number means: 30,000 is how many pictures exist, and each rate is how many of them play per second.
At 30/1: 30,000 ÷ 30 = 1,000 s.
At 30000/1001: 30,000 ÷ (30000/1001) = 1,001 s.
Exactly one second apart. This is a calculation with exact fractions, not a measurement of any camera or editor. The gap is 1/30000 s per frame, about 1 ms per second of program, or roughly 3.6 s over an hour.
| 29.97 (30000/1001) | 30 (30/1) | |
|---|---|---|
| One frame lasts | 1001/30000 s ≈ 33.367 ms | 1/30 s ≈ 33.333 ms |
| 30,000 frames last | 1,001 s | 1,000 s |
| Frames in 1,000 s | ≈ 29,970 | 30,000 |
| Frames in one hour | ≈ 107,892 | 108,000 |
For your own numbers, the timecode calculator supports 29.97 as 30000/1001 and true 30 fps for timecode, frame, and seconds conversions. Seconds you type in are rounded to whole frames, so use frame counts when you need exactness.
Step 4: Preserve duration or preserve the frame sequence?
There are two different operations, and they are not interchangeable.
Reinterpret: keep every picture, change the timing. The same frames get new timestamps, so speed and duration change by 0.1%. Adobe documents this for Premiere’s Interpret Footage: choosing “Assume this frame rate” changes duration proportionally and affects audio as well as video (Adobe: change the frame rate of a clip). Reinterpret 3,000 pictures from 29.97 to 30 and they last 100.0 s instead of 100.1 s. Leave the audio alone and it now ends 0.1 s after the picture, with the gap growing steadily.
Convert: keep elapsed time, change the frame count. The clock stays put, so frames must be added or removed. 100.1 s at 30 fps needs 3,003 frames, but only 3,000 exist; 100 s at 29.97 holds 2,997, three fewer than 3,000. The method decides whether the extra or missing pictures are repeated, dropped, blended, or synthesized, and the pattern is not guaranteed to be even.
A reproduced video-only conversion
A 3,000-frame synthetic H.264 clip at 30000/1001 reported 100.100000 seconds. With FFmpeg 6.1.1, converting it through fps=30 produced 3,003 decoded frames and the same reported 100.100000-second stream duration. This matches the duration-preserving goal: the output has more frame slots, so it needs repeated or newly generated pictures depending on the selected method.
This check used the fps filter, not optical flow or an editor timeline. Exact repeat positions, endpoint behavior and output counts depend on the method and timestamps. Inspect the output instead of assuming a universal duplicate pattern.
Step 5: How editors treat a mismatch depends on product and version
A timeline setting doesn’t alter the source file. What happens to clips that don’t match it depends on the application, and some commands deliberately reinterpret timing.
Adobe Premiere. Adobe’s mixed frame rate tutorial says a clip added to a mismatched sequence is conformed to the sequence rate while maintaining playback speed, and that you can choose any playback rate with Interpret Footage, which changes speed. Where speed changes, Premiere offers three time interpolation methods: Frame Sampling, Frame Blending, and Optical Flow. These pages were last updated between October 2025 and January 2026; confirm behavior in the version you run.
Final Cut Pro. Apple’s User Guide says you can mix frame rates in one project and choose per clip how mismatched frame rates are conformed. Separately, Apple’s FCPXML conform-rate reference says that for certain media and timeline pairs Final Cut Pro converts the media rate to the timeline rate and adjusts the duration, and its chart includes 29.97p and 30p pairs. That suggests a slight speed change in some cases rather than repeated frames, so test your version.
Other editors, including DaVinci Resolve and VEGAS, have their own conform and retime settings. Read the current documentation for your version, then test on a clip longer than a minute, because a 33-second cadence won’t show up in a short one.
Compare source and output duration, frame count and actual picture sequence. Those checks help distinguish retiming from cadence conversion, but trims, rounding and mixed operations can complicate the result. Do not infer the operation from one field alone. The 23.976/24 guide develops that distinction in more detail.
Step 6: A decision table, not a rule
No row below says “always set the timeline to X.” The right answer depends on what you can verify and what is written in your delivery requirements.
| Situation | 1. Verify | 2. Preserve | 3. What changing the rate may affect | 4. Inspect in the result |
|---|---|---|---|---|
| One source clip, no fixed delivery requirement | The source’s exact rate (metadata and per-frame timestamps); that timeline and export are set to it | The source rate, so nothing needs converting | Picking another rate creates a mismatch you then handle with repeats, drops, blends, or a speed change | Export frame count and duration match the source for an untrimmed export; timestamps are regular |
| A client explicitly requires true 30 FPS | The written spec (exact rate, constant or not) and the source rate | The delivery rate; then choose duration or frames | From a 29.97 source, keeping duration means about one extra picture per 33.4 s; keeping frames means 0.1% faster, 3.6 s shorter per hour, with audio needing to follow | Output rate and timestamps, frame count, motion at repeat points, audio sync at the end |
| Mixed 29.97 and true-30 footage | Each clip’s rate, especially anything labeled “30”; total running time per rate | Elapsed time per clip, unless you deliberately retime | Clips that don’t match the timeline get conformed or rate-conformed. Matching the rate that covers most running time touches the least footage | The minority clips: duration against the original, repeats or drops, audio sync on long takes |
| A file labeled “30” without a clear exact rate | Stream rate fields, time base, and per-frame timestamps across the whole file; frame count ÷ duration; a second tool | Nothing yet: treat the rate as unknown and don’t relabel it | A wrong guess gives a 0.1% speed error and audio drift of about 1 ms per second | Timestamp spacing is uniform at 1/30 or 1001/30000; sync at the end of the file |
| An export differs from the source | Which rate is source, timeline, and export; whether export is set to match source; which operation your app used | Decide: duration or frames | Duration kept: frame count changes (3,000 → 3,003 or 2,997 over 100 s). Frames kept: duration scales by 1001/1000 | Frame count, duration, last frame, cadence, rate fields |
| Separately recorded audio must stay synchronized | Audio length and sample rate against elapsed video time; how sync was made (clap, timecode, waveform) | The audio’s elapsed time; leave sound untouched where possible | Reinterpreting video alone shifts sync progressively; stretching audio changes duration or pitch depending on method | Sync at the start, middle and end of the longest take; picture and sound durations |
When a delivery requirement justifies conversion: when a written specification names a rate that differs from your source and you can’t change it. Quote the destination’s current specification rather than a general claim, and then choose the operation by what must be preserved.
Step 7: Inspect motion cadence and audio after a change
Cadence.
Count. Conversion: expected frames = duration × new rate (100.1 s × 30 = 3,003). Reinterpretation: the frame count should be unchanged and the duration scaled by 1001/1000.
Look at the repeat points. To inspect neighboring decoded frames around a suspected repeat, the frame-by-frame viewer steps through decoded presentation timestamps (subject to browser codec support). A repeat is a one-frame hold, a blend is a ghosted edge on moving objects, and a synthesized frame can warp fast motion.
Sample several points. Repeats arrive roughly every 33 seconds, so check near the start, middle, and end of long clips.
Audio.
Compare the durations of picture and sound. When video is reinterpreted and audio isn’t, the gap grows about 1 ms per second: roughly 60 ms after a minute and 3.6 s after an hour.
If audio is retimed to follow, inspect the chosen application's duration and pitch settings and verify real synchronized events. A silent video fixture does not establish audio behavior, and a tone test would not by itself establish speech synchronization.
Not every sync problem is a frame-rate problem. Sample-rate mismatches, variable timestamps, and drift in separate recorders produce similar symptoms.
Step 8: Drop-frame is a separate setting
Drop-frame versus non-drop-frame is a way of numbering frames in timecode for 29.97 material. It doesn’t convert footage to a different frame rate or remove pictures; it skips frame numbers (B&H overview). Choosing drop-frame won’t make a 29.97 file 30, and choosing non-drop won’t make a 30 file 29.97. See worked drop-frame and non-drop-frame boundaries for the numbering rules.
Verification checklist
Name the source, timeline, and export rates before touching a setting.
Read the exact rate from metadata and from per-frame timestamps, not from a rounded label.
Decide what to preserve: elapsed duration or the frame sequence.
Change one thing, then compare frame count and duration against your arithmetic.
Check cadence at several points on a clip longer than a minute.
Check audio sync at the start, middle, and end of the longest take.
FAQ
Is 29.97 the same as true 30 fps? No. 29.97 is 30000/1001, about 0.1% slower than 30/1.
What exact rate does 29.97 usually mean? 30000/1001 fps, about 29.97002997.
Can a “30” label be rounded? Yes. It may mean 30000/1001 or 30/1; check the metadata and timestamps.
Is a fractional frame rate variable frame rate? No. A fractional rate can be constant. Variable frame rate is about changing timestamp spacing.
Should I convert 29.97 footage to 30 because the numbers differ? Not for that reason alone. If no written requirement applies, keeping the source rate avoids conversion. If one does, pick the operation by whether duration or frame sequence must be preserved.
Does choosing drop-frame change my footage’s fps? No. It changes how frames are numbered in timecode.
The 30,000-frame comparison is exact arithmetic. A separate 3,000-frame video-only conversion was reproduced with FFmpeg 6.1.1; no editor, speech-sync or optical-flow benchmark is claimed.
Examples and calculations are scoped to their stated settings. Source links support the instructions; an illustration is not a screenshot of an application test.