We are very happy to announce the first AppImage of the next generation Kdenlive. We have been working since the first days of 2017 to cleanup and improve the architecture of Kdenlive’s code to make it more robust and clean. This also marked a move to QML for the display of the timeline.
This first AppImage is only provided for testing purposes. It crashes a lot because many features have yet to be ported to the new code, but you can already get a glimpse of the new timeline, move clips and compositions, group items and add some effects. This first Appimage can be downloaded from the KDE servers. Just download the Appimage, make the file executable and run it. This version is not appropriate for production use and due to file format changes, will not properly open previous Kdenlive project files. We are hoping to provide reliable nightly build AppImages so that our users can follow the development and provide feedback before the final release.
Today is also our 18th Kdenlive Café, so you can meet us tonight -20th of june – at 9pm (CEST) in the #kdenlive channel to discuss the evolution and issues around Kdenlive.
I will also be presenting the progress of this Kdenlive version this summer (22nd of July) at Akademy in Almeria – Spain – so feel free to come visit the KDE Community in this great event.
Is it going to be any faster?
I tried editing a more complex video in Kdenlive and it was painful.
One CPU is maxed out at 100%, all the other 7 CPUs are virtually idle.
Any chance Kdenlive will properly use multiple cores during previewing to make working with multiple video tracks / effects smoother?
No, the refactored timeline is not going to be faster (in the sense of using multiple cores). The goal of the refactoring is to get better code that is better maintainable and expandable, not speed. In fact, the timeline code does not do any timeline rendering into the project monitor — this is the job of MLT. The timeline code is the editor to the project data inside MLT. It only does the rendering of the timeline itself, but not of your project.
Also the refactoring will allow the implementation of new features like advanced trim tools… there are some things you can do to improve speed such as proxy clips and timeline preview rendering [1]. Check out the Toolbox section for more tips.
[1] https://kdenlive.org/project/timeline-preview-rendering/
Well, that is nice but it does not address the major usability issue of Kdenlive.
Doing anything as simple as two video tracks with a Cairo blend between them already slows down things significantly,
Add a few FX on each clip and things slow down to a CRAWL.
I worked on a complex music video with lots of edits and it took me 2 months. It was so slow.
In the end I had to do it in 2 separate projects, where I first mixed just one video track with all the FX, then exported it to webm.
Later imported that as the first track into the second project and added the second track there with more FX.
It was still slow as molasses. Very painful to work with. It was really an ordeal to get it done.
Frustrating to see one CPU going nuts and 7 doing nothing.
Maybe MLT is the part of Kdenlive that needs fixing more than the UI.
On a good note, Kdenlive was still the best tool for the job on Linux. OpenShot and Pitivi repeatedly crashed on me and look like total garbage, stability-wise.
Sorry for the rant, the whole project was far more painful than I anticipated.
Next time I may use a commercial tool. Kdenlive right now is not really usable for any more professional work.
Hi, maybe it would be a good idea to open a bug in this place:
https://github.com/mltframework/mlt/issues
MAke sure to read the FAQ first: https://mltframework.org/faq/#why-does-vdpau-not-seem-to-offer-the-same-performance-improvement-as-other-media-players
And yeah, I tried lowering timeline previewing, proxy clips, etc. Made very little difference.
Don’t know what you were doing and expecting, but Kdenlive doesn’t offer miracles yet. I just did a 7 video track trailer with intense effects and compositing. Timeline preview rendering helps me with checking timeline compositing, but the preview rendering is only using one core. This is known and mostly due to restrictions in MLT. Either go for commercial products or put your money where your interest is, giving it to the MLT engine to allow it to improve multi core performance. This world can be so simple. Don’t expect others to do all your work for free and you exploiting them freely at your pleasure.
You are just annoying, improvement can only be made by constructive criticism, this defensive attitude won’t get the project anywhere, he was speaking about his experience, valid as any other. Remember that on the last instance we want Kdenlive to become a competitor of other semi/professional video editors!
What is annoying is post after post having to hear people come with uninformed ideas trying to make a point. So maybe after a while we might get fed up. We also want to improve Kdenlive as it is our tool of choice but I don’t see how this is improving it… So instead of just “complaining” or “sharing your experience” maybe you could help improve it by participating more actively in the project, by helping in the forums, writing a specification on how to improve it or a detailed feature request, or reporting/confirming/replicating a bug… you know just be proactive instead of just wanting things… but that is just my humble opinion.
I think improving performance and stability is a clear enough feature request. By now I think Kdenlive is a really good enough program with the needed tool BUT! The bad performance made it UNUSABLE for me on every project I tried to do. Applying effects without immediately rendering the video makes it impossible to continue editing, the same for speed up sequences and so on. It makes me feel really bad to see how I can’t use a program this good for the most basic of the points, which is performance. If Kdenlive OFFICIALLY makes a crowdfounding campaign I will be really glad to help, but it’s a problem serious enough to blame others. Yes, I know it’s not a Kdenlive developers error, but this component/library/tool kdenlive uses is causing serious problems on THIS program so it’s OUR problem and in OUR hands to solve it.
Since there is no way to reply inline on your comment I’ll try to do it by points:
* The point of the refactoring is to improve stability and we are doing that. Performance is in the hands of MLT. We are not blaming others, those are simply FACTS.
* Since you are having bad performance why don’t you go to the forum and make a post. Describe your hardware and your footage maybe someone can help you improve/solve your woes.I can edit my videos (vimeo.com/gunga) just fine using proxies.
* Please be realistic, we can’t just create a crowdfunding campaign. Devs are volunteers and they choose to dedicate their free time to develop Kdenlive. Maybe you can help by finding a dev or contacting the MLT devs and try to start a campaign; as you said, it is “OUR hands to solve it”, so jump in and try to make this happen.
As a positive note to The DiveO’s last comment :-).
Let’s go Jacek and start a fundrising campaign if you want to support such an improvement on the MLT engine (many websites allow as to do it very easily today)!
No problem for me using KDenlive but I understand your point (but not your disappointment).
Thanks for the active work guys.
Cheers
That would be fantastic.
Great work! I hope that will solve the timeline bugs, such as disappearing or incorrectly moved and stuck clips.
That is one of the benefits! 🙂
The Appimage just gives me a black box on Linux Mint 18.1 cinnamon. Still, looking forward to where this goes.
yea.. I get a black box too instead of interface, with lot of errors on konsole like this:
QOpenGLShaderProgram: could not create shader program
QOpenGLShader: could not create shader
shader compilation failed:
this is on Kubuntu 17.04
.b
the appimage gives me an error exporting project on debian testing. with the debian package works fine.
great video editor, keep on.
Hi, please use the forum for support. Thanks.