The bug I noticed after rendering is that it appears to stall on some frames in the initial part of the clip where the speed should still be 100%, as if it’s slowed it by a small percentage.Īt first I thought there must have been some corruption in the project, but it appears to be entirely reproducible, if I just take that clip, enable time remapping, then add a single keyframe at 0:24,00. I have a 29.97fps (4k if it matters but it probably doesn’t) clip that I’ve cut to 5:04,17 duration and then tried to apply some gentle time remapping to.

Ok, and here’s a fun bug I haven’t seen prior to 23.08.3 … I didn’t notice it when I first created this part of the project with 23.08.1, but I can’t say offhand whether it didn’t happen there or I just didn’t notice. Right now loading a project that had used them silently ‘fails’ (there’s no warning, but rendering the project doesn’t use the selected wipe). These are Sometimes Useful wipes, so it would be nice to keep them (and compatibility with old projects that used them).

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. 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.

For iphone instal Kdenlive 23.08.1