I agree.
I have never used or developed for MLT, Kdenlive, Shotcut, etc., but the G’MIC C bridge library I developed some years ago (and which has since then been part of the regular G’MIC distribution) allows a developer to easily integrate G’MIC in other applications or plugin standards without any dependencies.
Well, I just downloaded Kdenlive and Shotcut and made a quick proof-of-concept filter using the frei0r SDK (which is one of the standards that MLT is based on). Within minutes I had G’MIC running in both Kdenlive and Shotcut as a plugin:
The plugin API seems a bit simple/limited, it does for example not appear to have a text input or button parameters, but in principle it works just like in the other hosts.
6 Likes
How long did it take to render this?
About 8 minutes I think on my crappy 10 year old notebook
4 Likes
Wow! Amazing! <3
Can we test this?
PS
I wonder if this is the same approach that Flowblade used. 
I have found a way to enable text input in Kdenlive I think.
I’ll see if I can make a frei0r public test build tomorrow, Windows only for now though!
And this will only include the generic G’MIC plugin (where you can enter any command as a parameter), not the whole package of the gui filters with proper parameter names, since filters for Kdenlive/Shotcut need to be put each into a separate library and also need a separate GUI definition file, so I would first come up with a decent batch compile/build/export solution, just like for After Effects.
1 Like
I will still be in the process of cleaning and updating the sources for still a while, removing dependencies and generally making stuff easier to understand (also for myself), while still maintaining compatibility with my commercial plugins and APIs.
As before, I will also make all my sources available (except for proprietary SDKs like Adobe AE, which developers can download themselves without costs) and put them dual-licensed under CeCILL-C and CeCILL v2.0, either in my own public repository on Github or in the G’MIC community repository (or both).
This will include sources to build a G’MIC plugin for Adobe After Effects, Adobe Premiere Pro, OpenFX, frei0r/MLT and possible some other plugin standards. Binaries for Windows (and later possibly MacOS and Linux) will also be provided.
But give me some more time, I hardly have any free time at the moment, but I’m sure we’ll get there 
5 Likes
This is really amazing. Thanks for the great work you’ve done. Do take it easy and no rush. Stay safe! <3
Kdenlive is rather fragile and has a lot of bugs in handling filters (independent of the G’MIC stuff I am working on) and a lot of features of the plugin/filter APIs are not properly implemented. But I managed to get my generic G’MIC plugin running in there now with an input text field, although it looks horribly squished on the UI (see screenshot).
Automating parameters also works in Kdenlive now, with the simple blur here automated from 0 to 20 over the length of the video. Render time was surprisingly fast, almost realtime (~8s).
Here is the result:
6 Likes
Tobias, I took the liberty of retweeting your progress, and a lot of people seem to be interested. What you’ve done so far is really great!
3 Likes
Looking Good! Could you expand on the handling of filters issue? I can pass it on to the devs. But afaik Kdenlive uses frei0r through MLT, does Shotcut handle it better?
That is fast indeed!
1 Like
Cool, thanks!
Both hosts I tested (Kdenlive and Shotcut) support several different filter/plugin APIs through various wrappers, but it all seems quite convoluted and unnecessarily error prone.
frei0r ist one of the main APIs to write C++ plugins (without UI interfaces in) for these hosts, but the frei0r API is intentionally kept very simple and does not cover more sophisticated constellations. It also does not offer any UI functionality at all, which would be fine as one would suspect the host would then provide a standard parameter UI for the few parameter types frei0r uses (bool, float, string, color, point). But no, neither of the hosts do that, instead they require writing your own UI in a rather simple XML text format (Kdenlive) or a very complex Qt QML description file. Even then, some of the underlying basic functionality (e.g. text input parameters) are not present in the Kdenlive XML API, and the mapping of UI parameters to plugin parameters is therefore really quirky. In my opinion, this is really the task of the host application to provide a standard interface, at least as a fallback.
So for Shotcut, I can easily put the frei0r filter to use, but I simply lack the time and expertise to write a UI QML definition file, let alone one for each of the G’MIC filters. This could of course be automated with a batch tool, but at the moment, this does not seem worth looking into for me.
As for Kdenlive’s other quirks, the whole handling of plugins is not very consistent. The sequence of the mandatory f0r_init/f0r_deinit calls for example does not always seem to be obeyed, and when exiting the program, f0r_deinit does not get called at all, preventing proper deallocation and even causing crashes.
They also do not seem to adhere to their own specification, with tags “keywords” and “keywordsdisplay” apparently not parsed.
For others the structure is really inconsistent and error-prone:
“paramlist” is an XML attribute and contains a list of values separated by semicolon, “paramlistdisplay” is an XML tag and contains a list of names separated by comma.
Parameter updates are also triggered inconsistently, while they are set on every manual frame change, on first load or when a parameter is adjusted on the same frame, the plugin sometimes does not get updated.
Since the APIs also do not have a cancel/abort flag, each time a parameter is actually sent, a full render will be triggered that can’t be aborted.
All in all, first (personal) impressions are not too good, neither about frei0r/MLT, nor about Kdenlive/Shotcut, but maybe I expect too much. Then again, having worked with commercial video and editing applications over the last 20 years, even those so-called “professional” applications regularly drive me up the wall.
2 Likes
Passing on to the Kdenlive team your feedback. Cheers
1 Like
No surprise. I recently volunteered to put some videos up on Facebook. Simple task involving putting clips together. The clips were poor and different in quality and specs; naturally, I wanted to make them easier on the eyes and ears. But the more I wanted to do, the more annoyances or bugs I caught. Many of those were longstanding issues reported intermittently over the years.
Anyway, I understand that this experience is a part of FLOSS.
So I understand this sentiment. 
On a separate note, it occurred to me right away that I was missing G’MIC in the process. So I am glad that you are looking into this.
Before I hop into bed, here are some more adaptations of the G’MIC plugin for popular video editors and editing suites:
Blackmagic DaVinci Resolve (applied on a 4K video!):
Blackmagic Fusion running inside Resolve:
Magix Vegas Pro 18.0:
The Foundry Nuke:
5 Likes
Kdelive doesn’t handle well projects with various frame rates… what kind of issues did you encounter? I recently did a quick 7 video series and the only issue I had was a rotoscoping bug. Do join the chat and discuss your issues the community is very welcoming. 
Every month there is a bit of progress, I wish it could go faster sometimes but it is basically one guy doing the work in his free time.
This is a game changer indeed for floss video editing.
I encountered this.
One time I had trouble encoding the video. After days of trying, it finally worked, but then I had trouble uploading it. Something was wrong with the file but I couldn’t tell why. After a couple of days, it was uploaded but then it wouldn’t play on the platform. Worked locally and was encoded in what I thought was acceptable. Ended up saying to the person last minute, “sorry, I can’t get it in on time; could you do it yourself?”. What an awkward situation. They didn’t ask me to do the task after that.
As noted, I don’t know what the problem was. I blamed it on my laptop and internet. In retrospect, there was a high res large size video made by Windows Camera. That was the new element. The other clips were also different from one another. Maybe the combination caused some kinks in the cutting process. I did try to separate and re-encode every single video and audio clip before putting them together but that clearly didn’t work. Sorry for not being very helpful with the story.
Time for today’s update:
From all of the various plugin standards/SDKs/APIs I know, only OFX supports multiple filters/effects within one library/plugin, all others need one library file per filter. Which of course is not easy to deal with when you have a G’MIC library with 1000+ filters.
Instead of going with a batch compilation approach where an individual source file needs to be created for each filter and then separately compiled, I used a technique I successfully apply to my commercial plugins as well:
A G’MIC filter definition (meaning its name, category, parameters, etc.) can easily be serialized into a string - similar to what is actually writting in the #gui sections of the .gmic files or in the .json export. The generic G’MIC plugin I have made for various platforms has one such filter definition string and reads the data from it at runtime. Now since this is just a string, we can take the binary, make a copy of it and overwrite this string with a new filter definition string, thus creating a new filter in that native format without needing to compile anything. This is very fast and even works across all platforms, so I can create plugins for all target platforms on a single system, as long as I have the binaries for the generic G’MIC plugin compiled. Of course it is not as easy as in theory, especially with Adobe plugins who need specific binary resources, etc., but as I said I already have used this system for years.
So I have written a small command line tool, that takes a JSON input file with filter definitions as first input and a binary template file as a second input. Running this against the standard update294.json file available on the G’MIC website and the G’MIC generic After Effects plugin generates for example more than 1000 self-contained After Effects plugins, each in its own DLL.
Of course loading so many plugins into After Effects is a bit of overkill, but you are free to put only the ones you want to use in your plugin folder. On the screenshot you see all the categories of G’MIC filters on the right and one active filter (Circle Abstraction) on the left, with only its custom parameters, fully automatable. The generic G’MIC plugin of course still exists and works as well.
That’s all for today, folks!
I plan on releasing some plugin binaries publicly next week so anyone interested can take a peek!
5 Likes
After Effects should support multiple plugins in a single file, you would need to make each effect in the module have its own entry point and PiPL resource (with a unique resource id 16000, 16001 etc).
This technique was documented in the Photoshop 3.0 SDK (which introduced the PiPL resources), but that documentation has disappeared in more recent versions.
Yes, I know AE technically has this option, but it has hardcoded limitations and internal bugs and Adobe says “It is possible, but not recommended to do this”. Besides, Premiere Pro then wouldn’t be able to load such a file anyway. Also, the resource requirement on build time would rule out having a user-defined set of filters, it would always be a fixed number, while in the G’MIC OFX file, the user can define via a textfile how many and what filters should be reported to the host.