Frame interpolation vs native frame rate
Interpolating up to a delivery frame rate fails differently than generating natively there. Where the artifacts land, and why 25 fps changes your retime math.
Two clips can both be 60 fps and be nothing alike. One had sixty distinct moments per second computed for it. The other had a smaller number computed and the gaps filled in afterwards by a model guessing what happened between them. They report the same number in the file header, they play at the same speed, and they break in completely different places — which is why "just interpolate it up" is fine advice for some footage and quietly ruinous for the rest.
The two things a frame rate number can mean
Frame interpolation synthesises new frames between existing ones by working out how things moved between two neighbours and inventing the moment in between. Native generation at a higher rate computes those moments directly. The glossary entry puts the distinction in one line worth memorising: interpolation is inference, not recovery. Anything that happened entirely between two source frames was never captured and cannot be reconstructed.
This matters more than it sounds, because the number in the header is not always a description of what happened. The same entry notes that some generators produce a modest number of real frames and interpolate up to the rate they advertise — so a clip labelled 60 fps has not necessarily had sixty moments per second decided. That's worth knowing when you're judging whether a model's motion is actually smooth or merely reported as smooth.
The catalog gives you a partial map of who commits to what. Of the 146 video models in Versely's catalog, 48 declare a selectable frame rate at all. Of those, 29 offer 24 and 30 only, 18 add 60 — VEO 3.1 among them — and exactly one, PrunaAI P-Video, offers 24 and 48. The remaining ~98 video endpoints don't expose the choice, which means the rate you get is whatever they render at.
Why 25 is the number that decides your retime
Versely's default video frame rate is 25 fps, not 24. That single fact reshapes every retime you do, because none of the rates models declare is 25 — the delivery default and the model-advertised options are separate facts, and the arithmetic between them is where judder comes from.
Work the ratios:
| Retime | Factor | What has to happen |
|---|---|---|
| 25 → 50 | exactly 2 | Clean. One synthesised frame between every pair |
| 25 → 100 | exactly 4 | Clean, but do it as two 2x passes, not one 4x |
| 25 → 30 | 1.2 | Five source frames become six. One invented frame per five, forever |
| 25 → 60 | 2.4 | Non-integer. Cadence never resolves |
| 25 → 24 | 0.96 | Something has to give: drop a frame per second, or slow the whole clip |
The 1.2 row is the one that bites in practice, because 30 fps is the most commonly requested delivery rate and 25 → 30 is not a clean multiple. Every fifth output frame is a synthesised one, arriving on a fixed cadence, and human vision is unfortunately good at picking up a repeating five-frame rhythm even when each individual invented frame is fine. It doesn't read as "one bad frame." It reads as a faint pulse in the motion.
The 25 → 24 row is worse for being invisible in the file. A naive conform to 24 either drops one frame per second — a hitch at a consistent interval — or retimes the whole clip 4% slower, which is inaudible on picture and very audible on any audio that was synced to it.
The practical consequence: pick the delivery rate at the top of the project and stay on it. The frame rate entry says the same thing from the other direction — mixing rates in one edit causes judder at the joins, so choose one for the whole piece. If your destination is 30, know before you generate that you'll be crossing a 1.2 boundary somewhere, and decide where.
Where the artifacts actually land
Interpolation does not fail evenly across a frame. It fails at three specific things, all of which are motion the interpolator's assumptions can't cover.
Contact points. The moment a foot meets the ground, a hand closes on a mug, a knife enters an onion, a ball meets a bat. At contact, a motion vector doesn't continue — it reverses or stops dead. An interpolator inferring the in-between position from two neighbouring frames extends the motion it can see, which puts the foot slightly through the floor or the fingers slightly inside the mug, and then the next real frame snaps back. The visible result is a smear or a half-frame ghost right at the moment the viewer is looking hardest. Generated footage already struggles here — physics failures around weight, gravity and contact is the standing version of the problem — and interpolating over a contact point compounds an error rather than smoothing one.
Occlusion. Something passing behind something else. The interpolator has no information about the hidden portion and invents it, which is where detached-limb artifacts come from.
Objects entering frame. A thing that exists in frame two and not frame one has no motion history, so the synthesised in-between frame either pops it in whole or fades it, neither of which is what happened.
Native generation at the target rate has none of these specific failure modes, because there is no in-between to infer — every frame was decided with the whole scene in context. It has its own problems, including that more frames at a fixed budget usually means fewer pixels or less time per frame, so the honest trade is smoothness-with-artifacts against detail-with-strobe.
When interpolation is the right call
It usually is, and this post is not an argument against it. Interpolate when:
- The motion is smooth and moderate. A slow pan, a drifting orbit, a person walking at normal pace. No contacts in shot, no fast occlusion. This is interpolation's home ground and it's most of what marketing video contains.
- You need slow motion you didn't generate. Slowing 25 fps footage to half speed and still delivering 25 fps means every source frame has to cover two output frames — that's a 2x interpolation whether you call it one or not. For heavier slow motion, two 2x passes beat a single 4x pass.
- The clip is already made and the alternative is a reroll. A frame-rate fix is cheaper than regenerating a shot you like.
Don't interpolate when the shot's payoff is a contact moment, when something crosses in front of something else at speed, or when you're trying to rescue footage that stutters for another reason — smoothing a gap also smooths the surviving footage around it.
One more thing interpolation never does: add detail. Invented frames add smoothness only. If the clip is soft, more frames make it soft more often. Resolution is a separate problem with a separate tool.
A conform order that avoids most of it
- Decide the delivery rate before generating. 24 or 30 for social; 60 only when the motion genuinely is fast. Write it on the brief.
- Check whether your chosen model exposes the rate at all. Most don't.
get_model_input_schemareturns the exact fields and allowed values for an endpoint before you dispatch, which is faster than inferring it from output. - Generate everything on one rate. Mixed-rate timelines judder at every join regardless of how good the individual clips are.
- Do speed changes in the editor, described rather than keyframed.
edit_videohandles speed as part of a full edit — changing video playback speed walks it through. Say which range and which factor. - Preview before you export. A 480p preview pass renders free, subject to a short per-user cooldown, and 480p is more than enough to see cadence problems — judder is a timing artifact, not a resolution one.
- Watch the contact frames specifically. Step through the moment of impact rather than watching the clip. That's where a bad conform hides.
FAQ
Is a 60 fps clip from a model that interpolates internally worse than one that doesn't?
Different, not automatically worse. It's smoother than its real frame count implies and it carries interpolation's artifacts at contacts and occlusions. It matters most when you plan to slow the clip down later, because you'd then be interpolating footage that was already interpolated, and the second pass has less genuine information to work from than the frame count suggests.
Should I generate at 60 and slow down, or generate at 25 and interpolate?
Generate at the higher rate if the model offers it and the shot has real fast motion — those are frames that were actually decided rather than inferred, and slowing them is a straight retime instead of a synthesis. If the model doesn't expose 60, generating at the default and interpolating for the slow section is the workable path, and it holds up fine as long as there's no contact moment inside the slowed range.
Does frame rate change what a generation costs?
Not directly. Across the catalog, credit cost is driven by duration and output resolution, and by whether a native audio pass runs — those are the dimensions models price on. Frame rate matters to cost indirectly, through the fact that higher rates at a fixed budget tend to come with resolution or length constraints on the model side.
Why does my clip look fine on a laptop and juddery on a phone?
Playback rate mismatch is the usual cause. A 25 fps clip on a 60 Hz display needs a repeating cadence to fill the refresh, and different players resolve that differently. It's worth checking a suspect clip on the actual destination surface before assuming the render is at fault — and if it turns out the render is at fault, the fix is a clean conform, not another interpolation pass on top.