Kdenlive: a Qt and MLT video editor you build from source

What Kdenlive solves, and who the repository is written for

Kdenlive is a video editor. The README describes it as free and open source and says it brings "professional-grade video editing capabilities to everyone", which is marketing language, not a specification. What the repository actually tells you is more useful: the editor is written in C++ and sits on top of MLT for editing functionality, with Qt and KDE Frameworks 6 for the interface, plus frei0r for video effects and LADSPA for audio effects. That stack defines the audience. If you already run a KDE desktop, the toolkit dependency is nearly free. If you are on another desktop or another operating system, you are pulling in KDE Frameworks 6 to run one application.

The README is split between two readers. Users are sent to kdenlive.org, where the project says downloads for stable releases and experimental daily builds live. Developers get a pointer to dev-docs/build.md, dev-docs/architecture.md, dev-docs/coding.md and dev-docs/mlt-intro.md. There is no install command in the README itself, no list of supported platforms, and no system requirements. Anyone deciding whether to adopt Kdenlive has to leave the repository to find that out, and that is a deliberate choice by the maintainers rather than an oversight: the documentation for building and architecture is kept in-tree, the documentation for users is kept on the website.

How the MLT core and the Qt front end divide the work

The architecture is a two-layer split, and the split matters when you debug. MLT owns the editing engine: clips, tracks, transitions and the rendering graph. Kdenlive owns the interface and the project model on top of it. Qt and KDE Frameworks 6 supply the widgets, dialogs and platform integration. Effects come from outside both layers, through frei0r for video and LADSPA for audio, which means an effect that misbehaves may be a plugin problem rather than an editor problem.

That layout explains several things a user notices. The renderer/ directory in the repository is separate from src/, so export and preview are their own concern rather than part of the main application tree. The plugins/ directory and the frei0r and LADSPA dependencies mean the effect set is not fully determined by Kdenlive's own release cycle. The dev-docs/mlt-intro.md file exists precisely because MLT is a separate project with its own concepts, and the README tells new contributors to read it if MLT is unfamiliar. If you are evaluating Kdenlive for a pipeline, the question to ask is not only whether the editor works, but whether the MLT version you have produces the output you expect.

The repository also carries a thumbnailer/ directory and a fuzzer/ directory, alongside appiumtests/ and tests/. Those are the parts of the tree that tell you the project treats rendering correctness and input parsing as things worth testing. The README says nothing about any of them, so the layout is the only evidence available.

Installing Kdenlive and making a first cut

The README does not give install steps. It says downloads for stable releases and experimental daily builds are on kdenlive.org, and it points developers at dev-docs/build.md. So there are two honest paths: take a build from the website, or follow the in-tree build instructions. What follows describes what the repository contains, not a build that was performed here.

The build documentation lives at dev-docs/build.md. The repository is a CMake project, so the top-level CMakeLists.txt is the entry point, and config-kdenlive.h.cmake shows that a generated configuration header is part of the build. Read dev-docs/build.md for the exact configure and compile commands the project expects, because the README does not reproduce them and the required MLT, Qt and KDE Frameworks 6 development packages are declared in CMake rather than vendored. Expect configuration to fail early if any of those are missing.

For a packaged install, the repository ships the packaging metadata rather than the packages: packaging/, snapcraft.yaml and .flatpak-manifest.json are all in the tree. The Flatpak manifest is the one to read if you want to know exactly which libraries a sandboxed Kdenlive build pulls in, because it lists them explicitly. Once you have a running editor, the first real task the README's own framing suggests is a simple project: import a clip, place it on the timeline, and render it out. The README describes the tool as suitable for "a simple family video" as well as complex work, so a single-clip export is the smallest thing that exercises the MLT path end to end.

Where Kdenlive is the wrong tool, and what the README will not tell you

The README is silent on rollback. It is silent on system requirements. It is silent on which platforms are supported. It is silent on performance. If your adoption decision depends on any of those, the repository does not answer it, and no amount of reading src/ will substitute for testing on your own hardware with your own footage.

The dependency chain is the concrete limitation. Kdenlive is C++ on top of MLT, Qt and KDE Frameworks 6, with frei0r and LADSPA for effects. That is a large surface. A distribution that ships an older MLT than the Kdenlive build expects is a real failure mode, and it is the kind of failure that shows up as a rendering difference rather than a clean error. Effects are the second weak point: because video effects come from frei0r and audio effects from LADSPA, the available effect set on your machine is a property of your installed plugins, not of Kdenlive alone. Two people running the same Kdenlive version can have different effects available.

Kdenlive is also the wrong choice if you want a single self-contained binary with no system libraries. The Flatpak manifest and the packaging directory exist because the project knows the dependency set is large enough to need packaging. If your environment cannot install KDE Frameworks 6, the source build is not a workaround, it is the same problem with more steps.

Kdenlive against a self-contained NLE such as Shotcut

Shotcut is the obvious comparison because it is built on the same editing engine. Both sit on MLT, so the underlying clip, track and filter model is shared, and both are free software. The difference is the layer above. Kdenlive puts Qt and KDE Frameworks 6 on top of MLT; Shotcut uses Qt without the KDE Frameworks layer. That single choice changes the install footprint, the look of the interface, and how much of your desktop stack the editor assumes.

For a KDE user the extra layer buys integration and costs nothing that was not already installed. For everyone else it is an extra set of libraries to satisfy, and it is the reason Kdenlive ships a Flatpak manifest and a snapcraft.yaml. The practical test is not which editor is better in the abstract, it is whether your machine already has KDE Frameworks 6. If it does, the dependency argument disappears and the decision comes down to the interface you prefer. If it does not, Shotcut's smaller stack is a real advantage, and so is any editor that ships as a single download.

Note what this comparison does not settle. MLT being shared means export behaviour is often similar between the two, so choosing on rendering alone is unlikely to be productive. The meaningful differences are in the interface, the effect management, and the packaging.

Maintenance, licence and the cost of upgrading

Kdenlive is licensed GPL-3.0, and the repository carries COPYING, a LICENSES/ directory and a REUSE.toml. The REUSE file and the LICENSES directory indicate the project tracks per-file licensing metadata, which is what you want if you need to audit what you are redistributing. This is not legal advice; if you plan to ship Kdenlive inside a product, read COPYING and the LICENSES directory yourself, and note that GPL-3.0 carries obligations that a permissive licence does not.

The README does not state a release cadence, and no recent releases were available to check. What the repository does show is the upgrade surface. Because Kdenlive depends on MLT, Qt, KDE Frameworks 6, frei0r and LADSPA, an upgrade can move any of those at once. The .gitlab-ci.yml, .kde-ci.yml and .craft.ini files in the tree are the project's own continuous integration and packaging configuration, and they are the place to look for which combinations the maintainers actually build against. The .flatpak-manifest.json is the pinned view, since a manifest has to name versions.

The contribution path is stated plainly: primary development is on KDE Invent, the GitHub repository is a mirror, and code contributions go through KDE's GitLab. The README asks contributors to get in touch before starting work, either in the issue or on the Matrix channel #kdenlive-dev:kde.org. That is a coordination cost, not a technical one, but it is worth knowing before you plan to carry a local patch.

Editorial conclusion

Adopt Kdenlive if you want a GPL-3.0 editor whose rendering core is MLT and whose interface is Qt and KDE Frameworks 6, and you are willing to get it from kdenlive.org or build it from the repository. Do not adopt it if you expect the README to carry install commands, system requirements or a rollback procedure, because it does not. Before committing, read dev-docs/build.md, check the packaging/ directory and .flatpak-manifest.json for the packaging paths the project actually maintains, and confirm which of frei0r or LADSPA effects your pipeline needs.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository