The clip looked fine on the phone. You watched it in the camera roll, air-dropped it or copied it over, and opened it on the laptop. The first few seconds are fine. Then the mouth is a little late. By the end of a twelve-minute interview, the voice and the face are not in the same sentence.

Or the picture hiccups. Not the whole file. A small stutter every second or so, like the player is catching its breath. The phone never did that.

Most of the time this is not a broken download and not a bad converter. The phone recorded a variable frame rate. The editor, the player, or the tool you used to make a smaller copy assumed every second held the same number of pictures. Those two clocks do not fit on one timeline, so something gives: smoothness, duration, or sync.

People re-encode the file three times, change MOV to MP4, and still have the same walk. The container was never the argument. The timestamps were.

What variable frame rate actually means

A frame rate is how many still pictures the file offers per second. Constant frame rate means that number stays put. A 30 fps clip is aiming at 30 pictures a second, all the way through. A minute of it is about 1,800 frames. The audio clock and the picture clock can stay married because both are steady.

Variable frame rate means the camera, or the capture app, was allowed to change that number while it was recording. A bright, simple second might be 30 frames. A dark second, or a moment when the phone was busy, might be 24. Another might land in between. The file still plays on the phone, because the phone wrote the timestamps and knows how to read them. Another program often does not.

You will see this shortened to VFR, and the steady kind to CFR. The letters matter less than the test. Does the frame rate mode say variable, and do the minimum and maximum disagree by more than a rounding error?

A minute that is not a fixed number of frames

Here is a small example, labeled as an example, not a spec your phone is required to hit.

Suppose a phone spent most of a 60-second clip near 30 frames a second, but dropped toward 24 for about ten of those seconds because the room got dark. A program that assumes 30 all the way through thinks the clip should contain 1,800 frames. The file might only have something closer to 1,740. The player then has to stretch, repeat, or drop pictures to fill the time the audio already occupies. That is where the stutter and the late mouth come from. Your file’s numbers will be different. The shape of the problem is the same.

Constant does not mean “broadcast perfect”

Constant does not mean every timestamp is identical down to a fraction of a millisecond. It means the file declares one rate and sticks to it closely enough that an editor can count frames.

The rates you will actually meet are 23.976, 24, 25, 29.97, 30, 50, and 60. YouTube’s upload guidance also lists 48 and 59.94. A phone that wanders between the high 20s and the low 30s is not on that list, even if Finder or Windows rounds the summary to “30.”

A min of 29.97 and a max of 30.00 is usually two ways of writing the same television rate. Do not “fix” that. A min around 24 and a max of 30, inside one file, is the real thing.

Where this recording habit comes from

Variable rate is not a glitch in the way a corrupt file is a glitch. It is a choice the capture device made so it could keep recording.

Phones

Phones do this on purpose. A locked rate is easier for an editor and harder on a battery. If the sensor and the encoder can ease off when the picture is not changing much, the phone stays cooler and the file stays smaller. Many phone cameras will vary the rate in the default camera app. A manual mode, a third-party camera app, or a specific frame-rate lock is what holds the number still. The default camera is the usual source, not the weird one.

The clip can look perfect in the camera roll. That is not a contradiction. The phone is the one device guaranteed to understand its own timestamps. “It plays on my phone” only proves the phone can read what it wrote.

Screen capture, webcams, and game overlays

Adobe’s FAQ on this in Premiere Pro names the same family of sources: smartphones, webcams, game-play recording such as NVIDIA ShadowPlay, and screen capture such as OBS Studio. The reason those apps vary the rate, Adobe says, is to hold a compression level or to keep performance up while recording. The symptom they call out is playback where the audio drifts away from the picture.

OBS is a slight special case worth knowing. It is usually trying to hold a constant rate. If the computer cannot keep up, it drops frames, and the recording stops being evenly spaced. A dropped-frame screen recording and a phone clip fail in similar ways once they land in an editor, even though the cause on the way in was different.

If you recorded a meeting you were in, a bug in your own product, or your own screen because there was no file to save, the recording is still yours to repair. Frame timing is a separate question from whether a screen recording was the right way to capture it.

Two different rates are not this problem

A 24 fps interview next to a 60 fps B-roll clip will hitch if you glue them without thinking. That is not variable frame rate. Each file is steady. You can conform each one, or let the timeline run at one rate and accept how the other is sampled.

Variable frame rate is unevenness inside a single file. Mixing two constant rates is a join problem. If the hitch only happens at the cut, start with joining clips that disagree. If the hitch happens in the middle of one phone clip, with no cut there, you are in this article.

How to confirm it before you blame the editor

Guessing from the stutter is how people repair the wrong thing. Five minutes of reading the file saves the rest of the afternoon.

MediaInfo, from MediaArea, is the straightforward reader. Open the file, switch the view to Tree if you need the detail, and look under Video. Frame rate mode is the line that matters. Variable is the answer that explains the stutter. You also want the minimum and maximum frame rate when they are listed.

A file that says 30 fps in the Finder, in Windows Properties, or in a website’s file picker can still be variable. Those panels often show one rounded number and hide the range. Treat that single number as a rumor until MediaInfo agrees.

The same habit of hiding the useful line is why a file can look fine in a folder and still refuse to play, or show a duration of 0:00. If the header and the pictures disagree in other ways, how to read video metadata is the longer version. For this problem you only need the frame rate mode and the min and max.

What the codec line is, and is not

You will often see HEVC in a MOV from an iPhone, or H.264 in an MP4 from an Android phone or a screen recorder. The codec tells you which tools will even offer a sync option. It is not, by itself, the bug. Plenty of HEVC files are constant. Plenty of H.264 files are not.

Premiere can also tell you, if it notices. Adobe’s FAQ says that from Premiere Pro 12.0.1 on, you import the clip, right-click it, and open Properties. If the panel says “Variable Frame Rate Detected,” the file is the kind they mean. If Properties stays quiet and MediaInfo says variable, trust MediaInfo. The toggle you are about to look for will not appear on a clip Premiere never flagged.

A playback test that does not need new software

Play the original on the phone and note a visual cue with a sound. A clap is ideal. A word with a hard consonant works. A door latch works. Scrub to the same moment on the laptop, in the program where it looks wrong.

If they match at the start and miss at the end, the error is accumulating. That is the signature of uneven timestamps, or of a convert that resampled them badly.

If they are off by the same amount at the start and at the end, you have a fixed offset. A clap that is late by the same beat at minute one and minute twelve is not a variable-rate walk. That repair is covered in fixing audio that drifted after a convert. Do not transcode a variable-rate file three times trying to cure a delay that was already a constant shift.

The symptoms people send to the wrong article

Drift that starts fine and gets worse

This is the classic one. Lip sync is acceptable at ten seconds. At four minutes you are not sure. At eleven minutes everyone looks dubbed. Variable frame rate does that because each slightly short or slightly long second adds to the last one.

A converter that then assumes a constant rate can bake the error into a new file. The damage survives even after the original mode is gone. If you already converted, and the drift showed up only in the new file, read the sync piece before you convert again. A second pass on a damaged copy rarely walks the error backward.

A duration that does not match the phone

The camera roll says 8:12. The editor says 8:04, or 8:21. It is tempting to assume the editor trimmed the file on import. Often it counted frames at a fixed rate and got a different length than the timestamps describe.

Trust the phone for “how long did we actually talk.” Trust a constant-rate transcode, checked against the phone at the start and the end, for “how long is the file I will edit.” If those two lengths still disagree after a careful conform, you dropped or repeated more frames than you meant to, and you should look at the rate you picked before you start cutting.

A join that hiccups on every clip, not only at the cut

You drop four phone clips on a timeline. Each one claims to be 30 fps. Every clip stutters on its own, and the audio pops when you try to butt them together. Each file may have its own varying rate. Joining them first asks the timeline to reconcile four different clocks.

Make each one constant, at the same rate and the same frame size, then join. The join article covers order, size, and clips that have no audio. It assumes the files are willing to be glued. Uneven files often are not, until you give them one rate.

Proxies and renders that misbehave

If you edit in Premiere, Adobe’s own limitation note is worth following instead of improvising. For proxy, consolidate, and transcode workflows, they say it is better to transcode variable frame rate material to a constant frame rate before editing. Do that first. Do not build a proxy of a file whose timing is still moving, and then wonder why the proxy and the full-res clip disagree.

What “preserve audio sync” actually trades away

Premiere’s control for this lives under MPEG Source settings. Adobe’s FAQ tells you to open the clip in the Source Monitor from the Project panel, then switch to Effect Controls. Two choices sit there.

Preserve Audio Sync decodes the clip so the audio and the picture stay together. The decoder adds or drops video frames to do it. Motion can look less smooth. This is the default when the clip has audio.

Smooth Video Motion decodes the frames that are actually there and does not try to hold sync. Motion looks smoother. Adobe points at this one for motion-graphics work, where you care more about every available frame than about lips. If Premiere does not detect audio, this becomes the default.

Adding and dropping frames keeps the voice lined up. It does not invent pictures the phone never captured. A slow pan can look slightly stepped. A talking head usually survives it, because a face does not travel far between frames. A sports clip, a whip pan, or a screen recording of a cursor shows the cost sooner.

If the footage is an interview, take the sync. If the footage is motion and you will replace the audio anyway, you can prefer smoothness. You rarely get both at the original variable timing unless you leave the file on the phone. That is not a workflow.

When the setting is missing, or it fails

Adobe is plain about the failure case. On some files, Preserve Audio Sync does not work as intended because the minimum and maximum frame rate are too far apart. Their recommendation is to transcode those files to a constant frame rate before you use them. They name Shutter Encoder for that job, and they note that HandBrake also works but has fewer features. If a file will not import cleanly, they say to use one of those rather than expecting Media Encoder to rescue it.

There is a quieter failure. Properties never says variable frame rate was detected, so MPEG Source settings never shows up. Reimporting the same MOV will not grow the checkbox. Read the file in MediaInfo. If the mode is variable, skip the hunt and make the constant-rate copy.

In HandBrake, the trap is “Same as source.” That choice can carry the uneven rate into the new file, which means you waited through an encode and kept the bug. Pick an actual number, and pick constant frame rate, not variable. Shutter Encoder is the other app Adobe names when the spread between min and max is large. Learn one of them. Switching apps in the middle of one file is how settings get half-applied.

Make one constant-rate working copy

Keep the phone original. Work on a copy. Name the copy so you can tell them apart later. interview-maria-cfr30.mp4 next to IMG_2044.MOV is enough. You want to be able to throw the copy away without guessing which file was the camera original.

VideoDownloaderX is for files you already have and are allowed to convert, compress, or cut. It is not a substitute for reading the frame rate mode first. If a convert is in your path, do the constant-rate pass before you shrink the file. Compressing a variable-rate original just makes a smaller copy of the same timing problem.

Which number to pick

Pick the rate the phone was aiming at, not a “better” rate you wish you had shot.

If MediaInfo’s maximum is 30 and the minimum sits in the mid-20s, 30 is usually the right target. The phone was trying to be a 30 fps camera and missing. Converting that to 24 throws away timing you did have and changes the motion on purpose.

If the whole project is 25 fps because you are delivering in a PAL country, or because the other camera was 25, then 25 can be the right target for every clip. Do that once, on purpose, for the project. Do not leave the interview at “whatever the phone felt like” and the B-roll at 25.

Fractional rates, 29.97 and 23.976, matter when the timeline already uses them or a broadcaster asked for them. For a YouTube video, a client review, or a file you need to send, integer 24, 25, 30, or 60 is easier to reason about. YouTube accepts both the integer rates and the fractional ones. Matching your editor matters more than matching a chart.

A 60 fps phone clip that varies between roughly 50 and 60 should go back to 60 if that was the camera mode, unless the whole project is 30. Conforming 60 down to 30 is a normal, separate decision about storage and motion. Do it after the file is constant, so you are halving a steady rate and not guessing through a wobble.

Repeating a frame versus inventing one

A constant-rate convert has to fill the gaps where the phone recorded fewer pictures. It can repeat a nearby frame, or it can blend frames together. Repeating is the safer choice for an interview and for anything with text. Blending can look smeared on titles, on software UI, and on a mouth.

If the tool offers a plain constant-rate option and a separate “smooth motion” or optical-flow option, use the plain one for faces, captions, and screen recordings. Optical flow is a creative effect. It is a bad default for a file you still need to trust.

Dropping frames is the other direction. The phone recorded more pictures than the target rate, so extras are discarded. Fast motion gets a little steeper. The soundtrack should stay on its own clock if the tool is doing the job properly. You are changing the picture grid, not speeding the voice up.

A worked example: a 14-minute interview

This is an example so you can see the order of operations. It is not a claim about every phone.

You recorded a client on the back camera, indoors, about 14 minutes. On the phone it looks normal. In the editor, sync is fine at the clap you did at the start. Around minute 10, the answer arrives slightly after the mouth closes.

MediaInfo says the frame rate mode is variable, the minimum is in the mid-20s, the maximum is 30, and the codec is HEVC in a MOV. You do not touch the original. You make a constant 30 fps H.264 MP4 at the same frame size. You keep the quality high. You do not also crush the file for a messaging app in the same step.

You play the clap, a sentence around minute 7, and the last answer. All three match. The new file is a bit larger or smaller than you expected. You do not care yet. You edit the copy.

Later, when you need a version small enough to send, you compress the edited export, not the variable original. Two jobs, two files. Making a video small enough to send is the second job. Mixing them is how people bake the stutter in and then spend the evening staring at a bitrate slider. If the destination is a phone player, WhatsApp, or email, that is a third decision about format and size, and it still starts from the steady file.

Screen recordings are the messy cousin

A screen recording that dropped frames will sometimes report a constant rate and still hiccup. The frames that remain may be stamped as if the missing ones existed, or the timestamps may simply gap. MediaInfo might not say “variable” in the same clean way. Your ear still can.

If a cursor jump and the click sound separate as the recording goes on, treat it like the phone problem. Make a constant-rate working copy before you cut, and keep the original recording. Check a click at the start and a click near the end, not only the first ten seconds, which almost always look fine.

If the computer was so overloaded that whole seconds are frozen or missing, no frame rate setting invents those seconds. Cut around the damage or record it again. A conform cannot recover a stretch where the encoder wrote nothing useful.

Game capture has the same shape. ShadowPlay and similar overlays will vary the rate to keep the game itself playable. The highlight looks fine in the overlay’s own player. It walks in an editor. Same test, same copy, same rule about not deleting the original until the end of the clip matches.

What to do after the rate is steady

Once the working copy holds one rate, the rest of the pipeline gets boring. That is what you want.

You can join clips that now share a rate and a frame size. You can trim without the trim tool guessing at a moving clock. You can compress for a message or an email. You can pick 1080p instead of 4K if the destination does not need the larger frame. Choosing 720p, 1080p, or 4K is about pixels and storage. MP4, WebM, or MOV is about which players will open the file. Neither choice repairs timestamps. Do them after the rate is constant, or every later file inherits the stutter.

If the constant-rate copy is in sync and a later convert knocks it off by a fixed amount, stop. You have left variable-rate territory. A soundtrack that is late by the same gap from the first frame to the last is the other article. Converting again at a new frame rate will not slide a constant delay back into place.

What makes it worse

Changing the speed of the whole clip to chase the drift. A small speed change might line the end up and still ruin the pitch of the voice. It also assumes the error was even, which is the one thing variable rate is not. It looks clever for the first twenty seconds and falls apart after that.

Stacking converts. Phone original, then “web optimized,” then “edit friendly,” then “smaller.” Each pass can resample timestamps. One deliberate constant-rate pass is enough.

Deleting the original once the copy seems fine at the start. Check the end before you delete anything. Then keep the original anyway until the project is delivered. Disk space is cheaper than a reshoot.

Trusting the single fps number in a file picker. It is a summary. The mode is the fact.

Conforming to 60 fps “for quality” when the phone mostly recorded near 30. You do not gain detail. You repeat frames and make the file heavier. Quality, here, is a steady clock at the rate you actually shot.

A short checklist

• Play the original on the phone. Find a clap or a hard word near the start and near the end.
• Read the file in MediaInfo. If the mode is variable, or the min and max are far apart, plan a constant-rate copy.
• If you are in Premiere, check Properties for “Variable Frame Rate Detected.” If it is missing, do not wait for MPEG Source settings to appear.
• Pick the rate the camera was aiming at, unless the whole project is already locked to another rate.
• Transcode a copy. In HandBrake, choose a real frame rate and constant frame rate. Leave “Same as source” alone. Leave the original alone.
• Check the start, the middle, and the end. Mouth and voice, not just the first second.
• Then edit, join, or compress. Not before.

The part worth remembering

The phone is allowed to vary its frame rate. Your editor is allowed to assume it did not. The stutter, the wrong duration, and the mouth that walks off are what that argument looks like on a screen.

You do not fix it by renaming MOV to MP4. You do not fix it by exporting the timeline three times at a higher bitrate. You read the mode, you make one constant-rate working copy, and you check the end of the clip before you trust the start.

If that copy is clean and a later file is not, the damage happened in the later step. Use the sync article for a fixed offset. Use the compress article if the only remaining problem is size. The uneven rate itself is a one-time repair. Do it once, on a copy, and then stop touching the clock.

Sources

• Adobe’s FAQ on variable frame rate in Premiere Pro covers the phone, webcam, ShadowPlay, and OBS cases, Preserve Audio Sync versus Smooth Video Motion, and when to transcode first.
• MediaInfo is the reader Adobe points to for frame rate mode, minimum, and maximum.
• HandBrake and Shutter Encoder are the two transcode tools named in that FAQ when Premiere’s own option is not enough.
• YouTube’s recommended upload encoding settings list the frame rates a normal delivery is expected to use.