| Summary: | Problems with rendering Previews and with GLSL/Movit | ||
|---|---|---|---|
| Product: | [Applications] kdenlive | Reporter: | Andrey <megester> |
| Component: | Video Effects & Transitions | Assignee: | Vincent PINON <vpinon> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | fritzibaby |
| Priority: | NOR | Flags: | fritzibaby:
timeline_corruption+
|
| Version First Reported In: | 19.04.1 | ||
| Target Milestone: | --- | ||
| Platform: | Flatpak | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Session logs and the project file
Proxy clip_Render-settings |
||
|
Description
Andrey
2019-05-12 19:20:36 UTC
Unfortunately, in the screencap not every single click has a meaning to make the bugs manifest themselves, particularly ignore my fiddling with the "Properties" pane and the track headers: I just thought I had some track-wide effects there, tried to display their settings, but then remembered I had removed them in the previous version of the project. I also tried to show that the intro logo part consists of a RGBA PNG image sequence plus the last frame imported as a separate clip but it turned out to be very clumsy. Movit and GPU acceleration is experimental and not supported yet. Please switch off. Please try with the current Kdenlive AppImage version 19.04.1 to see if there are any packaging issues https://files.kde.org/kdenlive/release/ or Kdenlive_Nightly_Appimage https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/ If they don't occur when using the AppImage, then it's your configuration or packaging. Okay, I tried the AppImage. In fact, I did try it before but could not resize the timeline area to fit my hidpi screen, it immediately snapped back to the original size and even was getting shrunk with every attempt, but now it's fixed somehow, I don't know why, so nevermind. To business: it goes better with the AppImage but still with some quirks in the preview rendering: 1. Preview of the intro (PNG sequence) is still very slow, just like if the frames are still read from the original files. 2. The final titles are still cause the preview renderer crash. Another thing: even on my better than average machine 4K editing on CPU-only is painfully slow, so I still at least have to use proxy files. But there is a problem: even such a simple effect as white balance correction causes them to play back slower than realtime or at least on the verge even with the "Track compositing" set to "Preview". I am making art videos which require a lot of fine tuning and inevitably some effects, at least curves and sometimes a vignette, and I don't understand why they are SO slow even when the proxy resolution is quarter the original size? And I cannot create a proxy for the PNG sequence (it results in "Cannot open file qimage:/home/olaf/.cache/kdenlive/proxy/ef3d466a7956492baaf307c4627706be.mkv"). As well as for a single PNG image. That's also bad. 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! Created attachment 120392 [details]
Proxy clip_Render-settings
I tested creating proxy from PNG, MTS and MKV and it works.
Could you check if it creates the proxy files in the cache/proxy folder as shown in the screenshot.
Yes playback is slow with CPU only. We found a bottle neck in MLT which slow down playback with picture. This will be solved with the 19.08 version.
Rendering: enable parallel processing and set thread to 0 for using all cores. If you get a black output file disable parallel processing.
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! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone! |