Variable time stretching (ramping)2 min read

Here are some initial thoughts on how slow/fast motion video (with variable speed within a clip) could be designed in PiTiVi.
What we could have is a concept of special keyframes that go in only one dimension (the x axis, and not the y axis). So, let’s say we have a clip on our timeline:
variable-timestretch-1
We then click a pushbutton in the timeline toolbar that toggle the visibility of the time bars below clips, and the following “time remapping” bar appears below the video clips:
variable-timestretch-2
Then, we simply double-click on an empty space in that grey area to add keyframe. In our case, we add two keyframes (the yellow one is selected). Then, we drag the second keyframe towards the left (yellow arrow) to “compress” the time between the two keyframes, thus speeding up that portion of the clip:
variable-timestretch-3
The result is this:
variable-timestretch-4
The 170% in the colored zone indicates the speed. In this case, 170% means that it goes nearly twice as fast as the original duration in that portion of the clip.
If there are other keyframes after the 2nd one, they are ripple-moved to the left to preserve their speed, etc. The clip itself is trimmed (or extended) at the end to accomodate the changes in speed.
I think this direct-manipulation approach would be fast, efficient, simple to understand (it provides an awesome sense of scale: we keep everything time-proportional). This is unlike Vegas’ way of doing ramping, which uses curves on the x and y axis, and are utterly confusing and hard to manipulate.
So far, this sounds good. But then, I designed it (with inspiration from After Effects and Final Cut Pro), so I’m obviously biaised and don’t see the potential pitfalls of this approach. It seems amazingly elegant to me, and would corner my video editing needs much better than Vegas ever did on that front.
Nota: There is also the possibility of not having all this in a “gray area below the clips” thing, but instead simply a “regular” curve (like the current opacity/volume curves in PiTiVi git) centered vertically and locked to the X axis, but methinks it would look less pretty.
Gentle readers, what do you think?


Comments

2 responses to “Variable time stretching (ramping)2 min read

  1. I thought about this many times… and there’s basically two scenarios:

    • global time-stretching (you want to stretch the time (and even direction) of the whole clip) : You’d just move the stop position graphically.
    • non-global time-stretching (you only want to speed up-down parts of your clip, or even go backwards for some parts). For this… the only way to do it seems to be to have a separate X/Y graph where X is the out-time (time at which a frame is played) and Y is the in-time (timestamp of the original frame).

    By default the curve would be linear (first frame is played out at 0, last frame is played out at ‘last-frame-timestamp’). In your stretch example above, you’d move the yellow buffer timestamp earlier (meaning that the curve would be steeper between those two points).
    Why do it like this ? Because you’d also be able to do invidiual frame repositioning (like for step-frame animation), but you’d also be able to do reverse playback (taking one frame… and bringing it earlier. The curve at that point would be going ‘downwards’).
    Makes sense ?

  2. it would have been cool to have a preliminary presentation of how other applications behave with that task.
    Kiddo, your proposal doesn’t seem bad at all, but why not simply allow the user to select part of the clip itself and displaying that option in contextual menu (for instance :
    > Adjust speed
    >> 1/2 speed
    >> normal speed (contextual entry : only if needed)
    >> x2 speed
    >> input speed factor (it could be -1 to revert playback)