https://bugs.kde.org/show_bug.cgi?id=364888
Bug ID: 364888
Summary: git-master:2016-06-29:Stabilize clips on timeline.
Product: kdenlive
Version: unspecified
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: User Interface
Assignee: j...@kdenlive.org
Reporter: evert.vors...@yandex.com
My wife has the habit of taking long clips, and she's a bit shaky on holding
the camera. I usually cut the pieces of the clips that I can use, and add them
to the project, then run the vid.stabilize over them, add the .mlt to the
project, and finally am able to get a stabilized clip on the timeline. This is
a lot of steps, and a lot of extra files added to the project.
It would be great if we could have vid.stabilize implemented as a filter,
avoiding the creation of many smaller clips and .mlt files.
The way I envisage this to work, is that when the effect "vid.stab" is applied
to a clip on the timeline, you get the same functions in filter effects as you
do on the popup menu if you stabilize a clip with clip jobs today.
Once the focus is gone from the effect, or when an accept button is pressed,
then the melt can render the .mlt file for the frame range in question, and
throw it in the cache, pretty much like a proxy. Since proxies are not
supported on .mlt files anyways this would make sense. A nice gui effect for
the rendering process on the timeline would be awesome, but is not a
requirement.
If the frame range changes, or the sliders are moved, the .mlt has to be
re-rendered, but this does not have to be a blocking operation for work to
continue and can happen in the background.
If this is a workable solution, then it can also be applied to other filters
that may require a two pass system. I'm thinking of ffmpegs' deshake filter
here, but there may be other examples.
Reproducible: Always
--
You are receiving this mail because:
You are watching all bug changes.
