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>