On Tue, Oct 28, 2008 at 4:13 PM, Jean-Michel Pouré <email@example.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
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 xml 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 melt, MLT API function arguments, MLT XML, SMIL, or even some future YAML/JSON-based syntax (hint).
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
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 MetadataRequirements
contains an attribute named "mutable" for the definition of a property.
The pre-requisite to this work is #1 on my ToDo
list because instead of
something like "[frame=]value[;[frame=value]]," it really should be "[time=]value[;[time=value]]." Unfortunatley, "time" is going to have some delimiters - at the very least ':' - and that now makes this syntax more complex and potentially unwieldy:
JSON is a subset of YAML and maybe I should adopt that:
["00:00:00" : [0, 0, 1.0, 1.0, 0.0], "01:02:03" : [0, 0, 1.0, 1.0, 1.0]]
The nested  is that group of settings I was talking about. Maybe positional parameters is not good, and we can work with groups of distinct MLT properties instead of a single property as "virtual properties":
["00:00:00" : ["x" : 0, "y" : 0, "width" : 1.0, "height" :1.0, "opacity" : 0.0], "01:02:03" : ["x" : 0, "y" : 0, "width" : 1.0, "height" : 1.0, "opacity" : 1.0]]
This can also be formatted, e.g.:
"00:00:00" : [
"x" : 0,
"y" : 0,
"width" : 1.0,
"opacity" : 0.0
"01:02:03" : [
"x" : 0,
"y" : 0,
"width" : 1.0,
"height" : 1.0,
"opacity" : 1.0
- 30 Oct 2008
I need to also consider different types of interpolation and ease-in and ease-out, which might impose different keyframe properties and the syntax for that. I am not saying all these things will come in one shot, but upon deciding an approach and syntax, I need to consider some longer term goals. Maybe that means a simple, convenient syntax for the common case of linear interpolated numeric values and a more structured set of classes and their corresponding serialization syntax for the more advanced stuff.
- 17 Sep 2009