libopenshot: the C++ engine under the OpenShot editor

A C++ engine shared by the editor, the player and three language bindings

libopenshot is the engine underneath OpenShot, not the editor a person installs and double-clicks. The repository divides into `src/` for the C++ core, `bindings/` for language wrappers and `examples/` for runnable programs, and the project description states that the API currently supports C++, Python and Ruby. That narrows the audience to teams writing their own video tooling, or product maintainers who need compositing and playback inside software they already ship. Anyone after a desktop editor belongs in openshot-qt, which the project website list points to as its own source tree.

3 example programs back the binding claim: `examples/Example.cpp`, `examples/Example.py` and `examples/Example.rb`. 2 more emit a web page instead of a video file, `examples/ExampleHtml.cpp` and `examples/ExampleHtml.py`. The feature list goes one step further and says the Python and Ruby bindings support all features, yet nothing in the repository listing breaks that down per language, so a team with one specific effect in mind cannot confirm coverage from these files alone.

Multi-layer compositing and curve-based timing over borrowed codecs

The codec layer is borrowed rather than reimplemented: the feature list claims all FFmpeg formats and codecs for images, video and audio files. Everything libopenshot adds sits above that layer. Multi-layer compositing puts several tracks into one frame, effects such as chroma key, color adjustment and grayscale act on them, and a bundled Qt player can display video on any QWidget, with qt5 carried as a repository topic.

Timing is curve-driven rather than a single number per clip. Curves come in 3 types, Bézier, Linear and Constant, and the same idea is reused twice over: time mapping covers slow down, speed up and reverse, and audio mixing and resampling are described as curve-based too. Audio plug-ins arrive in 2 formats, VST and AU, while 8 audio drivers are listed by name, from ASIO and WASAPI through CoreAudio, ALSA, JACK and Android. Frame rate conversion and telecine in both directions sit in the same list. That breadth is the reason to build on the library and also the reason an upgrade has a wide surface to re-test.

Hardware acceleration the README calls experimental and unpredictable

Hardware acceleration exists for both encoding and decoding, and the README labels it experimental. It also warns that enabling it can either speed those operations up or slow them down, depending on the power and features supported by the graphics card. That caution sits oddly beside a feature bullet that advertises multi-processor support with the word performance in brackets. A team profiling a decode path that has regressed gets a pointer to `doc/HW-ACCEL.md` and no decision procedure, so the switch itself becomes the thing to verify on your own card.

The examples folder adds a hint that the graphics path is unsettled: `examples/VulkanBenchmark.cpp` exists to measure it, and neither the feature list nor the acceleration page names Vulkan anywhere. The same folder holds `examples/Example_opencv.cpp`, with OpenCV absent from the feature list too. It also carries 4 `.cube` lookup tables and 4 fisheye projection images, while no feature bullet mentions colour lookup or lens projection at all. Read all of it as work in progress rather than as capability to plan around today.

Doxygen output and one logging page are the whole documentation story

The Documentation section runs to a few lines. It points at `doc/logging.rst` for file output, verbosity and environment settings, then gives one command for building HTML with Doxygen:

make doc

Generated documentation is published at http://openshot.org/files/libopenshot/ for reading without a local build. Beyond those two references the section offers nothing further, and the repository listing shows no other documentation tree besides `doc/` and `tests/`. The feature list advertises full documentation with examples; the only path to those examples runs through `make doc`, which means reading generated output to learn what the API does.

Build instructions point at the wiki while the repository ships doc/

The install story is the weakest corner of the repository. No configure line, package name or build command appears anywhere in the README. What you get instead is three wiki pages, one each for Linux, Mac and Windows, followed by a claim that the same instructions are available in the source documentation folder. The path given there is `/docs/`, with a trailing s. The repository's own top-level listing contains `doc/`, without one, and also carries `INSTALL.md` at the root. Three locations are offered for a single set of instructions, and the three disagree on the folder name.

The destinations, exactly as the README spells them:

https://github.com/OpenShot/libopenshot/wiki/Linux-Build-Instructions
https://github.com/OpenShot/libopenshot/wiki/Mac-Build-Instructions
https://github.com/OpenShot/libopenshot/wiki/Windows-Build-Instructions

Even the developer walkthrough sits elsewhere: the step-by-step page for obtaining source code and configuring dependencies is hosted on the openshot-qt wiki, so the repository holding the engine does not carry the engine's build recipe.

Why FFmpeg on its own does not cover timeline work

One real alternative is calling FFmpeg directly, which is fair since FFmpeg is the codec layer libopenshot uses anyway. The gap sits a level up. Hand-written FFmpeg means assembling a filter graph per operation, a different graph for a wipe than for a chroma key, with timing changes handled by rewriting timestamps. libopenshot models a timeline instead: layers, effects and curves are objects, and the bindings let the same object graph be driven from Python or Ruby without writing C++ yourself. For one conversion or a thumbnail job, plain FFmpeg stays the smaller dependency and the shorter conversation. For a multi-track editor with a scrub bar, that timeline model is the argument for taking the toolchain instead. Rendering targets are not limited to disk either, since `examples/ExampleHtml.cpp` and `examples/ExampleHtml.py` emit a web page, and the bundled player draws onto any QWidget.

Submodules, CMake modules and two CI definitions in one tree

The build setup shows through in the file names. `CMakeLists.txt` sits at the root beside a `cmake/` directory, with `version.sh` handling the version string. Dependencies arrive two ways, vendored under `external/` and `thirdparty/`, and `.gitmodules` records the submodule set. For adopters that matters twice: an air-gapped build or an internal fork has to carry those trees along.

Continuous integration is configured twice over. `.github/` holds the workflows, and the two badges at the top of the README point at `ci.yml` for libopenshot and at a second `ci.yml` in the separate libopenshot-audio repository. Meanwhile `.gitlab-ci.yml` sits in the root listing next to `codecov.yml`, which records coverage reporting. Two definitions mean choosing which one gates a change, and the README does not say which. Metadata is handled the same way, giving `COPYING`, a `LICENSES/` directory and a `.reuse/` folder side by side, which is what file-level licence tracking looks like in practice. Source is LGPL-3.0-or-later, and the README says commercial licenses are available for products that use the library for video editing and playback, with [email protected] as the contact address. Copyright runs 2008-2022 to OpenShot Studios, LLC. Put those terms against your own distribution model before linking; that is a question for your counsel, not for this repository.

What this repository leaves for an adopter to answer alone

4 questions stay open after reading everything here. No install command exists, since the README points outward to the wiki and those pages are not part of the repository. No performance figure appears in the feature list or the file listing: multi-processor support and hardware acceleration are both claimed, and neither arrives with a measurement, so any speed claim is yours to produce. The claim that the non-C++ bindings carry all features goes unitemised, one effect at a time. And acceleration is documented as experimental and as a possible slowdown, which makes it something to test per machine rather than switch on. Nothing is marked archived and the last push was on 2026-09-20, which is recent work rather than a dormant project, but recent commits are not a stability guarantee for a library other programs link against.

Editorial conclusion

libopenshot fits teams that already build C++ video tooling and need a timeline engine with multi-layer compositing, curve-based timing and accelerated decode without writing filter graphs by hand. It does not fit someone who wants a finished editor, since the Qt client lives in a separate repository, or a team unwilling to carry a C++ toolchain and FFmpeg. Before adopting, read the per-OS build pages on the wiki and time your decode path against `doc/HW-ACCEL.md`, because acceleration is described as experimental and can slow operations down.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. OpenShot/libopenshot on GitHub
3. Project website
4. README
5. Releases