OpenShot Video Editor: a Python front end over libopenshot, and what that costs you

What OpenShot is, and the editing problem it actually solves

OpenShot is a desktop non-linear video editor. The README describes it as "an award-winning free and open-source video editor for Linux, Mac, and Windows, and is dedicated to delivering high quality video editing and animation solutions to the world." The repository is written in Python and carries topics including c-plus-plus, ffmpeg, gplv3, qt5, video and video-production, which tells you the shape of the thing: a Python and Qt application layered over C++ media libraries.

The problem it solves is the one that has always sat between a paid editor and a command line. You have footage in several formats, you want cuts, transitions, titles, a soundtrack and an export, and you do not want to write an FFmpeg filter graph by hand. OpenShot gives you a timeline, a preview, and a render dialog. The feature list is broad rather than deep: unlimited tracks, clip resizing and trimming, curve-based keyframe animation, transitions with real-time previews, compositing and watermarks, title templates and sub-titles, 2D animation from image sequences, 3D animated titles, SVG import, scrolling credits, frame-accurate stepping, time-mapping for slow and fast motion, audio mixing, and a set of digital video effects including brightness, gamma, hue, greyscale and chroma key.

Who it is for: hobbyists, teachers, students, and small teams who need a free editor on all three desktop platforms and are comfortable with a GUI rather than a pipeline. Who it is not for: anyone who needs a headless render farm, a stable scripting API, or frame-accurate conform work at broadcast scale. Nothing in the README claims those use cases, and the developer section points at a wiki page for building rather than at an automation interface.

The three-library split behind the Python UI

The architecture is the most important thing to understand, because it explains both the format support and the failure modes. There are three repositories, each with its own CI badge in the README: openshot-qt (the application you launch), libopenshot (the video library), and libopenshot-audio (the audio library). The Qt application does not decode or encode media itself. It builds a project model, and libopenshot, which is built on FFmpeg or Libav, does the media work.

That split has a practical consequence for versioning. The README lists the dependencies for running from source as Python 3.0+, a PyQt or PySide binding for Qt5 or Qt6, libopenshot, libopenshot-audio, FFmpeg or Libav, and GCC build tools (or MinGW on Windows). It then adds a note aimed at packagers: use OPENSHOT_QT_API=auto|pyqt6|pyside6|pyqt5 to select the Python Qt binding, and if you are building libopenshot, its Qt major version is selected separately with -DUSE_QT6=AUTO|ON|OFF. Two independent Qt choices, one in each project, is a real configuration surface. Get them out of step and you have a build that compiles and then misbehaves.

The README also notes experimental hardware encoding and decoding through VA-API, NVDEC, D3D9, D3D11 and VTB. The word experimental is the project's own. Treat hardware acceleration as something to test on your machine rather than something to assume.

Import and export are handled through FFmpeg, with EDL and XML listed for interchange. That is the standard route into and out of other editors, and it is worth knowing that the README lists those formats without describing how lossy the round trip is.

Installing OpenShot and editing your first clip

The README is explicit that the quickest route is a pre-built installer. It points at the download page and tells you to click the Daily Builds button for the latest experimental builds, which are created for each new commit to the repository. That is a genuine trade-off: the daily builds track the develop branch, and the README calls them experimental. If you want the released version, take the normal download rather than the daily build.

https://www.openshot.org/download/

If you prefer to run from source, the README gives the launch command directly. You need libopenshot already installed for this to work:

cd [openshot-qt folder]
python3 src/launch.py

The bracketed path is a placeholder in the README itself; substitute your checkout location. If you have built libopenshot from source but not installed it, the README gives a second form that points PYTHONPATH at the compiled Python bindings:

cd [libopenshot folder]
cmake -B build -S . [options]
cmake --build build

cd [openshot-qt folder]
PYTHONPATH=[libopenshot folder]/build/bindings/python \
python3 src/launch.py

The README writes [options] as a placeholder, so the CMake flags are yours to choose, with the Qt selection flag noted above. Once the window opens, the workflow is the one the feature list implies: drag media onto the timeline, trim and arrange clips, add a transition or a title template, then render. The README does not walk through the render dialog, so for the interface itself it points at the official user guide and a step-by-step video tutorial on YouTube.

Documentation can also be generated locally. The README shows this:

cd doc
make html

That runs Sphinx over the doc directory and produces HTML you can open locally, which is the version that matches the source tree you have rather than the published one.

Where OpenShot breaks down, and when it is the wrong tool

The most frequently asked question about OpenShot, judging by what people search for, is why it crashes. The repository does not contain a stability statement, and the README offers no troubleshooting section, no crash-log location and no recovery procedure. What it does offer is a bug reporting path: an official Report a Bug form on the website that walks you through producing a high-quality report, and the GitHub issue tracker as a direct alternative. That is the honest state of things. If you hit a crash, the project's answer is a bug report, not a documented workaround.

The structural reason crashes are plausible is the same three-library split described above. The Python application is not compiled, but libopenshot and libopenshot-audio are, and they link against FFmpeg. A mismatch between the openshot-qt version you launched and the libopenshot version it found is a class of problem that a single-binary editor does not have. The README's own instructions for running against an uninstalled libopenshot exist precisely because that combination is common during development.

A second limitation is the licence situation. The repository's licence field reads NOASSERTION, which means GitHub's detector could not classify it automatically. The README text, however, is unambiguous: OpenShot Video Editor is free software under the GNU General Public License, version 3 or later, and the topics list gplv3. The COPYING file sits at the top level. If you are packaging OpenShot or shipping it inside a product, the GPLv3 text is what governs, and the NOASSERTION field is a metadata quirk rather than a different licence.

When is it the wrong tool? If you need a deterministic render pipeline, this is not it. The README documents no CLI for rendering and no scripting API, only python3 src/launch.py to start the GUI. The related searches include "openshot qt cli", and nothing in the repository supports an answer beyond the launch command. If you need automated, repeatable renders across a batch of projects, an FFmpeg pipeline or an editor with a documented headless mode is the better fit. If you need multi-user collaborative editing, nothing here addresses it.

OpenShot against Kdenlive and Shotcut

The searches that bring people to this project include "OpenShot vs Kdenlive" and "Which is better, Shotcut or OpenShot". The README contains no comparison, so the useful thing to do is state the difference in approach where the README gives you enough to see it.

OpenShot's distinguishing structural choice is the split into a Python and Qt front end and separate C++ media libraries, with the front end deliberately not compiled. That is why the README can say OpenShot is programmed in Python and does not need to be compiled to run, while still requiring libopenshot and libopenshot-audio to be built or installed. Kdenlive and Shotcut, by contrast, are distributed as compiled applications with their media handling inside the same binary. The practical difference for you is the upgrade path: a compiled editor is replaced wholesale, whereas OpenShot can in principle be updated as Python source against an unchanged libopenshot, or the reverse. The cost of that flexibility is the version-matching problem described earlier.

The second difference visible in the README is the animation model. OpenShot lists curve-based keyframe animations, 3D animated titles, SVG-friendly titles and scrolling motion picture credits as first-class features. That is a deliberate tilt toward titles and motion graphics rather than toward color grading or audio post. If your work is mostly cutting interviews and matching color across cameras, that tilt does not help you.

The third is the Qt binding choice. The README allows pyqt6, pyside6 or pyqt5 through OPENSHOT_QT_API, with auto as the default. Distributions differ in which binding they ship, and this environment variable is the project's answer to that. It is a packager-facing knob, not something an end user normally touches.

Release cadence, upgrades and what the licence means for you

The repository is not archived, and the last push was on 2026-09-20. Recent releases are v4.0.0 on 2026-08-30, v3.5.1 on 2026-04-08, and v3.5.0 on 2026-03-20. That is a major version in August followed by a patch four months earlier, so the project is moving, and the gap between v3.5.1 and v4.0.0 is where you should expect behaviour changes.

The upgrade cost depends entirely on how you installed it. Installer users replace the installer and get the matching libopenshot and libopenshot-audio in the same package, which is the low-risk path. Source users carry the matching burden themselves: after a major bump you should confirm that the libopenshot you have is the one the openshot-qt version expects, because the README treats them as separate projects with separate CI and separate Qt flags. The default branch is develop, and the daily builds are built from it, so a daily build is not the same artefact as a tagged release even when the version number looks close.

On licensing: the README states the project is distributed under the GNU General Public License, version 3 or later, with no warranty. For individual use that is unremarkable. For redistribution, the GPLv3 obligations attach to the whole work you distribute, and the NOASSERTION value in the repository metadata does not change that. This is not legal advice; if you plan to bundle OpenShot, read COPYING and take your own counsel. The copyright line in the README reads 2008-2022 OpenShot Studios, LLC, which is older than the current release dates, so do not read it as a statement about recent activity.

Editorial conclusion

Adopt OpenShot if you want a free, cross-platform editor with keyframe animation, unlimited tracks and FFmpeg format coverage, and you are willing to use the pre-built installers rather than build it. Do not adopt it if you need a stable build from source on an unusual distribution or a scripting interface for automated rendering, since the README documents neither. Before committing a long project, verify which release you installed, check the download page for the build that matches your platform, and confirm that your libopenshot version matches the openshot-qt version you are running.

Frequently asked questions

Official sources

1. Issues
2. OpenShot/openshot-qt on GitHub
3. Project website
4. README
5. Releases