SUMMARY When the motion -> freeze video effect is present in a project, it plays back correctly in the editor, but the rendered video contains 23 frames of blank white at the beginning of the frozen video clip. STEPS TO REPRODUCE 1. Add a video clip to the beginning of a blank project, and add the motion -> freeze video effect. 2. Render the project. OBSERVED RESULT The first 23 frames of the rendered video are blank white. EXPECTED RESULT The video should contain a single frozen frame through its duration. SOFTWARE/OS VERSIONS OS: KDE neon 5.15 User Edition KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.57.0 Qt Version: 5.12.0 ADDITIONAL INFORMATION This bug also happens in the latest nightly AppImage, currently "kdenlive-19.04.0-566230c-x86_64.appimage".
Tested on Windows 19.04.0-2 and AppImage 19.4.0. Clip 50fps MPG4, 3sec, freeze at 2sec9frame, project profile=clip profile, rendered as MP4. The rendered file shows the freeze frame 3sec only. Kdenlive 19.04.0 have MLT 6.15. The nightly build still MLT 6.13. Try with the AppImage 19.04.0 from the download page.
Created attachment 119633 [details] video that triggers the bug The bug still happens for me using the 19.04 AppImage. Here is the video I am using in my test ("Prelude-snippet2.mp4"). I'm just dragging the "Freeze" effect to the clip with the timeline cursor at 0, which should freeze the first frame of the clip. The project profile is set to "HD 1080p 29.97 fps".
Created attachment 119634 [details] video render showing the white screen bug Here is the render output I get when I complete the repro steps in the OP using "Prelude-snippet2.mp4".
Confirmed. Thanks for reporting. Opened issue: https://invent.kde.org/kde/kdenlive/issues/170
Could you try to uncheck the "parallel processing" checkbox in the render dialog and test if it fixes the blank issue ? The freeze effect might need some tweaks to fix parallel processing...
I can confirm that disabling parallel processing fixes the issue.
confirmed: disabling parallel processing fixes the issue on Windows as well.
I can confirm that this bug still exists in kdenlive-20.04-rc2-x86_64.appimage Here is a better workaround than disabling parallel rendering (since rendering on just one core will increase render time significantly): 1. Extract the desired frame as picture 2. Replace the clip with the desired picture of the frame Result: Manually applied freeze effect
Sorry, forgot to add to the comment before: The bug report is not accurate. The first frame is correct. Starting from the second frame the following 23 frame are blan/white.
Same here, and more... After rendered, the frozen range is filled with white screen just as described above, or, sometimes, the range is filled with broken(corrupted) image.
Should be fixed in my last mlt commit: https://github.com/mltframework/mlt/commit/2c24715b186d53348d164c4d3984a6ea19ed9c85
please report if OK for you :)
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I just tested with Kdenlive 20.08.2 (AppImage) using MLT 6.23.0, parallel processing enabled, and the bug appears to be fixed. Thank you, Jean-Baptiste!
In my test it seems also fixed. Thank you very much!