Kdenlive, Shotcut, DaVinci -- Best of all worlds

[Lumixuser]

Hi there,

I’ve been using Kdenlive alongside DaVinci and Shotcut on Linux and Windows for a few years now. They all have their use cases, pros and cons, and I’m glad I have all three of them available for different tasks. Premiere, in my experience, is just too buggy and crash-prone to be considered for serious work by me, and Avid as a vendor is just, well … Fortunately, I don’t work in Hollywood.

DaVinci is superb when it comes to colour grading and colouring, but this comes at a price in terms of complexity and the high learning curve, especially node-based editing, even though I think the sales price is OK, and it’s not a subscription fee. DaVinci, however, needs obscene amounts of memory in addition to the licencing cost, and memory is becoming really expensive in the near future, thanks to the AI bubble. I don’t think DaVinci’s node-based editing should become a part of Kdenlive. However, there are some details Kdenlive could learn from it, mostly regarding the UI. One is the Text/Title tool. Another one is the colour picker for the vectorscope, e.g. to pick the skin colour in a video (tiny detail, but a timesaver). While I can do most of the colour work I can do in DaVinci in Kdenlive, it would be nice if Kdenlive could just switch to something like Davinci’s superb colour workspace with all major tools available in one tab/widget, at least by default. An intermediate step could be to display only the “filters” relevant to a working space: Audio, Effects, Colour, so that it’s easier to create, arrange (UI) and save a Colour (or other) stack as one dialogue/widget (although I’m not sure whether this is possible with Qt).

As regards Shotcut, the software has seen a lot of improvements lately, and it’s been incredibly stable – no crashes in years, and in its latest iteration it also supports hardware decoding. For a quick edit at reasonable quality, it’s the go-to software for me. Unfortunately, its colour-grading tools aren’t nearly at the level of Kdenlive, let alone DaVinci. Since it uses MLT and ffmpeg, its file format support is equal to Kdenlive. The UI (as you probably know) is a little different compared to other non-linear video editors, but it has some really nice and sometimes innovative features. Here are some cool Shotcut features you may want to consider for implementation:

• Select a clip in a timeline (same track) and move it to the left over the previous clip → transition/composition. You can then select and adjust the transition, and you also get a mini preview of the transition. This isn’t the most precise way to do this, but it’s fast, and you can adjust it. Render priorities are clip → transition → track → project

• Immediate cut at playhead position (i.e., you don’t have to switch into the scissor mode and then click on a clip in the active timeline, but the cut happens immendiately – try it!). This would require two visually available cutting options or two cutting modes: immediate cut at the playhead and a cutting tool (persistent) mode.

• Ripple delete (context menu); much faster than in either DaVinci or Kdenlive

• Workspace-dependent display of effects (audio, colour, FX) remotely similar to DaVinci (see above)

• Buttons under the project preview to jump to the next cut/transition/clip (i.e., not just keyboard shortcuts)

• Glaxnimate is now being packaged with Shotcut, hence no worries about incompatibilities regarding Glaxnimate versions. You should do the same.

Bringing together the best of all worlds seems like a good idea to me, and I hope you’ll find some inspiration in this posting.

Thumbs up, and keep up the good work!

Christoph

[candidexmedia]

Thanks for sharing your experience, as someone who has experience with different software. Some notes:

@Lumixuser

Select a clip in a timeline (same track) and move it to the left over the previous clip → transition/composition. You can then select and adjust the transition, and you also get a mini preview of the transition.

Could you share a screen recording of this, for those of us who aren’t familiar with what you mean?

Is it the same as swapping clips around in Insert Mode? :

@Lumixuser

Immediate cut at playhead position

SHIFT + R does just this. You can use CTRL + SHIFT + R to cut all the layers at the playhead:

@Lumixuser

Ripple delete (context menu); much faster than in either DaVinci or Kdenlive

A screen recording of this as well would be helpful.

@Lumixuser

Workspace-dependent display of effects (audio, colour, FX)

This is a fantastic idea! I’d highly suggest creating a wishlist item / feature request:

Filing a Bug Report — Kdenlive Manual 25.12 documentation

@Lumixuser

Glaxnimate is now being packaged with Shotcut, hence no worries about incompatibilities regarding Glaxnimate versions. You should do the same.

If this becomes a thing, I’d suggest making it an optional add-on in the installation, similar to how Inkscape allows you to include Python when you install it. I think the other libraries and plugins should be included as options as well (text-to-speech, object segmentation, object tracking, etc.) since they can add significant weight to the app, and may not be useful to everyone.

[Ron]

@candidexmedia

@Lumixuser

Workspace-dependent display of effects (audio, colour, FX)

This is a fantastic idea! I’d highly suggest creating a wishlist item / feature request:

Kdenlive doesn’t really have different ‘modes’ - at least not in the sense that it works differently or has different features available, everything is always available everywhere, and the ‘layouts’ really choose just that, what widgets are visible where and how much screen real-estate they are given - the default names for the layouts and what things are in them where are in some sense ‘arbitrary’, they are just initial suggestions that you can completely change to something that suits you better if you wish.

So I’m not quite sure how we’d make this “workspace dependent”? But we do already have some filters for the effects, so you can select if you only want to see audio or video or favourite events etc. (and should be able to include your default choice for that that as part of a saved layout) - so if there are other categories to filter on which may be useful, in addition to how they are already categorised in the collapsible tree, we could consider expanding that somehow.

Beyond audio and video it gets a bit fuzzy though. Is ‘alpha’ a colour? In which case does anything which adjusts alpha (like ‘transform’) get included in a ‘colour’ filter? Or only things you might use for colour grading, which can be a slightly different fuzzy set depending on how specialist your use case…

But ideas about how to improve that would definitely be good to kick around here a bit more with an eye to shaping that into an actionable feature request.

[Lumixuser]

@Ron

First of all, the other effects would be still available in the same workspace, just not be displayed by default. You could still access them via the search. That’s how Shotcut does it, and I think it’s a good compromise, compared to DaVinci.

Second, since the “Color” workspace is specifically designed for colour grading/colourising, it should, IMHO, only display the filters relevant for these tasks.

[Lumixuser]

@candidexmedia

As to your first point: No it’s not the same. Regarding the second, as well as the “jump to previous/next cut” buttons in the project preview (which you didn’t mention), I’m aware that the functionality exists, but not in the UI. That was my point. I’ll create a few GIFs to show what I mean later.

I also mentioned the ease to determine and check the skin colour in DaVinci, which is so quick and easy compared to Kdenlive. In DaVinci there’s an eye dropper in the vectorscope that I can use to pick a colour (esp. skin), which will then be shown in the vectorscope. The latter looks otherwise very similar to Kdenlive’s. In Kdenlive I first have to isolate the skin region with rotoscope (mask) in the “Editing” workspace and then switch to the “Color” workspace to see it. You guys know how to implement a simple eye dropper, dont you?

I think there’s a major difference between Glaxnimate and text-to-speech, because the latter is huuuuge, whereas the former is relatively small. This doesn’t matter much on Linux, since there you have package manager, but for Windows it really makes a difference (no idea how this would work on macOS).

[candidexmedia]

Just an FYI: Not sure if the eyedropper comment was addressed to me, but I don’t work for Kdenlive lol. Even though this is an official forum, I don’t know how often the devs actually check every post, so your best bet for any feature request is the bug tracker.

@Lumixuser

As to your first point: No it’s not the same. Regarding the second, as well as the “jump to previous/next cut” buttons in the project preview (which you didn’t mention), I’m aware that the functionality exists, but not in the UI. That was my point. I’ll create a few GIFs to show what I mean later.

I didn’t mention the jump to next/previous cut, because it sounded like you were aware of the shortcuts for those, but not for cut at playhead. Using a UI button to cut in place seems kind of clunky to me, and learning shortcuts is something my video profs have stressed on for efficiency, but it might have its use cases?

@Lumixuser

I think there’s a major difference between Glaxnimate and text-to-speech, because the latter is huuuuge, whereas the former is relatively small. This doesn’t matter much on Linux, since there you have package manager, but for Windows it really makes a difference (no idea how this would work on macOS).

I’m on Windows, so being able to check/uncheck plugins and add-ons to include when installing isn’t unusual. Personally, I wouldn’t want Glaxnimate to be packaged with Kdenlive, but having it as an option wouldn’t hurt.

[Lumixuser]

@candidexmedia

I’m a trained teacher and have also worked in IT training for more than 15 years. I also worked as a volunteer for Open Source projects and was involved in UI optimisation. That being said, in the long term shortcuts really help with efficiency, but to get beginners up to speed with a software, I still think that the old rule of thump (every shortcut needs to have a UI equivalent; the other way around isn’t always feasible, because it’s hard to draw with a keyboard) is still valid. Our brain generally needs visual feedback when using something, no matter whether it’s a book, a lawn mower, or a piece of software. It’s also helpful to think about people who have learned to use another product where the shortcuts are probably different. For instance, the “cut at playhead” shortcut in Kdenlive is Shift+R, in Shotcut it’s S. Having a button with a tooltip that includes the shortcut really helps.

[Eugen_Mohr]

@Lumixuser

Ripple delete (context menu); much faster than in either DaVinci or Kdenlive

The fastest way for ripple delete is Ripple Trim to Playhead beside the 4 possible ways of ripple delete.

[Ron]

@Lumixuser

the other effects would be still available in the same workspace, just not be displayed by default.

That’s exactly what we already have today. And people who want that can save their selected filtering(s) with the layout(s) they want it to apply to.

If you want to add more predefined categories to that filtering, then you should propose what categories you want to add explicitly along with which effects you think should appear in them. Then we’ll have something actionable we can discuss.

There might be something we can usefully do there - but the devil is in the precise details, so this is something we’ll need to look at Precisely, not in a handwavy “you know, the colour tools” kind of way.

I’m aware that the functionality exists, but not in the UI.

What does that even mean? Keyboard interaction is a fundamental part of many elements of the UI. If every available function had a button on the screen there would be no room left to do any actual work. There aren’t even enough keys on the keyboard to map all of them to keys by default …

I’m all for making things as simple and intuitive as possible for onboarding new users, but if you can’t learn a few basic keystrokes then you’re probably in a world of trouble that we can’t ever help you with. And you don’t make things “simple and intuitive” for new users by adding even more buttons on the screen that they need to understand and sort through to find the one that they actually want.

We already have people asking if functionality exists that there is a button for on the main screen, which has a tooltip and/or is hinted at on the status line - because they simply didn’t see it in the already existing (somewhat necessarily) noisy set of options. And you don’t fix that by adding even more buttons that only one or two users might ever use.

So this isn’t a “you guys know how to add a button, don’t you?” thing. Good engineering is as much, if not more, about what you can usefully remove as about what else you can plaster on.

difference between Glaxnimate and text-to-speech, because the latter is huuuuge, whereas the former is relatively small

Where by “relatively small”, you mean “would only double the size of the kdenlive package instead of increase it by many multiples”. And it would do this for every release of Kdenlive regardless of whether Glaxnimate had actually also had a release or not, and make it harder to test new versions of it that are compatible.

for Windows it really makes a difference

Then windows users should come up with some solution that fixes the problem on their platform. One that doesn’t create problems for Everyone Else. But again, this has not been a problem we’re seeing anyone actually report, so it’s not clear who would actually benefit from the large cost it would impose on just about everyone else, from developers and release managers to end users who don’t use Glaxnimate at all?

@candidexmedia

but I don’t work for Kdenlive

Nobody works for Kdenlive : ) It’s the collective work of volunteers. Some who wear KDE hats, some who don’t. And when you make useful contributions here, that includes you too.

your best bet for any feature request is the bug tracker.

Filling the tracker with half thought out, implausible or impractical, requests doesn’t actually help anyone. In fact it just makes more busywork for someone else who then has to triage and close them instead of spending that time on actually improving things.

So it’s actually very worthwhile kicking them around a bit here first to sort out the rough edges and give them some shape. Actually actionable things (confirmed bugs and practical, well thought through, feature requests) belong in the tracker to remind us they need attention, this isn’t the right place for that - but it’s not a great place to shape and discuss half-formed ideas, this is the right place for that part of the process.

I don’t know how often the devs actually check every post

Or how often there is time to give attention to random posts to the tracker ;?

That’s the fun thing about collaboration - everyone doesn’t have to see everything, but we all make sure the people who need to know about something find out about it. If you post something here that needs action, it will get to whoever needs to act on it.

If you’re not sure if it does, or exactly what that action should look like, or who should do it, this is definitely the right place to start.

@Lumixuser

For instance, the “cut at playhead” shortcut in Kdenlive is Shift+R, in Shotcut it’s S

And if you’d prefer it to be ‘S’, we give you the ability to map it to that key.

Don’t get me wrong, you talking about your real lived experiences is extremely valuable to us - but before you can teach something, first you need to learn it. It’s not enough to know how to teach, you need a sufficiently deep knowledge about what you’re trying to share.

And I’m not getting the impression you have that about Kdenlive yet.

It’s a tricky thing, you’re in that transition where everything is new to you, and all our rough edges are keenly and sharply felt - so you get to notice things that the rest of us long ago became numb or acclimatised to - but you don’t yet understand how they got to be that way, or what the benefits of them being so are …

And that’s a window you won’t be in for very long, and which we’d be silly to waste - but it’s like the problem with Documentation. The people who you think would be the most qualified people to write it are actually the worst people to get to write it - because documentation is for people who don’t yet know things, and those expert people long ago forgot what everybody else doesn’t know about their Specialist Subject.

So you need someone who is learning the subject to write the documentation, and the specialist’s role in that is to review what they wrote and help find language to correct what they got wrong.

So you telling us about what you tried to do, and what problems or stumbling blocks you had with doing that, is extremely valuable. And if you have suggestions, we’d love to hear them. But you’re not explaining this to a 101 class, so the real big picture is going to be considerably bigger than what you’re so far seeing, and the real answers aren’t going to be as simple as they might seem to you right now.

[candidexmedia]

@Ron

That’s exactly what we already have today. And people who want that can save their selected filtering(s) with the layout(s) they want it to apply to.

Didn’t know that was possible, sweet! I don’t see a reference to this in the docs, but I’ll investigate later once I’m at a computer.

Edit: just checked on my Windows PC, but I don’t see an option to save/map Effect filtering to a layout. The filtering didn’t seem to persist when I saved a custom layout (v.25.12.3):

@Ron

Nobody works for Kdenlive : ) It’s the collective work of volunteers. Some who wear KDE hats, some who don’t. And when you make useful contributions here, that includes you too.

When I say “work for Kdenlive”, I mean the people listed here who meet for sprints.

Regardless of whether or not they’re paid, I’m saying that I’m not part or the team of people who (I assume) have the final say on which direction the project goes in. We can all contribute and be part of the community, yes, but we aren’t all maintainers / core team members / holders of official account passwords / roadmap deciders / donation handlers / etc.

That said, someone let me know that you are part of the team (?), so I removed your username from my reply.

@Ron

So it’s actually very worthwhile kicking them around a bit here first to sort out the rough edges and give them some shape. Actually actionable things (confirmed bugs and practical, well thought through, feature requests) belong in the tracker to remind us they need attention, this isn’t the right place for that - but it’s not a great place to shape and discuss half-formed ideas, this is the right place for that part of the process.

I was going off based on the Kdenlive website, which says that the chats and forums are to “share experiences and get help”, and the Bug Tracker step-by-step linked from there says that feature requests go in the tracker as well. Some parts of OP’s initial post were experience sharing, yes, but other parts sounded like feature requests to me.

If the current workflow for feature requests is to run them through the forums and chats first until they’re polished / detailed / actionable / thought through enough for the tracker (based on the community’s input? based on a core team member’s or admin/mod’s final say?), this should be made clear on the website’s support page(s) and communicated in the other channels.

[Eugen_Mohr]

@Lumixuser

every shortcut needs to have a UI equivalent; the other way around isn’t always feasible, because it’s hard to draw with a keyboard

I think this is a valid point. Specially for first or new users.

@Lumixuser

[Icon for] Immediate cut at playhead position

How to cut at the play head? This question comes up frequently, specially from new users. I added this point to our internal issue: Timeline UI redesign ideas

@Lumixuser

Buttons under the project preview to jump to the next cut/transition/clip (i.e., not just keyboard shortcuts)

I added this point to our internal issue: Refactor the monitor UI

[Ron]

@candidexmedia

@Ron

That’s exactly what we already have today. And people who want that can save their selected filtering(s) with the layout(s) they want it to apply to.

Didn’t know that was possible, sweet! I don’t see a reference to this in the docs

It’s not directly part of the ‘customisation’ as such, it’s just the normal functioning of the effects widget that you can use at any time - but saving the layout should save the widget states at the time of saving.

Though actually checking that right now - it looks like the filter state isn’t being saved with the rest of the window/widget state in the current layout code - so if people think it’s really worth saving the selected filter state with a layout, that is an actionable feature request that could be filed, and probably a pretty easy entry level patch if someone feels up to submitting one for it.

That’s a separate thing from whether we can usefully add more categories to the filters though. Personally I tend to think that if you want an optimally reduced subset to choose from, then putting them in favourites, or saving them as pre-configured custom effects is probably what you Really Want once you’ve been doing it enough to actually settle on something that works the best for you - but generally I’m fine with anything that doesn’t just trade one user’s perceived convenience for someone else’s optimal workflow or the like.

I’m not part or the team of people who (I assume) have the final say

In any good team it should be good ideas that win the day - so if your idea is the best one, and you implement it well, or convince someone else it’s worth their time to, then you’ve still been a valuable part of it, whatever hats you otherwise or outwardly wear.

If the current workflow for feature requests is to run them through the forums and chats first until they’re polished / detailed / actionable / thought through enough for the tracker

This isn’t some sort of formal requirement - and nobody is going to summarily close your tracker issue just because you didn’t do that first. But it will have a much better chance of actually getting some attention if it’s either a very precise report of a bug with enough information for others to reproduce it, or a well polished feature request that’s actually both feasible and desirable and has some consensus behind it.

If it’s not, you’re more likely to get people to engage with you and get it to that point here than you are in the tracker. Bad or incomplete ideas that get floated here can just fade away until or unless someone comes along (maybe even years later) with some improvement to them. Whereas those things in the tracker often just become clutter, that makes it harder to find the things in there which are actionable, and also commit someone else to eventually have to find the time to sift through them and close them.

So in an environment where “developer time” is our scarcest and most valuable commodity, it’s just common sense (in that sense of “things we’ve learned the hard way over many many years”), to get some peer review on anything you aren’t Certain about or have a tested patch for.

This is another use the right tool for the job thing. The tracker is great for things we know we won’t get to today, but definitely do want to at some point. It’s not a great place to discuss things and build on initially rough ideas. This forum is somewhat the opposite of that, so using them both together intelligently should generally get the best results.

Important and urgent problems posted here will get to the same people as they would via the tracker. Less urgent things that we need to not forget we’ll advise you to post to the tracker. Half-formed ideas posted here might get you some engagement from a wider audience to try and clarify or improve them rather than just joining the ranks of Things Nobody Has Time To Deal With in the tracker. There’s no hard and fast rules that say those things are Law - it’s just the lore and emergent reality of how things most efficiently get from the sausage factory into the actual sausage, in practice, today.

I’m not here to police which of many paths you should choose. But some of them definitely have a better chance of getting you nearer to where you actually want to be than others.

[Lumixuser]

Here’s a GIF with some actions we discussed in Shotcut. (Cut at playhead via UI, ripple delete via context menu, same-track transition, preview of the transition in the transition dialogue). Unfortunately I had to create it on Windows, since my Linux machine is in the repair shop, so the UI fonts are probably a bit too small.

[Lumixuser]

@Eugen_Mohr

Since you mentioned internal discussions about timeline improvements, here’s another idea from something totally unrelated to video/audio.

The Open Source DTP software Scribus introduced a feature called “Sticky Tools” years ago. This means that a selected tool (in Scribus, for instance, insert image frame; in Kdenlive it could be cut at playhead) remains active until deactivated. I admit that haven’t thought this through yet, but I think it’s an interesting concept. Just as an example, there could be a single cutting tool button in the UI, but also another (“sticky tool”) one. “Sticky” would mean “cut wherever the playhead is”, whereas the deactivated “sticky” would revert to the current behaviour (or the other way around).

[Lumixuser]

@Eugen_Mohr

My apologies. I went right to the shortcuts and wasn’t aware that “Extract Clip” means “Ripple Delete”. I was confused, because Kdenlive uses “Ripple” in other contexts, so that seems to be a bit inconsistent, at least to me.

[Lumixuser]

Another very minor feature from Shotcut that’s very useful but doesn’t exist in Kdenlive: If I drag a clip from the playlist not into an empty timeline, but instead into the very left of the timeline, and I mean the one with all the track options (name, enable/disable, lock), it’s automatically being inserted at 0:00:00:00. In Kdenlive (and others) it’s a bit of hit and miss. Not a big deal, and there are other problems with Shotcut’s timeline that Kdenlive doesn’t have. But this is a good one.

[Lumixuser]

And another one, also minor but useful, albeit perhaps unique to many of my projects. Background: I have to edit a lot of old stuff, i.e., digitised material from 8mm, 16mm, 35mm film, analogue video tapes, in some cases even Laserdiscs. This is where Kdenlive’s great colour tools shine and where DaVinci is still overkill (given the limited colour range), whereas Shotcut is coming up short.

In these cases I only need one track. If I have to deal with b/w clips and only need to do minimal colour corrections (like contrast, brightness) and do a few cuts, Shotcut is fine and fast. Where it is really helpful, though, is the project export, where I often need the source file name as the basis for the exported one, e.g., “dolphin_documentary_bbc” –> “dolphin_documentary_bbc_edited”. In Shotcut I can use the clip properties and copy the clip’s source file name (or parts of it) to the clipboard. In the export/render dialogue I can then paste the name. That’s currently not possible in Kdenlive.

See screenshot.

[berndmj]

@Lumixuser

That’s currently not possible in Kdenlive.

It is: Right-click > Copy

[Lumixuser]

Thanks for your reply, but it isn’t. What you describe is copying the path, not the name of clip (or parts of it) as selected in the properties. But again, this is just a minor detail.

[Ron]

@Lumixuser

Thanks for your reply, but it isn’t.

It really is. As usual in many ways. And the simplest doesn’t involve opening the clip properties at all. Just copy it from the bin. Or any of many other places it appears.