Week 9 & 10: Speed Ramp Implementation, MR Opened

08 Aug, 2026

This is a weekly update from my Google Summer of Code 2026 project with KDE, improving effect widgets in Kdenlive, a free and open source video editor. Combining two weeks here since the last post covered a lot of ground already.

From research to implementation

Following up from the last post, moved from investigating Speed Ramp to actually building it. The plan confirmed with Jean-Baptiste: reuse Kdenlive's existing keyframe type system rather than free bezier handles, and use KeyframeCurveEditor's per-pixel MLT sampling pattern as the reference for drawing the curve inside RemapView.

Implementation

Four commits, each built clean before the next:

• Added per-keyframe type storage (m_keyframeTypes), keyed by output position alongside the existing keyframe map. Absent key means linear, so existing projects load unchanged with no migration step
• Switched serialization and parsing to MLT's own animation API (anim_set with a keyframe type, then serialize_cut), instead of hand-formatted strings, so the type suffix always lands on the correct keyframe
• Added the curve band itself: sampled per pixel from the parsed time_map animation and drawn between the existing input and output rulers. What's drawn is exactly what MLT will play back, not an approximation
• Added a Type selector in the remap dialog, starting with a curated list (Linear, Smooth, Cubic In, Cubic Out)

Type

Type

Keyframe types follow their keyframes through drags, clip resizes, and deletion, and are captured in undo/redo alongside keyframe positions.

The curated list, and why

The full MLT keyframe type list also includes Bounce, Elastic, Exponential, and Circular, all of which overshoot outside the 0..1 range. On a time map, an overshoot means source time briefly runs backward, so the clip plays in reverse for a few frames at the keyframe boundary. That could be a real effect some people want, or a confusing artifact for everyone else. Left it out of the curated list for now and flagged it as an open question in the MR rather than deciding alone.

Manually verified

• Existing projects with time remapping load with all keyframes linear, playback unchanged
• Setting a keyframe to Smooth, Cubic In, or Cubic Out changes the curve shape and is audible/visible in playback
• Undo/redo through type changes restores both type and curve correctly, no desync
• Types survive keyframe drags, clip resizes, and neighbor deletion
• Save/reload preserves types; linear-only projects round-trip without gaining type properties

MR opened

Opened MR !928, referencing #2188 and #1454. Pipeline is running. No unit tests added this round since RemapView holds state directly in the widget, not reachable from the existing test harness without splitting the storage out first, noted this directly in the MR rather than skipping silently.

What's next

Waiting on Jean-Baptiste's review, specifically his call on the curated type list question.