[Kdenlive-devel] Keyframing: How are we doing it?

[Dan Dennedy]

On Thu, Jul 29, 2010 at 11:46 AM, Simon Eugster <simon.eu at gmail.com> wrote:
> Dear friends,
>
> I've got a question about how keyframing is implemented at the moment.
> Is it such that each effect has to do support keyframing by itself? Or
> what is this working like at the moment?

Each MLT service may choose to do itself with the help of mlt_geometry.

> The reason why I'm asking is because I'm intending to write a 3-way
> color corrector, a better one that also supports CDLs[1] (at least
> output), and I thought keyframing would be neat to have there as well.
> And I thought it would be a loss of work implementing the same thing
> over and over again. Because keyframing is mainly
> * changing a value between two key frames continuously:
> * linear
> * non-linear (smooth curve) (not there yet, right?)
> We've got keyframing in Saturat0r, Brightness, Volume, Composite, and
> perhaps others. It is the same all time: Changing a value linearly.

mlt_geometry only does linear, and a patch to do anything more will be
rejected because..

> Smooth curves would be really cool to have, especially for Composite.

it is already high on my MLT todo list to add property animation to
mlt_properties.

> There are even two variables that can be smoothed out: Position (e.g.
> a clip driving around on the screen in a circle) and speed (which is
> just constant at the moment, but might be smoothed out, like a
> stopping car).

My plan calls for a function of value over time. Motion paths are
currently out-of-scope for now.

> What is the current status?

still in planning. I am currently working on the merging of my
parallel-consumer branch. I hope to get property animation done by the
end of the year.

> Simon
>
> [1] http://en.wikipedia.org/wiki/ASC_CDL
>
-- 
+-DRD-+