Variable Frame Rate Explained: Check and Fix VFR

Constant versus variable frame rate

Every frame in a modern video file carries a presentation timestamp telling the player when to show it. In constant frame rate video those timestamps are evenly spaced: at 30 fps, one frame every 33.3 milliseconds, without exception. In variable frame rate video the spacing changes. The file may still report a nominal rate such as 30 or 60 fps, but that number is an average or a maximum rather than a promise.

A player does not care. It reads each timestamp and shows the frame at the right moment, while the audio plays continuously against the same clock, so picture and sound stay together. Problems start when software ignores the individual timestamps and assumes that frame number 1,800 sits exactly 60 seconds into a 30 fps clip.

Why phones and screen recorders produce it

VFR is usually not a bug but an efficiency choice by the recording device.

Phone cameras lengthen exposure in low light, and a longer exposure can mean fewer frames per second for a while. Heat, battery saving and processor load can also cause the encoder to skip frames.
Screen recorders often capture a new frame only when something on screen changes, or as often as the system can manage. A static slide may produce very few frames; scrolling produces many.
Video-call and meeting apps adapt the frame rate to network conditions, and recordings inherit those fluctuations.
Game capture can vary with the game's own frame rate.

Not every recording from these sources is variable, and settings differ between apps and versions. Some screen-capture tools record at a constant rate by default. The only reliable answer is to check the file.

The problems variable frame rate causes

Most issues appear in editing and processing software rather than in playback:

Gradual audio drift. An editor that maps frames onto a constant timeline places late frames too early and early frames too late. The error accumulates, so sound and picture can be fine at the start and noticeably apart after several minutes.
Stutter and judder. When the editor conforms an uneven sequence to a fixed timeline, it may duplicate or drop frames in visible clumps.
Wrong duration. Some tools compute duration from frame count and nominal rate and report a length that does not match the real recording.
Cuts that land in the wrong place. Frame-accurate tools may disagree about which frame sits at a given time.
Export surprises. Rendering a timeline built from VFR clips can reveal sync errors that were hidden during preview.

Different editors handle VFR very differently, and support has improved over the years in several of them. Check your own editor's documentation for its current advice before assuming you need to convert. Diagnosing sync problems in general, whatever their cause, is the subject of audio and video out of sync; a different problem, subtitles drifting because a video was sped up from one standard frame rate to another, is covered in subtitle timestamp alignment.

Example: a 40-minute meeting recording in an editor

A trainer imports a 40-minute meeting recording into an editor set to a 30 fps timeline. The first minutes look perfect. Around the half-hour mark the presenter's lips visibly lead the sound, and by the end the gap is around half a second. The recording itself is fine: in a media player it stays in sync throughout. The editor is treating unevenly spaced frames as if they were evenly spaced, and converting the file to constant frame rate before editing removes the drift.

How to check a file for variable frame rate

Open the file in MediaInfo and look at the Video section. A line reading Frame rate mode: Variable, often with minimum and maximum frame rates, is the clearest sign.
If you use ffprobe, compare r_frame_rate with avg_frame_rate for the video stream. A large mismatch suggests VFR, though it is a heuristic rather than proof.
For a definitive answer, ffmpeg's vfrdet filter analyzes the actual timestamps: ffmpeg -i input.mp4 -vf vfrdet -an -f null - prints a summary of how many frames departed from regular spacing.
Check a couple of files from each device or app you use. If one phone or recorder produces VFR, it usually does so consistently.
Note the nominal frame rate, such as 29.97, 30 or 60, because that is normally the rate to convert to.

Converting to constant frame rate

Conversion places frames onto a fixed grid: where the source has a gap, a frame is repeated; where it has extra frames, some are dropped. Because the stream itself changes, the video must be re-encoded. Three common routes:

HandBrake. In the Video tab, set the frame rate to the source's nominal rate, or Same as source, and select Constant Framerate. Use a high quality setting so the re-encode stays close to the original.
ffmpeg. A command such as ffmpeg -i input.mp4 -fps_mode cfr -r 30 -c:v libx264 -crf 18 -c:a copy output.mp4 converts to 30 fps CFR and copies the audio unchanged. Older ffmpeg versions use the -vsync cfr option instead of -fps_mode.
An intermediate codec. Many editors work smoothly with an editing format such as ProRes or DNxHR at a constant rate, which avoids a second lossy generation during editing at the cost of very large files.

Better still, prevent VFR at the source where you can. Many screen recorders and some camera apps offer a fixed frame rate setting, which suits footage you already know will be edited.

Trade-offs of converting to constant frame rate

Every conversion is a re-encode, so it costs time and some quality. A generous quality setting keeps the loss small but makes files larger.
Repeated frames are real. If the source had long gaps, the converted file shows held frames there, which can look like brief freezes.
Choosing the wrong target rate creates judder of its own. Convert to the nominal rate the device recorded, or to your project's rate if that is what you will deliver.
Converting does not fix sync that was already wrong in the original. If a file is out of sync in a plain media player, the cause lies elsewhere.
Long or high-resolution recordings take a while to convert, especially on laptops.

How mydubly handles variable frame rate video

mydubly does not need your video converted first. The translated voice is timed in seconds against the original speech, using timestamps from the audio, not frame numbers. When you choose a translated voice, the browser swaps the audio track by remuxing: the original compressed frames are copied unchanged with their original timestamps, and the picture is never re-encoded. A VFR source therefore stays VFR in the translated MP4, and plays back in sync in ordinary players for the same reason the original did. How the voice is fitted to the original timing is explained in syncing translated audio with video, and the copying step in browser video muxing.

Two practical notes follow. First, translate the original recording rather than a CFR copy you made only for that purpose; conversion adds a lossy generation without helping translation. Second, if you plan to edit the translated MP4 in a timeline that dislikes VFR, for example to mix a clean music stem under a voice dubbed from a dialogue-only export, the same conversion advice applies to that file before editing. The workflow is described in editing dubbed audio in a video editor.

Where variable frame rate is perfectly fine

Watching, sharing and uploading. Players and most video platforms read timestamps correctly.
Archiving the original. Keep the untouched recording even if you also make a CFR editing copy.
Transcription and subtitles. SRT and VTT cues are timed in seconds, not frames, so VFR does not shift them; the screen recording translation use case shows a typical workflow.
Simple trims in tools that copy streams without editing the picture.

Next step

Check one file from each device you record with. If an editor is part of your workflow and the file is variable, make a constant frame rate copy for editing and keep the original for everything else. When you want a version in another language, upload the original to the video translator; it keeps your frames and timestamps exactly as recorded.

Frequently asked questions

Is variable frame rate lower quality than constant frame rate?

Not inherently. VFR describes when frames are shown, not how sharp each frame is. A VFR phone video can look excellent, and a CFR file can be heavily compressed. VFR matters because some editing and processing tools mishandle the uneven timing, not because the picture itself is worse. For plain viewing, the two are usually indistinguishable.

Which frame rate should I convert a phone video to?

Use the nominal rate the phone recorded, usually shown as 30, 60, 29.97 or 25 frames per second depending on the device and region, unless your editing project uses a different delivery rate. Converting to a much higher rate adds duplicate frames without benefit; converting to a much lower one drops motion detail. Matching the project rate avoids a second conversion later.

Can I tell that a video is variable frame rate just by watching it?

Rarely. In a normal player VFR footage looks and sounds correct, because the player follows each frame's timestamp. The problems only become visible inside software that assumes constant timing, typically as gradual drift or uneven motion in an editor. A media inspector such as MediaInfo, or ffmpeg's frame-timing analysis, is the reliable way to find out.

Does variable frame rate affect subtitles?

Not directly. SRT and VTT cues use times in hours, minutes, seconds and milliseconds, and players match them against the playback clock, not frame numbers. VFR can matter indirectly if an editor shifts the picture while conforming the clip, or if you use a frame-based subtitle workflow. Subtitles made from the same file you publish will line up as long as the timeline is not changed.

Why does my screen recording have such a low average frame rate?

Many screen recorders only capture a new frame when the screen changes or when the system has capacity. A recording dominated by static slides can therefore average far below its nominal rate, while scrolling or video playback within the recording pushes it back up. That is normal VFR behavior. If the file is going into an editor, either convert it or set the recorder to a fixed rate next time.