- Differential Revisions
- D276: When a GESEffect is used that changes the playback rate, such as the 'pitch' element, correct for it when sending seek events to the source.
- git URI
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.
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.
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:
- bring up a dialog and enter a percentage
- use a modifier key so the user can "stretch" or "squeeze" a clip (as opposed to trimming it
- 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.
How should the UI look like? We could have in Clip Properties > Transformation something like:
Speed: [ 1|-|+] (4 seconds)
-/+ would work in .1 increments.
I think if we call it "Rate" then it would not be consistent with the project settings UI where the framerate can be edited using a separate combo and entry. Considering this, the "rate" could be changed to "speed" in the code.
(ptv-xdgapp) ➜ gst-editing-services git:(master) ✗ git phab checkout T2344 git log Git URI: git://anongit.freedesktop.org/gstreamer/gst-editing-services, branch: wip/phab/T2344-applyrate5 Traceback (most recent call last): File "/usr/bin/git-phab", line 1068, in <module> obj.run() File "/usr/bin/git-phab", line 968, in run getattr(self, method)() File "/usr/bin/git-phab", line 806, in do_checkout commit, remote_branch_name = self.fetch() File "/usr/bin/git-phab", line 788, in fetch self.repo.git.fetch(remote, "%s" % branch) File "/usr/lib/python3.5/site-packages/git/cmd.py", line 440, in <lambda> return lambda *args, **kwargs: self._call_process(name, *args, **kwargs) File "/usr/lib/python3.5/site-packages/git/cmd.py", line 834, in _call_process return self.execute(make_call(), **_kwargs) File "/usr/lib/python3.5/site-packages/git/cmd.py", line 627, in execute raise GitCommandError(command, status, stderr_value) git.exc.GitCommandError: 'git fetch git://anongit.freedesktop.org/gstreamer/gst-editing-services wip/phab/T2344-applyrate5' returned with exit code 128 stderr: 'fatal: Couldn't find remote ref wip/phab/T2344-applyrate5'
You should set your git config phab.remote to your repository, morevover that has to be readable by the outside world (you can configure git remote set-url --push)
I'd just like to add a suggestion: smooth enter/exit of this effect. It allows better-looking transitions from normal video to slow/fast video. Android's PowerDirector has this option and it is very nice, in case you want to see an example of what I say.
GitLab Migration Automatic Message
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pitivi/issues/632.