We release 17.04 with a redesigned profile selection dialog to make it easier to set screen size, framerate, and other parameters of your film. Now you can also play your video directly from the notification when rendering is finished. Some crashes that happened when moving clips around on the timeline have been corrected, and the DVD Wizard has been improved.
Please note that while this major release may seem to have few features development is at full throttle in the refactoring branch. You can monitor the progress here.
Thank you very much for the refactoring process. I hope to see kdenlive totally stable some times.
That would be great to have a stable opensource video editor. Reading the features list, it sounds great. Working with kdenlive or other opensource editor, it become frustrating.
Would be a sign of quality if you could specify which features didn’t work. So, well, your “post” is quite useless as you don’t seem to care helping us with constructive feedback, but just criticize in general.
In the opensource szene it seems not to be a good idea to criticisim something. The people are working voluntary on the projects and so the users have to acept this.
I dont know if you are a developer or not, but have you really tried to realize a video project with an opensource video editor, in this case with kdenlive? The bigger and more complex the project will be, you will find more bugs. Sure, a lot of small bugs but sometimes you loose a lot of time.
The you go to report a bug and sometimes you get no answer.
So why should people report bugs?
The free work which the developers invest in there software ist awesome, but theres a different point of view from developer and user side. And thats the biggest problems using opensource video editors.
I’ve been working with Kdenlive in video projects using RAW Full HD footage for 30 minutes videos and the stability has been more than acceptable. I think part of been proactive and constructive is to take the time to document and and report bugs when encounter as good as one can. I’ve done so even if the answer arrives months later it helps others. Ranting is cheap, helping is rewarding.
+10
Dear Jim, did you check some facts with respect to Kdenlive, and its community?
You should have noticed that I’m using Kdenlive on a regular basis, in many projects. I’ve wrote many of the toolbox posts with a lot of background information. I’m an old hand when it comes to Kdenlive, I use it even in my daytime job, albeit I’m not from the AV field.
But we disgress: you still don’t detail anything with respect to my inquiry, but instead go down yet another route. Don’t you want to answer?
This is my work done in Kdenlive (most of it): https://vimeo.com/gunga
If you have constructive criticism, bug reports and suggestions the team is open for dialogue. If you want to only complain then we don’t want to hear it.
I concur wholeheartedly. I have had a similar experience arguing with the Kdenlive developers here:
https://bugs.kde.org/show_bug.cgi?id=368984
(and other places). You can read their smug, arrogant, self-centered replies. I gave up on them. This is clearly a hobby they indulge themselves in. Users who fail to kowtow them are obviously a nuisance to them.
The devs apparently do not use Kdenlive for much. I just opened a 12 minute video I saved open up many duplicates of video clips randomly placed all over. This a major bug that has persisted for year. They have not fixed it. I doubt they ever will fix it. But they keep adding new features! Hurray! Um… no.
I should have known better. The best approach I have found is to make many very short Kdenlive projects and then concatenate them.
I have learned not to waste my time arguing with FOSS developers including Kdenlive developers. They seem to have good intentions but clearly they focus on new features which they enjoy and often ignore fixing critical bugs.
Well, seems the attributes you are quickly to attach to devs and maintainers can be wholeheartedly attached to yourself. If you ever had checked the bug tracker and discussions you would have noticed the incredible amount of bug fixing going into the project. And even then you are still denying that we work with Kdenlive a lot of ourselves. But don’t let truth distort your alternative facts, so awful. In contrast, several users, including me, have spent a large amount of time to track down and file bug reports, and the devs were spend also lots, lots, and lots of unpaid work to fix bugs. But then, you seem to know better. Thank you for choosing another project, so we can get our work done here.
If I open a Kdenlive project with more than, say, 20 audio and video elements, edit it for a couple of hours, save it more than 50 times (which I do habitually as I work), and quit and reopen it more than a dozen times (having learned the hard way, that one of those times it won’t open the way I left it), then inevitably one of the times I open the project it will open as a jumbled mess. Duplicates of audio and video elements will be strewn all over the timeline. It’s so confusing that unless the project is small (say consists of 20 elements or fewer) I end up creating a new project altogether.
The Kdenlive devs either have “forgotten” about this bug (which has been reported properly), or the Kdenlive code is too convoluted and poorly documented for them to actually find the bug, or they are simply not good enough developers to fix this major, long-standing bug.
Don’t believe me? Do a Google search for “Kdenlive Reddit.” Then you can read for yourself about how people criticize Kdenlive as being “unstable.”
For devs adding new features is fun, bug fixing is not.
I look forward to a new FOSS project that will come along which will be more stable so I can toss Kdenlive where it belongs: into the dustbin along with countless other buggy FOSS apps.
In the meantime, creating small projects in Kdenlive and concatenating is the best method I have found to deal the “if-it-is-big-enough-and-you-work-on-it-long-enough-eventually-your-project-will-open-as-a-jumbled-mess bug we Kdenlive developers are not going to fix.
One of FOSS devs favorite techniques is to ignore bug reports that cannot be very easily replicated reports. If you report a major bug that inevitably but intermittently appears you—the foolish user—are obviously imagining things. Uh. Yeah. Sure we are.
I try to remember that FOSS devs very likely don’t really use the apps they develop the way that users actually do. Instead, the devs seem to develop for their own enjoyment.
1- What you are talking about might be a timeline corruption triggered by the speed effect, if you would’ve reported this in the forum and/or tracker you might have figured it out in a less painful manner. Part of this hard and boring work that is the refactoring is to prevent this kind of bugs in the future. This will bring more stability and better code maintenance to add the pro features power-users need.
2- You can help make this tool better by reporting bugs, helping in the forums, giving contructive criticism or even donating to the project. If you don’t want to do that, fine, just dont expect us to give ears to your negative energy. The communication channels are open, use them! You are also welcome to choose another software to do your editing, so be happy. 🙂
@Jim
Do you know the quotation, “Weinberg’s Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.”
As you stated,
>> In the opensource szene
>> it seems not
>> to be a good idea to
>> criticisim
>> something.
Regarding FOSS, I have noticed that for all but the most black and white situations, legitimate criticism is often ignored and frequently ridiculed. The FOSS devs generally “know” they are right. They seems to think users are merely fools who do not know what they are doing.
FOSS devs are generally out of touch with users. For example, I have no idea why the current speed control feature exists in Kdenlive. I have learned from bitter experience that the Kdenlive speed control “works at first” but it like a quickly ticking time bomb. Soon after choosing speed control, inevitably something will go wrong in my project.
Therefore, I do use this obviously buggy feature. But certainly other unsuspecting Kdenlive users use it, get bitten by this obvious (and longstanding) buggy feature, and correctly assume that Kdenlive is “unstable” (which is merely a polite way of saying full of bugs).
I see the Kdenlive speed control as a simple example of a classic bug FOSS developers tolerate because they prefer more to add more features instead of creating a more application.
Even if they did not want to bother fixing the obvious bug(s) in the speed control feature (which is a critical feature) the Kdenlive developers should have removed the speed control feature many years ago. But they have decided to leave in a known bug. Nice. Very nice.
When I want speed control I use ffmpeg which works flawlessly. Here’s what I run in a terminal from my home directory (in Linux): fmpeg -i input.mp4 -filter:v “setpts=0.5*PTS” output_speed_of_video_changed.mp4
If the Kdenlive devs actually focused on usability they would have at least explained to users that ffmpeg could be used to easily and reliably change the speed of videos. The Kdenlive devs might self-righteously argue it is beyond the scope of the Kdenlive project… and then get back to adding some new feature that fewer than 1% of Kdenlive users will likely ever use.
Or the Kdenlive devs could have created a very simple feature that would have allowed users to choose the video whose speed they want to change, choose their desired speed, and then hit “Ok.” The devs could have passed this information to ffmpeg, which I imagine would would have changed the speed of said video, and then had the new clip appear in the same directory as said video. Easy peasy.
Have the Kdenlive devs implemented either of the two simple and obvious fixes above? No. Why not? Probably because they enjoy adding new features (which 99% of Kdenlive users will likely never use and do not care about) instead of focusing on the actual user experience of the 100% of Kdenlive users who want to Kenlive to be bug-free (despite the fact that sophisticated software is very rarely bug-free).
What if you have a big video that takes up much space on your local drive and you want just a small clip in Kdenlive? Kdenlive could easily allow you to cut out that clip so you would not have a massive video file stored locally. Here’s how I do it with ffmpeg:
ffmpeg -i input.mp4 -c copy -ss 00:01:26 -to 00:03:08 clipped_file.mp4
I put input.mp4 in my home directory, run the above command from a terminal and virtually instantly clipped_file.mp4 shows up in my home directory.
That is a *huge* benefit to me, would likely benefit many other Kdenlive users, is technically trivial, and a feature that seems obvious to me but something the Kdenlive devs have not implemented. Why not? Presumably they enjoy focusing on adding new features not the user experience.
I presume that most Kdenlive users are annoyed waiting 15 minutes to several hours as the Kdenlive code works feverishly to create a video clip which is something ffmpeg does can do in a split second.
But see, very quickly and very easily extracting short video clips from large videos is a feature that is not a cool, bright shiny new object. It’s technically trivial project that would help enable some Kdenlive users to quickly and easily save gigabytes of drive space.
How about incremental backups? Sure the Kdenlvie devs know about rsync but do they know Grsync? The “G” stands for graphical as in GUI (graphical user interface)… but that is anathema to devs who adore CLI (command line interfaces).
I use Grsync on GalliumOS, a flavor of Linux for Chromebooks. It’s a simple app that helps me avoid dealing with the command line.
With Grsync it is trivial for a user to create incremental backups of a Kdenlive project to a USB drive (thumb drive). Again, it’s not technically exciting, but I presume many Kdenlive users would find such a feature very beneficial. The Kdenlive devs might contend that simple, quick, incremental backups are beyond the scope of Kdenlive.
By myopically defining Kdenlive in technical terms (from the self-centered perspective of the Kdenlive devs) that would make sense. But when considered from actual Kdenlive users perspective such an argument is absurd on its face.
The Kdenlive deves should explain something like, “Here’s how to easily create incremental backups to a USB drive. You should create a backup (normally an incremental backup but occasionally a full backup) to an external drive (such as a USB drive) each time you spend more than an hour or two editing your Kdenlive project(s). Such backups will likely take you less than 30 seconds. It’s very cheap ‘data insurance.'”
How about incrementally backing up Kdenlive to a cloud service (such as Google Drive or Microsoft OneDrive)? Sounds like a good idea. Right? After trying to work with more know-it-all FOSS devs (remember, I am merely a foolish user) the following is the best I have come up with:
#!/bin/bash
cd ‘/home/y/MY CURRENT STUFF/ALL AUDIO AND VIDEO/’
find . -mtime -.75 -type f -print0 | rsync -0v –files-from=- ‘/home/y/MY CURRENT STUFF/ALL AUDIO AND VIDEO’ ‘/home/y/MY CURRENT STUFF/Backup of ALL AUDIO AND VIDEO’
When I remember, at the end of each day I work on my Kdenlive projects I run that script and upload “Backup of ALL AUDIO AND VIDEO” to Google Drive. But if I forget to do so, or if I have not worked on my Kdenlive projects for a while then I need to change the .75 above (which stands for 75% of 24 hours or 18 hours) to a larger number such as 4.0 (which stands for 4 days).
These “backup details” are not little to me. And trying to argue they are beyond the scope of Kdenlive is silly. Being able to quickly and easily create incremental backups to a USB drive should be mentioned clearly and up front in the Kdenlive user documentation or even in the FAQs. It should go without saying, but backing up data is critically important. How many Kdenlive users actually backup their data frequently? How many would if they knew it would take then 30 seconds with a simple GUI like Grsync?
And someone should figure out how to create incremental backups using Grsync (which is a simple GUI for rsync) which can easily be uploaded to a cloud service.
Will the Kdenlive devs do this? I am not holding my breath. I presume they are working on some new features for Kdenlive which 99% of Kdenlive users will never use.
>> I dont know if
>> you are a
>> developer or
>> not, but have
>> you really
>> tried to
>> realize a
>> video project
>> with an
>> opensource
>> video editor,
>> in this case with kdenlive?
It is typical of these self-righteous, smug FOSS developers to ignore a germane, unequivocal, direct question which would obviously undermine their ludicrous arguments.
Although I suppose your question was rhetorical, I will take the liberty of speculating. It is likely that the Kdenlive devs do not use Kdenlive to create complex projects. After all, if they were to, they would have been confronted with the slew of bugs you and I have become accustomed to but not innured to.
The Kdenlive devs fix simple bugs that can be quickly and easily replicated. That probably makes them feel like they are responding appropriately to user bug claims.
The Kdenlive code is likely bad and almost certainly poorly documented. In other words, it is very likely a mess. Most devs probably would not understand most of the Kdenlive code even if they took the time to read it.
Devs notoriously hate maintenance; they famously adore new development.
>> The bigger and
>> more complex
>> the project
>> will be, you
>> will find more
>> bugs.
You and I have found those bugs because we actually use Kdenlive to create complex projects. The Kdenlive devs very likely have not because they do not. Along with abhorring maintenance devs (not just FOSS devs but all devs like all engineers) notoriously hate performing quality assurance. In this way, they are like chefs who do not want to clean their own kitchens.
As you probably know, in most software companies, developers, developers do not perform quality assurance. Instead, developers churn out poorly documented code with bugs (in part because they are compelled to meet unrealistically tight deadlines) and wait for the QA department or customers to submit bug reports.
Devs are like cowboys. Eventually farmers overwhelmingly displace cowboys. Pair programming, videoing of coding sessions, requiring devs to create screencasts at the end of each coding session in which they audibly comment on their code, along with the bigger and better libraries of bug-free code, are gradually transforming these cowboys into farmers (or if you prefer transform farmers into city dwellers).
>> Sure, a lot of
>> small bugs but
>> sometimes you
>> loose a lot of
>> time.
That has been my experience as well. But the Kdenlive devs seem to think we are making this up because we are fools using Windows 95 on a 486 and don’t even know how format a floppy disc.
for example, in some cases working with proxy clips make inpossible to play clip to the end, proxy clip ends 2-3 beforereal clip ends. As work around I just add color clip on separate track which is 2-3 second longer than clip.
Please use the forum to ask for help. Make sure to specify the system, distribution, and versions of kdenlive, mlt, and ffmpeg you are using. Also give information about the project profile and prox settings. In order to reproduce we probably need a minimized (!!!) kdenlive project with minimized(!!!) video files that trigger the issues. And no, no-one will look at bug reports which link to several tenths of megabytes or gigabytes of video files.
just crashes,
open clip, played, after 5 second crash
[swscaler @ 0x7f8d384680c0] Warning: data is not aligned! This can lead to a speedloss
[mp2 @ 0x7f8cfb982340] Header missing
[producer avformat] /home/kitru/Documents/proxy/0e1e4510c333b97c1cf7101f4266e4f4.mpg
audio decoding error -1094995529
[mpeg2video @ 0x7f8cfbba6e00] ignoring pic cod ext after 0
Segmentation fault (core dumped)
Please use the forum to ask for help. Make sure to specify the system, distribution, and versions of kdenlive, mlt, and ffmpeg you are using.
Sure, im willing to answer. Look at this post: https://forum.kde.org/viewtopic.php?f=272&t=125642 Until today its not solved. A lot of people have problems to render thier project, but nobody seems to have time to fix this very bad problem.
I think it was in the bug section “bugs.kde.org”. Theri i read that the problems depends on some distributions. But the same project, which chrashes on different Linux versions, chrashed also under Windows.
But other things are more important then fixing this horrible bug which make kdenlive unusable.
The forum post you are refering to doesn’t have to do with a Kdenlive issue but a distro packaging one… Either way I can tell you that by 16.12.3 many rendering bugs got fixed. Are you using a newer version and are experiencing this? Report the bug!
I read that this is not a kdenlive problem, but a MLT problem that now have all the video editing programs that uses MLT! I think they are working on that, someone noticed that bug in every video editing program with MLT!
OK: for years users have reported that when an edited video is rendered, often the process sticks on “Waiting…” with no indication of whether or not anything is happening. It’s still a problem (I’m experiencing it right now.
Can’t use bug report because my PW (which was saved by Kdenlive) is not recognized.
So which version of Kdenlive are you using??? Which distribution? Is it a distro package or an AppImage?
Please make
à appimage so we can use easily …thanks
It will be out soon…
Cool,
I hope it become more stable, 16.04 was a great step forward, but not ideal from stability point of view.
Anyway, great job and many thanks to developers!
Still crashes on ty playback 4k video written by phantom 4 pro
kf5.kio.core: KSambaShare: Could not find smb.conf!
KServiceTypeTrader: serviceType “ThumbCreator” not found
KServiceTypeTrader: serviceType “ThumbCreator” not found
[swscaler @ 0x7f3f3c7fe120] Warning: data is not aligned! This can lead to a speedloss
/tmp/.mount_XImK56/AppRun: line 27: 22865 Segmentation fault (core dumped) kdenlive –config kdenlive-appimagerc $@
I’m sure of that: It will be a great release!:D
Dear Developers,
Eagerly Waiting for windows version of Kdenlive. Could you tell, when Kdenlive 17.04 will be released for windows.
Regards and thanks in advance,
Sunil
+1
Kdenlive-17.04.0-2-w64.7z en:
https://files.kde.org/kdenlive/release/
using it nearly on a daily basis! thanks!
I love Kdenlive. Thank you for your work. Using it on Ubuntu for the past 4 years or so. But something I was always wondering: how come, on the same computer in Windows Sony Vegas (video editing software) it takes 5-6 times less to render the same kind of project? I have quite a powerful laptop (core i7, 12gb or ram, ssd, nvidia 2gb). On Kdenlive even when I export as mp3 or wav it takes 1h to render a 40 min file.
Technically this has to do with MLT, which is the multimedia framework Kdenlive uses, which doesn’t support hardware rendering but progress will come eventually.
Actually it is not true, I opened a discussion in MLT mailing list and after in Kdenlive mailing list. And seems that MLT could use hardware encoding if compiled with a version of ffmpeg compiled with nvenc option enabled (the nvidia hardware encoding). MLT just pass the nvenc option to ffmpeg.
It’s a pity that in the kdenlive repositories MLT is not compiled using ffmpeg with nvenc enabled, because not all people would waste time compiling in Ubuntu.
I compiled only ffmpeg and made a profile on Kdenlive to use ffmpeg nvenc enabled to transcode resized proxy clips in h264 codec at more than double speed. Without resizing ffmpeg nvenc give to me 10 times speed compared to libx264 (CPU) encoding, using my NV GTX 1060. But nowadays I had no success to compile MLT with nvenc enabled. I’m new in this kind of things.
Hello, thank you for the information, I have been looking for making kdenlive use NVEMC. FFmpeg >=3.2.4 (installable from PPA) has uupstream Nvidia NVENC support and does not have to be rebuilt with CUDA
It would be great to add gsp information layer (as dashboard/wirbedit)
btw. I was editing as usual with Kdenlive. It crashed several times – mostly when I add a new track. Also done a lot of work on my documentary I’m working, and now my “zoomed” videos (aspect ratios I fixed with videos inside the project) are all messed up. I love Kdenlive, but putting up with so many such bugs is killing me. Now I can’t even fix those “zoom” problems with videos and if I fix them they may go nuts again. Frustrating. I understand your work is awesome and free (as I know), I too do all my work for free, but I would put a “beta” tag on Kdenlive until it is 100% rock solid.
I have the same problem many crashes. I tried to force the previous version on Kubuntu 16.04 using synaptic, but it seems do not resolves the dependencies. I’m stuck!
The kdenlive-oldstable repository has a too old version of kdenlive and can’t load the project made with a new version of kdenlive. Please is possible to have the previous version of kdenlive on oldstable repository? I have crashes in particular when I use the Affine transaction.
Get the 16.12.2 appimage at https://files.kde.org/kdenlive/release/
One advantage of using an appimage is that it won’t get inadvertantly upgraded.
Thank you Jiri Lebl, you saved my life!
You actually updated during a project?
I have some project that I edit a bit almost everyday, I upgraded the updates of ubuntu without realize that there was also a new version of kdenlive.
You can never do that no matter what software you are using!
OK my fault but there is a way to go back on the previous version?
Please use our forum for help. Since this is a distro specific issue ask in your distro’s forums. 🙂
It is not a distro specific issue because I use the official Kdenlive repositories!
I have ti say that I think I will switch to Windows and Sony Vegas again because again, while working on my 1h+ documentary in Kdenlive lots of my videos got messed up. Explaining: so I add a big video file, i divide it in parts because i only need some parts of it; I then add all kinds of effects to these parts, like speed, or aspect ratio, or zoom. Now I reopen my kdenlive project (no update to the project) and these parts are all messed up inside the project…if I cut one part from min 1 to min 3 now that part is cut from min 2 to min 4. It is a complete mess. I hope I can fix those manually again then render the entire project and I am done making videos in kdenlive for now. I appreciate all your work, and i always promote open source projects, but I am only asking from you to but a “beta” label to Kdenlive for now.
And i apologize if my comments may sound as ‘mean’, it’s just that it is super frustrating to try and work in Kdenlive for the past 3-4 years doing documentary films and have it crash so many times and seeing so many bugs….it slows me down so much sometimes. I wish you would fix these bugs or at least as I said add a “beta” label to it. I will try to submit the bugs I find, unless I switch to Sony Vegas or Adobe
I understand your frustration since it happened to me once, it sucks to edit for hours and things get messed up. Hopefully this year you’ll get to try a better Kdenlive after the refactoring is complete. Here you can keep up with the development branch: https://cgit.kde.org/kdenlive.git/log/?h=refactoring_timeline
Hi Tio,
The speed effect is what triggers the timeline corruption bug you are describing, don’t use it! This is kind of a known issue and it is being fixed.
Have you kept up with the latest news on what is coming to Kdenlive? This post will fill you in with what is happening: https://kdenlive.org/2017/03/kdenlive-status-update/
Do you have a place where we can see your work? Here is mine: http://vimeo.com/gunga
Cheers
Only for curiosity. I myself prefer that you devote time to other important features, I also know that Kdenlive is not a DVD authoring program, but since they continue to improve DVD Wizard, I ask: would it be very difficult to add the sub menu feature? That is, in the “Target” option choose another menu. I think it would be very useful.
Thank you for another great release. 😉
Any chance of thumbnail array throughout the video strip, so the user can orientate faster? Like an array of frame thumbnails, dependable of the zoom level?
I installed Kdenlive for Windows and installed the ffmpeg as instructed. but the old effects like “Vertigo” is not working in the windows build. the picture just goes black. Is this an error or is it because i forgot to install some files? Please help.
video effect transform -> distort not working
reinstall and horraay its work!
Please report this in the forum or bug tracker.
Help, COMPOSITE transition generates segmentation fault!
Please report this in the tracker or the forum to get help.