For services that currently have "start" and "end" properties (like
brightness), it probably makes sense to deprecate those properties and create
new ones (as already mentioned).
For services that do not have "start" and "end" (like volume), I wonder if we
could simply change the parameter type to animation. I think we could modify
the animation property type to detect if the user has provided an animation or
a simple type. If the user supplied an animation, parse and proceed. If the
user has provided a simple type, create an animation with a single element
containing the property value as the first element applied to the first frame.
~Brian
________________________________
From: Dan Dennedy <d...@dennedy.org>
To: Janne Liljeblad <janne.liljeb...@gmail.com>
Cc: mlt-devel <mlt-devel@lists.sourceforge.net>
Sent: Thursday, March 13, 2014 1:26 PM
Subject: Re: [Mlt-devel] Creating versions of services "brightness" and
"volume" with animated levels
On Thu, Mar 13, 2014 at 1:46 AM, Janne Liljeblad <janne.liljeb...@gmail.com>
wrote:
Hi,
>
>I think we should do new versions of mlt services that use "start",
>"end" mechanics to achieve animated parameters. We should use the new
>animation framework to animate parameter values.
>
>
Yes, of course.
On Flowblade I have "brightness" and "volume" used as "multipart
>filters" which is a unnecessary added complication to application
>code. I'd be happy to remove code needed to do this and replace them
>with versions of services that support animated level values.
>
>Another question is that should the existing services be expanded or
>should new services be created. I think we should do new services
>called something like "brightness_a", "volume_a" etc. that use the new
>animation framework, these would be much simpler to use from
>applications. There may obivously be other considerations like
>increased library size.
>
I am leaning towards using the existing services, adding a new property, and
deprecating the older properties. I do not understand how new services would be
easier to use in an application. It should be simply the choice of properties
to use. The filter would ignore deprecated properties if a new property is used.
If we think this is a good idea, and agree on the details, I can do a
>patch that does "brightness" and "volume" and later work on other
>services.
>
>Janne
>
>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
