If you load a “custom” wipe method with those names (using a local copy of those pgm files from an earlier release) everything works exactly as expected - but it seems kdenlive might need to jump through some extra hoop with MLT 7 to use the autogenerated ones? Kdenlive still lists those wipe methods in the composition dialog, and explicitly enumerates names for them in core.cpp but if you select them, they don’t actually work/get used. The kdenlive appimage no longer ships physical files for the numbered wipe lumas (luma01-22.pgm), which I gather from MLT - Documentation is because MLT no longer ships them, it generates them dynamically when the old names are used. It took a while to find and fix all these small issues, and the last one we were aware of was that the frei0r effects were missing.This one isn’t new for 23.08.3 - if I understand correctly (which I’m not entirely sure I do it is an artifact of the changes in MLT 7, but I bumped into it again today when making some changes to an old project from the 21.x days. The main job after was to adjust the so-called “blueprints”, and tweak some parts of the Kdenlive code to use the right file paths to find all the plugins. To build Kdenlive on macOS, we use KDE Craft, a meta-build system and package manager that we have already been using for some time for our Windows builds. Once the DBus issue was solved, there were only some small issues left to fix. When you use this flag, Kdenlive uses QLocalSocket and QLocalServer for communication instead of DBus. Vincent made it possible to build Kdenlive with the cmake flag -DNODBUS=ON. DBus is used for the communication between the render process and the application’s main window. If you follow the Kdenlive project closely, you will remember that in the first video cafe we talked about macOS and that a big blocker was that DBus caused trouble with the dmg packaging.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |