[Kdenlive-devel] Fwd: Effects idea

[Zsolt Sandor]

Hello!

At the weekend i sent some time to watch the mlt framework source.

> > I think it is already the case, you can have a look in:
> > /usr/local/share/mlt/modules/

Definitly NO! The effects are linked together into libcore.so (check the
Makefile for modules/core) The core library is dinamically loaded, but
NOT the effects, they are linked together into the libcore.so file.

What I noticed:

the effects (transitions, producers, consumers) are linked together with
factory.c. Factory.c is a factory "class" in simple c, has different methods,
like:

mlt_create_filter(char *id,..)
mlt_create_producer(char *id,..)
mlt_create_consumer(..)
mlt_create_transition(..)

every function simply compares the id with some strings hardcoded into
the factory file, and returns a new filter/producer/etc. according to
the needs.

Example:

if ( !strcmp( id, "greyscale" ) )
                return filter_greyscale_init( arg );

 Where does it now about greyscale? It does know about, because the
grayscale's header is included at the top of the factory.h.

Okay, so what can i help in this situation.. i added dinamic so
handling (just a proof of concept, not a fine-tuned solution)

Kdenlive mailing list does not accept zip files, dahhh... so,

How to use it:

- create a directory into "src/modules" called "filter_test" (or what you want)

- add filter_greyscale.c, filter_greyscale.h, Makefile to it.
- overwrite your factory.c in the core directory

- in the dinamic_core directory enter make. A new
libfiltergreyscale.so is created in the modules directory.

- Modify the Makefile in the core directory, you find something like:

OBJS = factory.o \
           producer_colour.o \
           producer_framebuffer.o \
           ...
           filter_greyscale.o \

remove the line filter_greyscale.o. It will result that
filter_greyscale will not be statically linked to the core.

- recompile (make) and install the mlt framework
- copy libfiltergreyscale.so  into /usr/lib
- su
- ldconfig
- run kdenlive

add a new video, add a greyscale effect to it.
Tadam!! (You can experiment with other effects, too..)

Okay, so, what to do:

- put all the effects into one directory, create dinamic .so-s from them.
- effects should be described in a text file (perhaps somewhere in
/etc/mlt_effects)
- factory should read from that text file, and create the so file
according to it
- sometime we should close the module (dlclose(module);) but when?

> > I do not have enough knowledge to really
> > comment on this, but having one library for each effect would probably
> > result in a worse real time performance.

After dinamically loading the effect, there is no performance loss.
(just a simple call...) :)

> > > - Create an xml schema that can describe an effect (and one for a
> > > transition). It should contain a link to the so file, the parameters,
> > > the function names bound to the parameters, and so on.
> >
> > Yes, I have been thinking about it for a some time, would be much better
> > than current situation. The best thing would be to have a place in MLT data
> > folders where xml files for the installed effects / transitions would be
> > installed, then Kdenlive would just have to parse this folder to
> > automatically create all effects.
>
> I am glad we are all thinking the same thing because Charlie and I did some
> brainstorming similar to this in July, 2004. I even generated a sample and
> discussed some minor additions to API and miracle/DVCP for an applcation to
> query for the XML.

Can you write about it? (Send example, and so on...?)

> > Still, one thing I am not sure is how we could manage translation of the
> > effect names and parameters, because all names will be in MLT and not in
> > Kdenlive anymore...

Well, the textual description of the effect gui can be translated. What i think:

in greyscaleeffect.xml

<effect>
  <name>Greyscale</name>
  <library>libgreyscalefilter.so</library>
  <gui>
   <rowlayout id="layout1">
     <component id = "mylabel" type="label">Hello world!</component>
   <rowlayout>
  </gui>
</effect>

Then the translations:

in the file "greyscaleeffect.hu"

effect.name = Szürkeárnyalat
effect.gui.layout1.mylabel = Helló világ

Or something like that...

> >From this metadata, you have the introspection to build a generic GUI, but
> that's not very nice. In 2004, when we discussed this, it was in the context
> of Kino and GTK+ where we pondered the usage of Glade XML, but that also
> raised the issue of how to bind the UI controls to an object's properties.
> Would kjsembed work for kdenlive?

I will check that kjsembed, too...

Regards:

 Zsolti
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filter_greyscale.c
Type: application/octet-stream
Size: 1748 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20070305/e4899ecb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filter_greyscale.h
Type: application/octet-stream
Size: 1031 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20070305/e4899ecb/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 635 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20070305/e4899ecb/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: factory.c
Type: application/octet-stream
Size: 4490 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20070305/e4899ecb/attachment-0003.obj>