Keyframes and Time Remapping

Time Remapping#

A clip's Time Remapping is transferred natively, as a real retime curve you can still open and edit in Resolve's Retime Curve editor. The clip keeps its timeline length, and every speed keyframe you set in Premiere lands on the matching frame in Resolve.

The conversion is exact. Every single rendered frame of the clip shows the same frame of your footage in Resolve as it does in Premiere: not "close enough", not "within a frame or two". CrossFlow may end up writing more keyframes than you set, because some of Premiere's speed ramps have no direct equivalent in Resolve, but that is how the result stays frame accurate, never a loss of accuracy. Extra keyframes and exactness are not a trade-off here: you get both.

Premiere's speed ramps come across too. When you split a speed keyframe in Premiere you get a ramp between the two halves, and dragging its handle changes how that ramp accelerates:

• The default ramp (handle untouched) and the hard step (handle rotated all the way) convert exactly, with no extra keyframes at all.
• Any handle rotation in between follows a curve shape Resolve has no direct equivalent for, so CrossFlow samples it into a few extra Resolve keyframes. The sampling is driven by the frames themselves: keyframes are added until every rendered frame in Resolve shows the same frame of your footage as Premiere, rather than until some average error looks small. A typical ramp gains a handful of keyframes. The extra keyframes are what make the ramp exact: the result is not an approximation of it.
• Premiere Pro and DaVinci Resolve do not agree about which source frame to show when a speed ramp puts the playhead a hair away from a frame boundary: Premiere always takes the earlier frame, Resolve rounds up into the next one. Where that would change the picture, CrossFlow aims a hundredth of a frame (well under half a millisecond) further inside the frame Premiere displays, so the two applications show the same frame of your footage on every single frame of the clip.

Speed changes and Reverse Speed apply on top of Time Remapping. In Premiere these are two separate things (the constant Speed of the Speed/Duration dialog, and the keyframed Time Remapping curve) while Resolve has a single retime per clip. CrossFlow combines them, so a retimed clip you also slowed down, sped up or reversed arrives in Resolve with both in place: a reversed one plays backwards through its own speed keyframes, ramps included.

The same frame accuracy applies when a clip's retime never changes rate at all: a uniform slow motion, or a plain Speed change from the Speed/Duration dialog. Resolve records where a clip starts in its footage as a whole frame of the timeline, which the clip's speed then turns into a fraction of a frame of your footage, so CrossFlow lines the retime up on the value Resolve actually stores: a trimmed clip you slowed down or sped up opens on the same frame in both applications.

One case CrossFlow reports rather than converts: a transition placed at the end of a time remapped clip. A transition reaches past the clip it sits on, into frames the retime curve no longer covers, so the few frames inside the transition can show slightly shifted footage. CrossFlow flags the clip in Full Details when this happens, with the number of frames concerned. A transition at the start of a time remapped clip is unaffected.

Time Remapping follows the Transfer Speed option, not Transfer Keyframes, because dropping it would not merely lose an animation: the clip would show the wrong footage all the way through. If you would rather have the speed changes burned into the media instead, enable Force Transcode of Time Remapped Clips in the Transcode Options (see Automatic Transcoding).

Advanced: keyframe accuracy, and why Resolve sometimes gets more keyframes#

You never need to read this section to use CrossFlow. It is here for the moment you open a converted clip, find twelve keyframes where you set two, and want to know whether something went wrong. Nothing did, and this explains exactly how close the result is.

Premiere Pro and DaVinci Resolve do not animate in the same way. For most parameters the two models line up and every keyframe converts one-for-one. For three of them the models genuinely differ, and CrossFlow has to rebuild the animation rather than copy it, adding intermediate keyframes so that what you see and hear matches. In those cases it is the rendered result that is preserved, not the keyframe count.

Converted one-for-one, with no difference at all

Scale, Rotation, Crop, Opacity and Pan use the same kind of curve in both applications, so each Premiere keyframe becomes exactly one Resolve keyframe carrying the same Bezier handles. Position is exact too whenever its Spatial Interpolation is Linear, that is a straight motion path, no matter how you have eased it in time.

1. Position, when the motion path is curved

Premiere treats Position as one 2D motion: a path through space, plus a separate curve describing how fast the clip travels along that path. Resolve has no concept of a shared path: it stores X and Y as two independent curves. While the path is straight the two descriptions agree exactly. As soon as it curves (Spatial Interpolation set to Bezier, Continuous Bezier or Auto Bezier) no pair of X/Y keyframes can reproduce it, so CrossFlow samples the real path and adds keyframes where it bends hardest.

• Typically 2 Premiere keyframes become 9 to 16; a curved 3-keyframe move lands around 37.
• Worst difference: 1 pixel on any rendered frame. On real projects it measures 0 at your own keyframes, which carry Premiere's exact values, and at most 0.85 pixel in between.

2. Anchor Point, which also changes your Position values

The two applications use the Anchor Point for different things. In Premiere, moving the anchor moves the image. In Resolve the anchor only sets the point that scaling and rotation pivot around: at 100% zoom, moving it does not shift the image at all. The two behaviors happen to coincide at exactly 50% scale and nowhere else.

CrossFlow therefore writes the anchor and compensates on Position. That has visible consequences:

• Resolve's Position values will not match Premiere's numbers, even on a clip where you never animated Position. The image lands in the same place; the numbers differ by the anchor offset.
• An animated Anchor Point creates Position keyframes, even if Position itself was never animated in Premiere. The movement Premiere gets from the anchor has to live in Position in Resolve.
• Resolve's Anchor Point keyframes also have no Bezier handles: the anchor can only travel in a straight line between them. So any eased or curved anchor move has to be sampled: 2 Premiere keyframes typically become 10 to 41, and a long, heavily eased 3-keyframe move can reach around 150, roughly one keyframe every 5 frames. A straight, constant-speed anchor move needs no extra keyframes at all and converts exactly.
• Worst difference: 1 pixel on any rendered frame for the anchor itself. In the rendered image the Position and Anchor Point budgets combine, and the anchor's share is multiplied by the distance of your zoom from 100%: it cancels completely at 100% and grows as you scale away from it. Measured on real projects: at most 0.95 pixel at 100% zoom, and 1.53 pixels anywhere between 25% and 200%.

3. Volume

Premiere works on raw audio level, while Resolve works in decibels and interpolates its keyframes in decibels. A straight fade in one is a curve in the other, so the two end keyframes alone cannot describe it: copying just those would leave a 0 dB to -20 dB fade about 4.8 dB off at its midpoint. CrossFlow rebuilds the curve instead.

• Typically 2 Premiere keyframes become 7 to 24; a 3-keyframe fade lands between 27 and 36.
• Worst difference: 0.25 dB on any rendered frame, roughly four times finer than the 1 dB a listener needs to notice a level change at all. It measures 0.16 to 0.24 dB on real fades. Below -60 dB, which is effectively silence, the curve is not tracked that tightly because no one can hear it.
• Pan is unaffected: it means the same thing in both applications and always converts one-for-one, exactly.

In short, the worst difference on any rendered frame is:

• Scale, Rotation, Crop, Opacity, Pan: converted one-for-one, no difference.
• Position on a straight path: converted one-for-one, no difference.
• Position on a curved path: rebuilt with more keyframes, within 1 pixel.
• Anchor Point: rebuilt with more keyframes, and your Position values change with it. Within 1 pixel, or up to 1.53 pixels in the rendered image once you zoom away from 100% (measured across 25% to 200%).
• Volume: rebuilt with more keyframes, within 0.25 dB.
• Time Remapping: can be rebuilt with more keyframes, and is still exact: no frame is ever shifted. It is the one rebuilt case with no error budget at all, because the unit that matters is a whole frame of footage rather than a pixel or a decibel. See Time Remapping.

If you would rather have Premiere's exact result and do not need to adjust the animation afterwards, enable Force Transcode of Keyframed Clips in the Transcode Options: the animation is then rendered into the media itself, matching Premiere frame for frame, at the cost of no longer being editable in Resolve.