See also http://jeff.ecchi.ca/blog/2009/07/15/variable-time-stretching-ramping/ for some initial/potentially incomplete thoughts (as indicated by Ed's comment on that post) about how it could look/behave like in the UI.

Am I right assuming that this would use the "videorate" gstreamer filter, or would it be something else? Would it be easy-enough to implement to be part of http://wiki.pitivi.org/wiki/PiTiVi_Love ?

I really love the proposal in the blogpost mentioned in comment 1. It seems like a very intuitive way to handle it. 

To address the issue of reversing the direction, it might be better to keep that functionality separate. Is it really that natural to think of reversing a clip as stretching it negative? What if you just had an option to 'reverse' a clip. And then just use the tools as described in the blog post to speed up or down?

I think this should be actually handled with the new pane like we can see here: http://lh6.ggpht.com/_3mLd5CtlHo4/TCIk1jYJH3I/AAAAAAAAHSw/J_ELnMPOmQE/s1152/Capture-3.png

I am going to work on that after my branch is merged I think. It seems to be pretty important.

On the backend side, is seeking the good way to go to adjust rate ?
I tried that today and it worked : http://pastebin.ca/2005204

that is changing the playback rate for the entire pipeline. What this bug is about is changing the playback speed of an individual clip in the timeline. To do this you only need to set media-duration != duration for the clip. If media-duration is < duration, then playback is slower than normal. If media-duration is > duration, playback will be faster than normal. This is the rationale for having two separate duration properties.

The real question is how to expose it in the UI. Here are a few ideas, which we should definitely talk over with users:

1) bring up a dialog and enter a percentage
2) use a modifier key so the user can "stretch" or "squeeze" a clip (as opposed to trimming it
3) this could be an application for a regions (which haven't been implemented)

What I thought about was rather a simple spinbutton that would be set sensitive when the clip is selected. Its simple and efficient, unless you want to get other parameters from the user.

@Brandon in comment 6 and comment 7: okay, that's for setting a uniform speed over the entire clip... but what about motion ramping (variable speed inside a clip) such as demonstrated in the link in comment #1 ?

@Mathieu in comment 8: I don't see where this spinbutton would go, except in the eventual "clip properties" tab (which is currently disabled because there's nothing in it)

The point is what I could implement without coding in C would pretty much be only setting a uniform speed over the entire clip.
And the spinbutton in my mind would go down, besides the "ungroup" button.

To clarify, a new gstreamer element would be needed to do motion ramping, which would probably need to be written in C and added to GStreamer.

I have done a little digging and there is an underlying problem somewhere in PiTiVi. This will have to be fixed at some point before we can implement this feature.

I created a project with a single clip in it. I edited the media-duration values such that the clip would play at half speed. The video portion does play at half speed, but not the audio. On the other hand, a simple test script I wrote in python seems to work at slowing down audio playback. So it should work in pitivi -- it just doesn't.

A nice way to do it : http://slowmovideo.granjow.net/videos.html

This bug has been migrated to https://phabricator.freedesktop.org/T2344.

Please use the Phabricator interface to report further bugs by creating a task and associating it with Project: Pitivi.

See http://wiki.pitivi.org/wiki/Bug_reporting for details.