VFR to CFR in FFmpeg: Fix Audio Desync (2026 Guide)

What VFR and CFR actually mean

CFR writes a frame every fixed interval — at 30fps, exactly 33.333 ms apart, every time. VFR writes a frame only when the picture changes, then stamps it with the real capture time. A static shot might produce four frames in a second; motion produces thirty.

The drift is arithmetic, not a bug. An editor conforming VFR to a fixed rate assumes every frame lasts 1/30 s. If the real average was 29.7 fps, a 40-minute clip accumulates roughly 24 seconds of phantom timeline — the audio, recorded on its own steady clock, slides out of position as you approach the end.

Step 1 — Confirm the file is actually VFR

Do not guess. Run this first:

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

• r_frame_rate is the nominal rate the container advertises.
• avg_frame_rate is the real average.

If the two values differ, the file is VFR. A file reporting r_frame_rate=30/1 and avg_frame_rate=2997/100 is variable.

When both look identical but you still get drift, check the raw frame timestamps:

ffprobe -v error -select_streams v:0 -show_entries frame=pts_time -of csv=p=0 input.mp4

A CFR file shows a uniform step (0.000, 0.033, 0.067). Uneven gaps confirm VFR. On FFmpeg builds older than 5.x, replace frame=pts_time with frame=pkt_pts_time.

Step 2 — Convert to CFR at the right frame rate

Match the output rate to your project rate, not to what the phone claims:

A rounded rate is the most common self-inflicted desync: conforming a 29.97 clip to 30 introduces about one frame of error every 33 seconds — roughly 72 frames across a 40-minute recording.

Step 3 — Pick settings by source type

Delivery targets for the same job

If the goal is also a smaller file after the sync fix, see how to make a video file smaller with FFmpeg.

Fixing audio that is already out of sync

Two different faults need two different tools. Diagnose before you touch anything.

Constant offset — early or late by the same amount everywhere

ffmpeg -i input.mp4 -itsoffset 0.5 -i input.mp4 -map 0:v:0 -map 1:a:0 -c copy output.mp4

ffmpeg -i input.mp4 -itsoffset -0.5 -i input.mp4 -map 0:v:0 -map 1:a:0 -c copy output.mp4

Progressive drift — fine at the start, worse by the end

The audio needs time-stretching, not shifting. Measure both streams:

ffprobe -v error -select_streams v:0 -show_entries stream=duration -of csv=p=0 input.mp4

ffprobe -v error -select_streams a:0 -show_entries stream=duration -of csv=p=0 input.mp4

Then compute atempo = audio_duration ÷ video_duration. If video is 3600.000 s and audio is 3599.020 s:

ffmpeg -i input.mkv -c:v copy -af "atempo=0.999728" -c:a aac -b:a 192k -ar 48000 output.mp4

atempo accepts 0.5 to 2.0 per instance; chain filters (atempo=0.8,atempo=0.8) for anything beyond that. If timestamps are simply wrong while the audio data is intact, let aresample repair them instead:

ffmpeg -i input.mkv -c:v copy -c:a aac -b:a 192k -ar 48000 -af "aresample=async=1:first_pts=0" output.mp4

Why -r 30 alone does not fix desync

Three flags look similar and behave completely differently. This is where most guides send you wrong.

The fps filter is the correct tool because it rewrites the timeline, not just the frame count. It duplicates frames where the source was slow and drops them where it was fast, so total duration is preserved and the audio stays anchored.

• Never use -c copy to fix VFR. Stream copy preserves the original timestamps exactly, so the drift survives the remux untouched.
• -vsync is deprecated. It was superseded by -fps_mode in FFmpeg 5.1. Older builds may still accept it with a warning; new scripts should use -fps_mode.

For editors: build a CFR intermediate instead

If the footage is going into an NLE, a CFR delivery encode is the wrong output. Transcode once to an intra-frame intermediate — it decodes instantly, so it also removes the playback lag that 4K H.264 and HEVC cause.

ffmpeg -i input.mp4 -c:v prores_ks -profile:v 0 -pix_fmt yuv422p10le -vf "fps=30000/1001,scale=1920:-2:flags=lanczos" -c:a pcm_s16le -ar 48000 -fps_mode cfr -movflags +faststart output.mov

For a full breakdown of when each codec wins, see ProRes vs DNxHR compared.

Batch-convert a folder of VFR clips

macOS and Linux, using bash

#!/usr/bin/env bash
set -euo pipefail

SRC="input"
OUT="cfr"
FPS="30000/1001"
mkdir -p "$OUT"

while IFS= read -r f; do
  base=$(basename "$f")
  base=${base%.*}
  out="$OUT/$base.mp4"
  echo "Converting: $out"
  ffmpeg -hide_banner -nostdin -y -fflags +genpts -i "$f" -vf "fps=$FPS,format=yuv420p" -af "aresample=async=1:first_pts=0" -c:v libx264 -crf 18 -preset slow -c:a aac -b:a 192k -ar 48000 -fps_mode cfr -movflags +faststart "$out"
done < <(find "$SRC" -type f -iname '*.mp4' -o -type f -iname '*.mov' -o -type f -iname '*.mkv')

Windows, using PowerShell

$Src = "input"; $Out = "cfr"; $Fps = "30000/1001"
New-Item -ItemType Directory -Force -Path $Out | Out-Null

Get-ChildItem -Path $Src -Recurse -File -Include *.mp4,*.mov,*.mkv | ForEach-Object {
  $rel = $_.FullName.Substring((Resolve-Path $Src).Path.Length + 1)
  $outFile = Join-Path $Out ([System.IO.Path]::ChangeExtension($rel, ".mp4"))
  New-Item -ItemType Directory -Force -Path (Split-Path $outFile -Parent) | Out-Null
  Write-Host "Converting: $outFile"
  $ffArgs = @('-hide_banner','-nostdin','-y','-fflags','+genpts','-i',$_.FullName,
    '-vf',"fps=$Fps,format=yuv420p",'-af','aresample=async=1:first_pts=0',
    '-c:v','libx264','-crf','18','-preset','slow',
    '-c:a','aac','-b:a','192k','-ar','48000',
    '-fps_mode','cfr','-movflags','+faststart',$outFile)
  & ffmpeg @ffArgs
}

If the whole folder is heading to a mixing stage rather than an editor, batch audio loudness normalisation belongs in the same pass.

Verify the fix

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

r_frame_rate and avg_frame_rate must now be identical. If they are, the timeline clock is constant and the drift is gone.

Troubleshooting