[Kdenlive-devel] Keyframes feature

[Dan Dennedy]

On Tue, Oct 28, 2008 at 4:13 PM, Jean-Michel Pouré <jm at poure.com> wrote:
> On Tue, 2008-10-28 at 15:33 -0700, Dan Dennedy wrote:
>> A module can choose to do it is own way for any
>> property, and some of them do. The point is that I want to make this a
>> framework facility for any type of mlt_property so that it remains
>> consistent across modules. As for naming them, well, I don't see a
>> reasonable way to do that without fucking up the concise syntax that
>> we have thus far. I suppose an app could figure out a way to do it.
>> Or, a side-property like foo.key.names=[frame=]Name[;[frame=Name]]*
>> might work.
>
> Just to understand. MLT Keyframes are attached to an effect, as they are
> properties.

kind of.
I watched the Final Cut tutorial you pointed me towards. We are
getting hung up on terminology and perspective. I think we have the
same idea.

> But in other environments keyframes are objects, which can be defined
> anywhere. Effects apply to keyframes and not the converse.

I can see how some UI may give you that perspective except for the
"anywhere" part, but I think you mean that any and all effects'
settings work with keyframes.

> I don't know MLT XML syntax to tell if keyframes can be independant
> objects in MLT. But if you create an XML syntax for keyframes, defining
> them as XML objects, you would not break backward compatibility.

MLT, the _framework_, currently does not require any XML; XML is
actually limited to the westley _module_. I don't want to have to
write a XML document that describes something as simple and concise as
[frame=]value(s)[;[frame=value(s)]] that works with inigo, MLT API
function arguments, westley XML, SMIL, or even some future
YAML/JSON-based syntax.

When I watch that video, I do not see keyframes as you describe it.
Rather, I see keyframes for groups of property values similar to what
MLT already has in mlt_geometry. How they are represented in a project
file is a separate matter and outside the scope of discussion here
because you do not write the XML; rather, you use the kdenlive UI.

As I tried to explain, today only mlt_geometry implements keyframes,
and it affects up to 5 floating point values. This is convenient for
x, y, width, height, and opacity, which was the reason for the name
"geometry" - the composite, region, and watermark effects use it. All
I am saying is that mlt_geometry should be more generic. Let's rename
it as mlt_keyframe. Then, I can make it not just support 5 floats but
1 or more of any property type including (non-interpolated) strings.
So, that changes things more to what you describe. mlt_keyframe is an
object that manipulates over time (animates) the values of a _group_
of settings/properties.

As a generic thing, this mlt_keyframe would be available _anywhere_,
but not _everywhere_. The way a particular module is implemented
determines that. Some effects might only see the initial value and do
nothing if that value changes within the same instance of that effect.
That could be seen as a shortcoming, but I do not want to impose a
requirement because sometimes a module is a bridge to another system
(frei0r, ladspa) or library (sox) where animation is not supported.
That is why the MLT YAML-based metadata[1] schema contains an
attribute named "mutable" for the definition of a property.

The pre-requisite to this work is #1 on my ToDo[2] list because instead of
something like "[frame=]value[;[frame=value]]," it really should be
"[time=]value[;[time=value]]." I put more notes[3] about this on my
wiki.

[1] http://www.mltframework.org/twiki/bin/view/MLT/MetadataRequirements
[2] http://www.mltframework.org/twiki/bin/view/MLT/ToDo
[3] http://www.mltframework.org/twiki/bin/view/MLT/PropertyAnimation

-- 
+-DRD-+