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

[Simon Eugster]

2010/7/29 Dan Dennedy <dan at dennedy.org>:
> 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

Sounds good! Definitively looking forward to it. Thanks for the information.

Simon