Avidemux is a plain video editor with a build tree that spans every platform

Small in scope, old in its bones

The project's own description is one sentence, a simple cross-platform video editor for Linux, Windows and macOS, and the whole README is consistent with that. There is no feature matrix and no catalogue of effects, and the downloads are the two things you would expect from a project like this, the latest release on the GitHub releases page and nightly builds hosted on the project's own site. The codebase is C with Qt, and the tree divides the way a long lived media application tends to divide, with `avidemux/` for the application itself, `avidemux_core/` for the core, `avidemux_plugins/` for the codec and format plugins, and `addons/` for the extras. The history of a project like this shows in its layout. There is an `attic/` directory for code that is kept but no longer built, `myOwnPlugins/` for plugins maintained outside the main tree, and `autononreg/` for the non-regression test material. The `AUTHORS` file, the Doxyfile and the `man/` directory with manual pages are the markers of a project with a real process around it, whatever its feature ambitions.

The build directory has to be on a case-sensitive filesystem

The first requirement in the build section is the one that will cost you an evening if you miss it. The build directory must be located on a case-sensitive file system. Out-of-tree builds are supported, but if you build in the tree, the source directory itself has to sit on a case-sensitive filesystem. The reason is not stated in the documentation, and it does not need to be: a project whose sources differ only in case cannot be compiled on a filesystem that folds case, and the error you get when you try is usually a confusing one about a missing file. The repository carries a `checkCaseSensitivity.sh` script in the root, which is the practical way to find out whether your filesystem qualifies before you start. The second step is the source itself, and the clone is recursive because the translations live in submodules:

git clone --recursive https://github.com/mean00/avidemux2.git && cd avidemux2

If you forget the recursive flag you get a build that fails later on a missing translation file rather than on a missing checkout, which is a small trap worth knowing about in advance.

Linux has two dependency scripts and one bootstrap

On Linux the build is split by distribution, and the split is handled by scripts that install the dependencies for you. On Debian, Ubuntu and the variants that is a single call:

bash createDebFromSourceUbuntu.bash --deps-only

On Fedora the equivalent is:

bash createRpmFromSourceFedora.bash --deps-only

Both take a `--deps-only` flag, which tells the script to stop after installing the packages and not attempt a build, so the dependency step and the build step are the same script with and without that flag. The build itself is:

bash bootStrap.bash

And if you need the older Qt, there is an explicit alternative, `bash bootStrap.bash --enable-qt5`, which tells you the Qt version is a switch rather than a branch, since the project supports both Qt 5 and Qt 6 and lets you pick. The compiled output lands in the `install` subdirectory of the build directory, which is the directory you copy to a machine that should run the editor.

Running it from the build tree without installing

The documentation explains how to run Avidemux without installing it, and the mechanism is a start script. The template is `run_avidemux_template_qt6.sh`, which means the Qt 6 flavour is the current one, and the procedure is to make a copy of it, adjust two variables, and put it on your path. `BUILDTOP` has to point at the actual build directory, and it is only correct if you built in the default location under your home directory, otherwise you edit it. `PREFIX` is adjusted if necessary. Then the script is copied to a directory listed in `$PATH` and made executable, at which point `avidemux` runs from wherever you built it. This is the arrangement that lets a developer test a change without repackaging, and it is also the reason the build directory path matters, since the script is what connects the two.

macOS is a script per architecture and per system version

The macOS instructions show the shape of this project's build maintenance, and the shape is one script per target. The dependencies come from Homebrew, in a single long list:

brew install cmake pkg-config nasm yasm qt xvid x264 x265 libvpx aom opus fdk-aac lame libass mp4v2 a52dec

That list is the project's real dependency surface, and it tells you the codec and container support the editor has: x264 and x265 for H.264 and H.265, libvpx and aom for VP8 and AV1, opus and fdk-aac for audio, lame for MP3, libass for subtitles and mp4v2 for the MP4 container. Then the build splits by machine and by macOS release, with `bootStrapMacOS_Monterey.arm64.sh` for Apple silicon and, for Intel, an explicit deployment target followed by `bootStrapOsx_Catalina.bash --enable-qt6`. The note about needing full Xcode rather than just the command line tools, because otherwise the app bundle creation fails, is the kind of detail that only appears in a document written by someone who hit it. The disk image ends up in the `installer` subdirectory, and if you built on a different Apple silicon machine there is a script to replace the ad-hoc signatures, with a `BUNDLE_CONTENT` variable to adjust when the app is installed somewhere other than the default.

The tree is a map of how many platforms this supports

The top level of the repository is the clearest evidence of the project's reach, and it is worth reading as a list rather than as a directory. There are bootstrap scripts for HaikuOS, for macOS High Sierra, Sierra, Catalina, Monterey and Sonoma in several variants including a lite one, and a set of Windows cross-compilation scripts for MinGW with Qt 5 and Qt 6, some using ninja. There is an `mxe/` directory for the MinGW cross-compilation toolchain and an `mxe_scan_deps.py` helper to work out which dependencies need cross-compiled versions, and a `cross-compiling.txt` document at the root explaining the recipe. There are AppImage targets, with separate scripts for a plain build and for minimal Bookworm and Buster variants, and a `packageDeb.sh` alongside the Debian and RPM source scripts. The dev container definitions are numerous, with one each for Debian bullseye and trixie, Fedora, Ubuntu 25.10 and 26.04, and the MinGW environment, and a matching set of `devpod_*.sh` scripts. So the answer to how many platforms this project supports is given by the file listing, and it is a lot.

Releases from 2022, commits from 2026, and a licence to read

The version history needs a caveat. The tagged releases are 2.8.1 from 2022-09-21 and 2.8.0 from 2021-12-27, so the last published package is four years old, and the last push to the repository was on 2026-10-18, which means the code is being worked on without new releases being cut. For a user who wants a binary, the practical options are the release from 2022 or a nightly build from the project's own site, and the nightlies are the more interesting of the two because they correspond to the current tree. For a developer, the master branch is where the work is, and the cross-compilation scripts and the dev containers are the tooling that makes it buildable on many systems. The licence situation is the last thing to check. The repository records a custom licence that GitHub cannot classify, and the tree holds `License.txt`, a `License.txt.in` template and a `COPYING` file, which suggests the licence text is generated from a template at build time and that it carries terms beyond a standard permissive licence. Read it before you redistribute a build.

Editorial conclusion

Avidemux suits a user who wants a small, scriptable video editor for cutting and muxing files without a large suite, and it suits a developer who wants to see how a decade old C and Qt project keeps building on a long tail of platforms, which the bootstrap scripts and the dev container definitions document unusually well. It is a poor fit if you want a modern feature set or a maintained package, since the most recent tagged release is 2.8.1 from 2022-09-21 while the last push to the repository was on 2026-10-18, and it is a poor fit if you build on a case-insensitive filesystem without reading the note about the build directory. Before you start, check three things: that your build directory is on a case-sensitive filesystem, which the documentation requires and the tree has a script to check, which Qt version you want, since the Qt5 path is a flag rather than a separate branch, and the terms in `License.txt`, since the repository records a licence that GitHub cannot classify.

Frequently asked questions

Official sources

1. Issues
2. mean00/avidemux2 on GitHub
3. README
4. Releases