Shotcut: the GPLv3, Qt-based video editor that runs on MLT

What Shotcut is, and who it is actually for

Shotcut is a video editor, not a library. The repository is the application itself: a Qt 6 front end sitting on top of MLT, the multimedia authoring framework that does the actual media processing. The README lists the direct dependencies plainly: MLT, Qt 6 (6.4 minimum), FFTW, FFmpeg, Frei0r and SDL. That list tells you most of what you need to know about the architecture. FFmpeg handles formats and codecs, Frei0r supplies video plugins, SDL handles cross-platform audio playback, and MLT glues the graph together.

The target user is someone who wants a desktop non-linear editor that is free, open source and cross-platform, and who is comfortable with a traditional timeline interface. The project is licensed GPLv3, main authorship is attributed to Dan Dennedy with contributions from Brian Matherly, and the codebase is C++. If your work involves cutting clips, arranging tracks, applying filters and exporting, that is the shape of the tool.

It is not a fit for a few common expectations. There is no mobile application in this repository, no web build, and nothing in the README describing AI-assisted editing. People searching for a Shotcut APK or a Shotcut online editor are looking for something this repository does not contain.

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

The split is the interesting design decision. Qt owns the window, the menus, the timeline widgets and the QML files that describe parts of the interface. MLT owns the media graph: producers that read files, filters that transform frames, and consumers that write output. Shotcut's job is to translate what you do in the interface into changes in that graph.

That is why the dependency list is unusually long for a desktop application. Every capability you get for free, such as decoding an obscure codec or applying a particular filter, comes from a library that Shotcut links against or loads at runtime. The upside is that improvements in FFmpeg or MLT show up in the editor without Shotcut rewriting anything. The downside is that a misconfigured or outdated MLT installation breaks the application in ways that look like Shotcut bugs.

The repository layout reflects this. There are separate top-level directories for elements, filter-sets, icons, packaging, scripts, src, tests and translations, plus a MinimalMediaBackend directory. The presence of tests and a packaging directory alongside the application source is a sign that the project treats distribution as part of the codebase rather than an afterthought.

Installing Shotcut on Windows, macOS or Linux

The README is direct about installation: binaries are regularly built and available at https://www.shotcut.org/download/. For most people that is the end of the story. Download the build for your platform and run it.

Building from source is a different matter, and the README carries its own warning: building Shotcut should only be reserved for beta testers or contributors who know what they are doing. If you proceed, the fastest path the README names is Qt Creator. From the command line, the documented configure step is a cmake invocation in a separate build directory:

cmake -DCMAKE_INSTALL_PREFIX=/usr/local/ /path/to/shotcut

The README recommends adding -GNinja to that command to use the Ninja generator. After configuring, you build and install:

cmake --build .
cmake --install .

The install step is not optional. The README states that if you do not install, Shotcut may fail when you run it because it cannot locate its QML files, which it reads at run time. That is a concrete failure mode worth remembering: a successfully compiled binary can still refuse to start because the runtime assets are not where it expects them.

Before any of this works, the dependencies must be satisfied and the paths must be set so the build can find Qt, MLT, frei0r and the rest. The README does not walk through per-distribution package names, so on Linux you are largely on your own for assembling the dependency set.

Where Shotcut gets awkward: dependencies, mobile and AI editing

The honest limitation is the dependency surface. Qt 6.4 is the stated minimum, and you also need MLT, FFmpeg, FFTW, Frei0r and SDL present and discoverable. On a distribution that ships older Qt or a mismatched MLT, the build will fail or the application will misbehave, and the README offers no troubleshooting section for that. The documentation points at the credits page for a fuller list including indirect and bundled dependencies, which suggests the real dependency graph is larger than the six names given.

The second limitation is scope. Shotcut is a desktop editor. Searches for a Shotcut APK, a Shotcut app for phones, or a Shotcut online editor describe products this repository does not provide. If mobile or browser-based editing is a requirement, this is the wrong project regardless of how well the desktop version works.

The third is workflow style. Nothing in the README describes AI-assisted editing, automatic captioning, or template-driven output. If your editing process depends on those, Shotcut will feel like manual work. That is a design boundary, not a defect, but it decides adoption for some teams.

Shotcut compared with DaVinci Resolve and CapCut

The comparison people actually search for is Shotcut against DaVinci Resolve. The difference in approach is licensing and dependency philosophy. Shotcut is GPLv3 and built from open components: MLT, FFmpeg, Qt, Frei0r, FFTW, SDL. You can read the source, build it yourself, and package it for a distribution. DaVinci Resolve is proprietary; you get a binary and its feature set is defined by its vendor.

Against CapCut, the split is even clearer. CapCut is oriented toward template-driven, mobile-first, AI-assisted editing. Shotcut is a traditional timeline editor where you place clips, trim them, stack filters and export. The README does not describe any template library or AI features, so anyone arriving from CapCut should expect to do more by hand.

Neither comparison is settled by feature checklists. The practical question is whether you need source access and a permissive-enough-for-your-purposes copyleft licence, or whether you need the specific capabilities that only the proprietary tools provide.

Licence and the cost of keeping up with releases

Shotcut is GPLv3, and the repository ships the full text as COPYING. If you redistribute Shotcut or a modified version, the GPLv3 obligations apply to that distribution. If you merely use the editor to produce video, the licence does not reach your output. That distinction matters for anyone evaluating it for commercial post-production, but it is a question for your own legal review rather than something the README settles.

The maintenance picture is straightforward. The repository is not archived, and the last push was on 2026-09-21. Releases are frequent and date-versioned: v26.8.1 on 2026-08-01, v26.7.16 on 2026-07-16, and v26.9.6 marked as a beta on 2026-09-06. That cadence means upgrade cost is real but bounded: you are tracking a moving target, and beta builds should be treated as beta. If you build from source, note that the version numbering follows the release date, so a jump from one release to the next can land you on a different Qt or MLT expectation. The README does not document a rollback procedure, so pinning a known-good release before upgrading is a decision you have to make yourself.

Editorial conclusion

Adopt Shotcut if you are on Linux or Windows, want a GPLv3 editor with a real timeline, and are willing to learn a Qt-style interface. Skip it if you need AI-assisted editing, mobile editing, or a browser-based tool; the repository has no APK and no web build. Before committing, verify that your distribution packages Qt 6.4 or newer, MLT, FFmpeg, FFTW, Frei0r and SDL, and confirm the prebuilt binary for your platform from the download page actually launches and finds its QML files.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mltframework/shotcut on GitHub
3. Project website
4. README
5. Releases