[Kdenlive-devel] Support for more clip types

Till Theato root at ttill.de
Tue Feb 26 18:51:52 UTC 2013

Hash: SHA1

On 02/23/2013 05:14 PM, jb wrote:
> On Tuesday 19 February 2013 06.20:02 Brian Matherly wrote:
>>>> I've been inspired to add support in Kdenlive for more of
>>>> the
>>>> producers in MLT. Right now, you can make color clips and you
>>>> can use the generator plugin to create a noise and count down
>>>> clip. But MLT exposes some other producers: like the Frei0r
>>>> test patterns. And I'd like to add some audio test tone
>>>> synthesizers.
>>>> <SNIP>
>>> in case you do not need this feature immediately you might want
>>> to have a look at the refactoring branch. There we have 
>>> AbstractProjectClip (src/core/project/abstractprojectclip.h), 
>>> AbstractClipPlugin and AbstractTimelineClip which can be
>>> subclassed for different types of clips/producers (See
>>> src/plugins/cliptypes). Currently the implementations of image
>>> (qimage/pixbuf) and video (avformat, should be renamed to av)
>>> are started. These two cannot be made more generic because of
>>> things like exif data or the requirement to have different base
>>> producers for different tracks (audio issues with avformat).
>>> But especially all the "generators" which do not use an input
>>> file could probably be handled by one single clip type plugin.
>>> For example by making using XML files similar to the ones used
>>> for effect descriptions. Just as you proposed. What do you
>>> think?
>> Till,
>> Thanks for redirecting me to the refactor branch. Things have
>> certainly changed there. And I think it will be easier to add
>> more generators in the new code. Based on what I saw, I agree
>> with you. I think we could make a new clip type called
>> "producerclip" or something similar. It could provide 
>> configuration for all the simple MLT producers like noise, color
>> and colorbars.The producer properties could be automatically
>> exposed to the user by querying the MLT metadata. If the producer
>> properties can't be extracted from the MLT metadata for some
>> reason, then we could provide an XML override to allow the
>> parameters to be described manually.
>> I'm in no hurry. So I can wait for the refactor branch to be
>> done. Do you have any idea when the refactor branch will be
>> merged into master? Alternately, I could start hacking in the
>> refactor branch. But I don't want to get in anybody's way.
> Hi,
> Sorry for taking so much time to answer... I completely agree with
> the producer proposal. I am currently busy fixing bugs for the 0.9
> branch and hope to make a release in about 10 days.
> When I make the release, I will make an announcement and a week
> later, we could move the refactoring branch to master. It is
> important that we give some delay because several packagers / build
> scripts are using current git master to provide a "bleeding edge"
> version of Kdenlive, and they will need to switch to the 0.9 branch
> until refactoring is usable.

Shouldn't we move the refactoring branch to next first and only move
it master when at least all core functions are ported? master is used
by quiet a huge amount of people after all...

> I will be really happy to start working on the refactoring branch.
> However I don't know how we can coordinate the work between us
> since some core parts are changed. I think maybe we can use the
> list when we plan to work on a part of Kdenlive to explain
> basically what we plan to do so that the others can speak.

Sounds like a good idea. Additionally we could set up a list with
tasks and ideas. Would mantis be appropriate for this?
Btw. I started working on (and hopefully will have time to finish this
week) adding clips to the timeline, this affects Bin and Timeline, UI
+ Model.


> regards jb

Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the Kdenlive mailing list