Kdenlive 18.08.3 is out with updated build scripts as well as some compilation fixes. All work is focused on the refactoring branch so nothing major in this release. On the other hand in the Windows front some major breakthroughs were made like the fix of the play/pause lag as well as the ability to build Kdenlive directly from Windows. The next milestone is to kill the running process on exit making Kdenlive almost as stable as the Linux version.
In other news, we are organizing a bug squash day on the first days of December. If you are interested in participating this is a great opportunity since we have prepared a list of low hanging bugs to fix. See you!
Bugfixes
- Fix finding MLT data in build-time specified path. Commit.
- Fix play/pause on Windows. Commit.
- Try catching application initialization crashes. Commit.
- Fix MinGW build script misses. Commit.
- Backport some Shotcut GLwidget updates. Commit.
- Fix MinGW build. Commit.
- Install doc files. Commit.
- Build scripts for Linux & Windows. Commit.
- Backport packaging scripts. Commit.
- Fix MinGW build. Commit.
- Backport fix for incorrect bin rename. Commit. See bug #368206
Upon relaunching this version the theme is changed from dark to white. Regardless if I change it back to dark on relaunch it’s white again.
Thank you for the hard work that went into this release though!
I hope the undo bug has been fixed in the refactoring; I didn’t see it in the list of fixed bugs.
Had the same issue. Change settings -> “force breeze icon theme” several times on/off and the issue is gone. Or delete the file “kdenliverc” on share.
This is not the refactoring branch. Check if the undo bug is gone.
That doesn’t work for me. I’ve repeated the on/off thing about four times, and deleted the file you mentioned from the .config directory. I guess I’ll just have to manually switch it on every time I launch the app.
Will let you know if the undo bug persists.
I thought this was the refactored version. Is that what’s coming next month?
Just saw that the undo bug is still there.
For anyone reading this who doesn’t know what this bug is, it’s basically when a number of undos and redos cause a clip to become unmovable, and sometimes (right before a crash) it will seemingly copy itself to an adjacent timeline track, except it’s not a copy, it’s actually moved there. The original clip still shows, but it is like a shadow because there is no actual video there if you play the timeline. If you continue to work after this happens the next action will crash Kdenlive. Upon relaunching Kdenlive you see that the clip is still on the adjacent timeline track and its original (shadow) position is then empty. As a workaround when this bug happens, don’t try to move the clip back, just save your work and restart the application, then continue as normal.
This bug is particularly nasty when moving multiple clips at the same time; when this bug happens when doing so and on the next action it crashes, then upon relaunching Kdenlive the multiple clips you moved have spread across the timeline, so you then have to put all of them back into place. As a workaround for that, group the clips, move them, then ungroup them (sometimes I just leave them grouped).
I now work around this bug seamlessly, so it’s not really an issue for me anymore, other than having to leave the application temporarily and then restarting it. It would be nice if it could be fixed in the future though.
Honestly Kdelive is the best video editor I’ve ever used, nothing beats it! I keep finding out new features and wonder why I have started using it before. The GUI always looked daunting to me, until I found out I could customize and simplify it. I’ve been promoting Kdenlive to everyone who edits videos. It’s amazing this software is free!
I know this isn’t really the place for it, but if possible, as a feature request, I would love a simpler way to rotate portrait videos from smartphones, because at present it’s tedious to do. Just a simple button on a toolbar that turns a clip 90 degrees clockwise or counterclockwise would be great!
Please note that this bug should be fixed in the refactoring branch. Try to test it and give your feedback. 🙂
Farid, I tried that version but the way the timeline shows the video and audio in separate tracks and the black with green outline drives me nuts! I hope they change that in the final version because I rather live with that bug than use the software that way.
Oh, all the work now is focused on the backend. There will be a new design for the timeline.
Try with WINDOWS 10, it’s incredibly rewarding, everything works well, even “force breeze icon theme”
Coincidentally I installed Windows 10 April release yesterday so I could decently run SketchUp, instead of under Wine, but I couldn’t get my wifi working anymore. I’m glad I no longer need Windows 10 for my workflow. Judging from the latest updates Microsoft makes a complete mess of its latest OS.
I use Lubuntu 18.04 LTS with a heavily customized Openbox setup. I will never look back again.
Kdenlive 18.04.x, 18.08.x, etc, etc ….Why waste time in a discontinued branch of development? My beautiful and extraordinarily efficient and neat WINDOWS 10 does not deserve this abuse !!!!!
?
What about kdenlive Windows Version ?? Not showing 18.08.3 in Windows download link. When it comes ?
Use hitfilm express (or DaVinci Resolve), it’s free and your beautiful WINDOWS deserves it
You are free to share your opinions but if you are just trolling you might get banned.
why ? , I use kdenlive and I like it, but if all the attention of the development team is set on the refactored version, what is the meaning of this “new version” that will soon be discontinued? Recommend DaVinci Resolve, which is free, while waiting for a stable version of Kdenlive (refactored) is a reason to ban? hmmm ..
Well you sounded like were trolling so I am giving you a heads up. Also the new versions come with some minor bug fixes and usability improvements…
The free version of Davinci, plays Mp4? I tested it on linux just out of curiosity and just played the audio of the video. So far Kdenlive is the only semi-professional editor that does not place restrictions on formats.
Since free version 14 runs mp4 (Windows).I’m testing Manjaro Linux and I’m having problems with mp4 too.
Thanks, it means that I’m not the only one.
Windows version will come soon. Has to be compiled.
on version 18.08.3-x86_64.AppImage CPU usage it very high in idle,
18.08.2-x86_64.AppImage is ok
on another computer is ok 18.08.3-x86_64.AppImage, I probably have a problem with the first computer
Use WINDOWS 10, it’s very rewarding
I use kubuntu 18.04
hello
I’m using kdenlive on my “linux mint” and i’m so happy with it. I want use it with mac osx too.
I’m not able to find any documentation about it 🙁
any help?
It isn’t something very complicated to do but we don’t have the resources to do it. If anyone can step in to help it would be appreciated.
As usual, unstable. Tried with 4 clips + generate slideshow of 5 images pan zoom. After render craches on last second with
//STARTING RENDERING: true , false , “/tmp/.mount_GvnukD/usr/bin/melt” , “atsc_1080p_25” , “avformat” , “-” , “/tmp/kdenlive_rendering_nmLUXf.mlt” , “/home/kitru/Documents/airplane.mp4” , () , (“properties=x264-medium”, “f=mp4”, “vcodec=libx264”, “acodec=aac”, “g=120”, “crf=23”, “ab=160k”, “preset=faster”, “threads=4”, “real_time=-6”) , 0 , 7696
Skipped method “slotGotProgressInfo” : Type not registered with QtDBus in parameter list: MessageType
Skipped method “slotTimelineClipSelected” : Pointers are not supported: ClipItem*
Skipped method “slotTimelineClipSelected” : Pointers are not supported: ClipItem*
Unsupported return type 65 QPixmap in method “grab”
Unsupported return type 65 QPixmap in method “grab”
airplane.mp4 crashed
[mp4 @ 0x7fdb74000f00] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. [mp4 @ 0x7fdb74000f00] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
airplane.mp4 crashed
[mp4 @ 0x7fdb74000f00] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. [mp4 @ 0x7fdb74000f00] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Big step forward, not crashed during editing, big step backward, you can’t be garanti that your result of work for hours can be rendered without crashes…. again
Kirill, here are some possible solutions:
Group your clips into one big group before you render.
If that doesn’t work, try rendering in webm. I don’t know if you need this in mp4, but I use Kdenlive for YouTube and I can tell you I can not see a difference in picture quality.
If you still want mp4, render in webm and then use ffmpeg to convert the file to mp4 without real loss of quality. You can do it using a program such as WinFF, or with ffmpeg in a terminal (command line).
“threads=4” -> try with 1 max. 2
It does not depend on thread amount, it crashes bbecause of image clip generation independ on with or withour zoom crop centrer pan and so on.
I have found only one workaround-remove image clips, left only few images. As I understand it is some issue with jpeg SOS signal due to unstandard tag or something with pics.
Kirill, what if you convert the jpgs to png or some other format?
If that doesn’t work, create a separate project and just render the image sequence as a video, then import that video into your original project.
it is a option. Did not tried, but it is strange that preview render is working, but final render crashes on 99%
“threads=4” -> try with 1 max. 2.
I had the same issue (with the flatpak) on an i7-7500U CPU on a Debian Stretch. I converted the GPU-accelerated effects to software ones, and the rendering is working now
(thanks strace -f -tt -o 🙂 )