Find the first stage where judder appears
When still frames look sharp but motion advances unevenly, do not classify the problem as blur, A/V sync, or slow generated action. Record four observations around the same motion in one table. Start at the same point and play at normal speed without editing during the pass.
| Comparison | Decision and next step |
|---|---|
| Source motion is already uneven in the same player | Inspect native capture rate, shutter, and subject displacement; select another take or recapture. A higher export rate can only repeat existing pictures, not recover motion that was never captured. |
| Source is normal and the edit intermediate first shows judder | Inspect timeline interpretation, speed changes, proxy replacement, and intermediate export. Repair this stage before encoding another final. |
| Intermediate is normal and the final export first gains a regular pause pattern | Align pictures and timestamps against the known-good intermediate to inspect repeats or missing motion states, then decide whether a candidate from that intermediate is warranted. |
| The exact final file fails in player A but not player B | First reduce playback resolution or expensive overlays and inspect hardware decoding and system load. Retain the same file so player overload is not mistaken for file cadence. |
Use a file hash or absolute path to prove both players opened the same final. Player comparison locates a failure layer; it does not approve either player as a delivery reference. If the source is a genuinely low-rate fast pan, the constant-rate candidate in this article cannot restore missing motion samples.
Probe decoded-frame timing, not one frame-rate number
Run this read-only command separately for the source, edit intermediate, and final, then retain each JSON result with its file path:
ffprobe -v error -select_streams v:0 -show_entries format=duration:stream=codec_name,width,height,avg_frame_rate,r_frame_rate,time_base,duration:frame=best_effort_timestamp_time,duration_time -of json INPUT
Inspect decoded best_effort_timestamp_time intervals, pictures that persist across multiple times, and the first stage where the pattern changes. This article reviewed that output on the self-generated fixture. ffprobe 9.0.1 returned duration_time, so the command does not use the older pkt_duration_time field. Field availability still depends on the file and build; record “not reported” rather than inventing a value.
avg_frame_rate, r_frame_rate, and time_base are clues, not motion-quality verdicts. Also record first-frame time, last-frame time, frame count, container duration, and expected cut points. Variable timing is not automatically faulty, and a constant rate does not rule out many repeated pictures. Decoded-frame hashes can confirm bit-identical adjacent repeats. A lossy encode may decode repeated source pictures to different pixels, so unequal hashes do not rule repeats out. Inspect drops by aligning pictures, timestamps and motion order against the known-good intermediate; hashes alone cannot establish them.
Measured boundary: 24 to 30 only repeated existing pictures
A local FFmpeg 9.0.1 run generated a 320×180, 24 fps, two-second testsrc2 clip, encoded as lossless FFV1 in Matroska with no audio. An external fps=30 filter then re-encoded a second FFV1 file. The result supports only filter mechanics and timestamp observations.
| Measured item | Result |
|---|---|
| Decoded input and output frames | 48 → 60 |
| Unique input and output pixel hashes | 48 → 48 |
| Adjacent repeat transitions in output | 12 |
| Output picture provenance | All 60 output pixel hashes came from the input; all 48 input hashes remained. |
| Decoded timestamps | Input first/last: 0.000/1.958 s; output first/last: 0.000/1.967 s. |
| Quantization boundary | The Matroska millisecond time base reports 0.041/0.042 s input intervals and 0.033/0.034 s output intervals. |
This test had no normal-speed viewing, real camera footage, variable-rate media, audio, or production end-to-end run. It does not prove smoother perception, retention of every picture for other sources, or passing duration and sync. It shows only that this controlled 24-to-30 conversion added repeated frames rather than synthesizing new motion states.
Make an external candidate only after verifying the delivery rate
Verify the target rate from a written delivery specification, an accepted master in the same series, or explicit project settings. The next example assumes a verified 30/1 target; do not copy it when the evidence says otherwise. Set ACCEPTED_INTERMEDIATE to the last verified good intermediate. Keep the source and defective final as comparison evidence; do not feed the defective final into a filter that cannot recover pictures already dropped there. Keep inputs read-only and write a new path:
ffmpeg -n -i ACCEPTED_INTERMEDIATE -map 0:v:0 -vf fps=30 -an -sn -c:v libx264 -pix_fmt yuv420p cadence-candidate-30.mp4
This is a picture-only diagnostic candidate. The fps filter creates a constant rate by duplicating or dropping existing pictures. Filtering requires decode, filter, and re-encode, so it cannot use -c:v copy. Do not change playback speed to force duration, treat output -r as an already verified equivalent repair here, or describe repeated frames as motion interpolation.
Before accepting default boundary behavior, inspect the first input PTS, source clock, intended in-point, and end boundary. If the current delivery requires explicit fps start_time, round, or eof_action settings, write the expected first- and last-frame rule first and verify it frame by frame. This article does not assign universal values to unknown footage. A higher rate is not a universal fix: when the source contains sparse motion samples, the output merely schedules existing pictures more densely.
Audio is intentionally absent from this candidate. Only after picture duration, cuts, and boundaries match the plan should adopted audio enter downstream assembly as a separate asset. Verify the adopted version, head and tail, a complete listening pass, and sync explicitly. This article does not promise that picture resampling automatically preserves audio.
Original case: the first failing stage in a riverside mural clip
Wind Along the Wall is a fictional teaching case created for this article. A creator filmed a cyclist passing a riverside mural. The wheel spokes and painted letters look sharp when paused, yet the exported pan seems to hold every few steps. There is no real media, playback test, or successful result.
The creator first opens ridge-ride-source.mov, ridge-ride-edit.mov, and ridge-ride-final.mp4 in the same player, starting where the cyclist enters a blue letter. Source and intermediate motion agree; a regular hold first appears in the final. The exact final file shows the same cadence in another player. This paper evidence limits the next step to timestamp and duplicate-frame inspection at the final-export layer rather than sharpening or player tuning.
Suppose probing then shows a written 30/1 delivery requirement and confirms that this export layer introduced the repeat pattern. Only then does the creator make picture-only cadence-candidate-30.mp4 from verified good ridge-ride-edit.mov; ridge-ride-final.mp4 remains comparison evidence only. Its status is “awaiting boundary and viewing review,” never “fixed.” The creator compares first frame, last frame, each letter-crossing cut, and total duration with the intermediate, then watches the complete candidate at normal speed on the target device. If cadence remains unacceptable, the evidence is retained and the decision returns to capture or shot selection; the rate is not raised again to manufacture success. Adopted ambience is handed to downstream assembly separately, followed by a complete listening and sync check.
Use this record to decide whether the candidate can enter ordinary editing
Record mechanical checks, normal-speed viewing, and audio review separately. If any row is incomplete, the file remains a compatibility candidate rather than a repaired master.
| Record | Entry |
|---|---|
| Failure layer | Source / intermediate / final / specific player, plus the observation in-point for the same motion. |
| Frame evidence | ffprobe JSON for all three files; first/last PTS, frame count and interval pattern; repeats/drops checked against the good intermediate, with lossy hash limits noted. |
| Target basis | Verified delivery rate and its source, never “higher is better.” |
| Candidate command | Complete picture command, encoder, filter value, output path, and file hash. |
| Boundary checks | Duration, first frame, last frame, every cut, and subtitle/picture event placements. |
| Actual viewing | Complete normal-speed playback on the target device, with observations for pans, fast subjects, and cuts. |
| Adopted audio | Separate track version/hash, complete listening pass, head/tail, sync, and adopted content. |
| Decision | Write “ready for ordinary editing” only after passing; otherwise record the failure location and next candidate. |
At the pinned revision, multi-source Video Recap cutting selects an output rate from the used sources and normalizes each segment to that rate before concatenation. Ordinary assembly either copies picture or encodes H.264 yuv420p according to visual operations, but exposes no universal FPS-repair control for an arbitrary final. This article's candidate is therefore an external, unverified compatibility input. Only after checks pass should it and separately verified adopted audio enter ordinary Video Recap editing; do not describe that handoff as a native repair for every kind of judder.
FAQ
Will exporting 24 fps footage at 60 fps make it smoother?
There is no such guarantee. The fps filter duplicates or drops existing pictures; a larger number cannot recover motion states that were never captured. Locate the first failing stage and use the verified delivery rate for a candidate that still requires viewing.
Why can video still judder when its reported rate is 30 fps?
One rate number cannot show whether adjacent pictures repeat, timestamps are evenly spaced, or a player is overloaded. Compare stages, inspect decoded-frame timing and picture hashes, and open the exact file in another player.
Do it with the skill
Use $video-recap to continue ordinary recap editing from the compatibility candidate that has completed normal-speed viewing, boundary checks, and adopted-audio verification. Its path, file hash, verified rate basis, and separate adopted track are in the handoff record. Retain the external cadence diagnosis as upstream evidence and do not describe it as a universal native FPS repair. Inspect the actual media first, plan the edit, narration, captions, and new output, and report all remaining human viewing or listening checks.
Read the method: Frame-rate normalization in multi-source cutting · Multi-source output-rate selection · Copy and re-encode boundary in ordinary assembly · Ordinary Video Recap editing and delivery review · Official FFmpeg fps filter documentation · Official ffprobe documentation