-
Notifications
You must be signed in to change notification settings - Fork 357
OpenFX Module #1186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
OpenFX Module #1186
Conversation
|
@joinlaw any chance you can show the feature in action ? (like a screencast?) |
|
demos basic-gain-plugin.webm |
|
Thank you, I can start taking a look around middle of January. I am taking a break over the holiday before some release activities at the end of the year, which is often followed by increased support. |
| mlt_properties params = mlt_properties_get_data(image_effect, "mltofx_params", NULL); | ||
| mlt_properties image_effect_params = mlt_properties_get_data(image_effect, "params", NULL); | ||
|
|
||
| *format = mlt_image_rgba; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not going to accept any new code that is 8-bit only. I see OpenFX has kOfxBitDepthShort that appears to correspond to the mlt_image_rgba64 that we added in 2025. Please try to include it.
| /* TODO: add support for OpenGL plugins */ | ||
| propSetString(host_properties, kOfxImageEffectPropOpenGLRenderSupported, 0, "false"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might not ever be able to support for OpenGL (or CUDA or Metal) without a good way to prevent multiple heavy data transfers between CPU and GPU RAM. For example, the Movit module and proper management by the app such as Shotcut addresses that.
No code change requested here. Just FYI to inform any future plans. I guess the key point is that OpenGL integration should not be standalone and needs to coordinate with the movit module. Also, the qglsl consumer is a way for melt to provide an OpenGL context on the render thread. Also, the future of OpenGL is also rather uncertain. The GPU tech landscape is messy.
|
I was literally just searching the progress for OFX support and I'm pleasantly surprised to see effort being made within hours ago. I guess the big question is, Is there a supposed date when I'd finally be able to use OFX plugins in kdenlive? |
|
@joinlaw I am interested in helping to sponsor this change into the code base. I intend to fetch your branch and start testing. Do you have any work-in-progress that I should have? Also, do you want any help resolving the comments above? Let me know how i can help. |
Well after this first merge request get merged the main priority is to implement OpenFX OpenGL plugins suite and DrawSuite (openfx extension something like postscript or cairo vector graphics). Once I have free time I will resolve all comments by @ddennedy and hopefully we will have basic OpenFX support so we can implement all other openfx extensions later. |
1d7cfb4 to
d3cad6a
Compare
| @@ -0,0 +1,72 @@ | |||
|
|
|||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do not want to duplicate the OFX host header files in our source tree. Today, when installing the OFX host environment for myself, I was surprised to find that they do not offer an install target for the host files. HOWEVER, they do offer pre-packaged development files with each release:
https://github.com/AcademySoftwareFoundation/openfx/actions/runs/19546967037
The directory structure of that package is documented in their github workflow:
https://github.com/AcademySoftwareFoundation/openfx/blob/main/.github/workflows/build.yml#L364
We should remove all these header files, and require the packager to have the official package from OFX installed - or to provide their own if they build it themselves. This will allow us to support compilation with different versions of the OFX framework over time.
As a convenience, we could offer a script for the packager to download and extract the official packages. That is not a requirement from me - just a suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and possibly using a git submodule
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MLT would still need libOfxHost.a and libOfxSupport.a. Where would they get those from? And how would we guarantee that the tag/release that we chose to get with git submodule matches the library versions the packager has?
I am open minded, but i do not want to build OFX as part of building this OFX MLT module because then our build would depend on conan - which is completely unnecessary if the packager just uses the official package release from OFX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
libOfxSupport.a is utility library to be used by plugin developers and as you see it is statically linked by the developers.
libOfxHost.a is sample/example reference implementation C++ library classes and my code is free from it because openfx module is pure C not C++.
The only thing needed is the header files at this folder only https://github.com/AcademySoftwareFoundation/openfx/tree/main/include so we don't need conan.
|
Please turn off this new module in |
… ends with other postfix
…ths from environment variable
…d widget '2dsize'
- handle the Microsoft Visual C++ compiler in module CMakeLists.txt - Change every copyright to the year 2025 - Use C99 variables in the for loop initializer declare style - Clang format and include <stdbool.h> explicitly - specify which versions of OpenFX supported - mention OpenFX header files URL in mlt_openfx.c - using mlt_image and its functions in src/modules/openfx/filter_openfx.c
|
@joinlaw, can you provide more commentary about how we can help potential users get access to openfx plugins? For example, I see you are using G'MIC plugins in your working copy. I have seen previous requests for that. So, I think in order to provide that, I will need:
I haven't found binary releases on the GitHub pages. And my Unbuntu package manger does not seem to provide the OFX files (it does provide the G'MIC library). Where will users get the OFX files from to use with this module? Will KDENLIVE help users download them? |
Actually I downloaded the Natron portable package and used them also I built the example plugins nothing more than that but I have seen before few other free software plugins over the internet. I added them to the environment variable |
|
There are a lot of OpenFX plugins, many of them commercial. Besides web search there are a lot of other so-called organic means to learn about them such as special interest web sites and forums. It is a lot like the VST plugin ecosystem. Expect to potentially deal with a lot of support and troubleshoot with the diversity. Properly supporting and debugging them in host may also cost money if you want to actually provide assistance. |


continuation on the close PR #1051 on this version unsupported plugins such as draw suite and opengl plugins are filter out so they don't appear on the plugins (filters) list.
Some plugins such as
com.genarts:OpenGLSamplePluginandnet.sf.openfx.Shadertoydoesn't returnkOfxStatErrMissingHostFeaturestatus inkOfxActionDescribeandkOfxImageEffectActionDescribeInContextOpenFX mainEntry action but they are harmless when they run because they have no effect when mentioned suits are not available.Some plugins such as
com.genarts:OpenGLSamplePlugincontain colons:in the pluginIdentifier which I replace with^(openfx.com.genarts^OpenGLSamplePlugin) to avoid any issue with MLT filters naming constraints.