# MLT Framework build and first render with melt

> MLT Framework is an LGPL-licensed C multimedia framework for video editing, with CMake builds, module integrations, and a development container. Its out-of-tree build is isolated, but hardware playback inside that container requires explicit access and configuration.

**mltframework/mlt** — MLT Multimedia Framework

- Repository: https://github.com/mltframework/mlt
- Website: https://www.mltframework.org
- Stars: 1,869 · Forks: 396
- Language: C
- License: LGPL-2.1
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/mltframework-mlt

## MLT Framework's place in video editing software

MLT solves the problem of providing video editing applications with a shared multimedia layer. The README describes it as an LGPL multimedia framework designed for video editing, and the repository identifies C as its primary implementation language. It is aimed at developers building editing tools, rendering components, command-line workflows, or applications that need to coordinate audio and video operations.

The repository topics show a broad integration surface: audio processing, FFmpeg, frei0r, LADSPA, OpenGL, Qt, SDL2, video processing, and effects. These labels indicate that MLT is intended to connect media sources, processing modules, and consumers rather than implement one narrow playback feature. The README does not define the public API, media graph schema, module-loading rules, or frame-processing contract, so those details cannot be reduced to a simple sequence without consulting `docs/` and `src/`.

The `demo/` directory provides a better entry point for understanding expected use. Files named `mlt_composite_transition`, `mlt_fade_black`, `mlt_jcut`, `mlt_lcut`, and `mlt_effect_in_middle` identify editing concepts that MLT can represent. The README does not explain the XML or configuration inside each example, but the filenames establish that the project is intended for more than media probing or playback.

## MLT's source tree and module boundaries

The repository separates implementation from examples and documentation. `src/` contains framework source, `CMakeLists.txt` and `cmake/` define the build system, `presets/` and `profiles/` hold configuration assets, and `demo/` contains applications or scripts that exercise editing behavior. `MltConfig.cmake.in` is also present, indicating integration with CMake-based consumers, while `vcpkg.json` and `vcpkg-configuration.json` record package-manager inputs. The README does not enumerate these files' contents or explain every module boundary.

The visible topics suggest that MLT is extensible across codec, audio, graphics, and effect technologies. FFmpeg is relevant to media handling, while SDL2 and Qt identify potential playback or interface technologies. OpenGL points toward rendering, and frei0r and LADSPA identify effect ecosystems. The README does not claim that every listed integration is enabled by a minimal build. Availability therefore needs confirmation in the CMake configuration and runtime plugin set.

This structure has an adoption consequence. Developers can examine both `demo/` and `src/` before writing an application, but a missing installation instruction for a particular codec remains a genuine unknown. The README links to `https://www.mltframework.org/docs/install/`, so that page is the stated place to investigate platform packages and dependency support.

## Configuring an isolated MLT build

MLT should be configured from a build directory, not from the project root. The documented flow creates `build/`, changes into it, and invokes CMake against the parent directory. This keeps generated files out of the source tree and makes the entire build disposable by deleting that directory.

Run these commands from the repository root. The README says CMake is triggered from inside the build directory, and `build/` is the location it expects.

```bash
mkdir -p build
cd build
cmake ..
```

After successful configuration, the normal build uses the generated CMake build files:

```bash
cmake --build .
```

Ninja is documented as an alternative. The CMake configuration command must still be issued from `build/`.

```bash
cmake -G Ninja ..
```

Once that configuration has succeeded, the build command can be shortened:

```bash
ninja
```

The README also documents parallel builds that reserve one CPU core. It describes this as recommended only on systems with many CPU cores, so it is not the safest default for an unfamiliar build host.

```bash
cmake --build . --parallel $(($(nproc) - 1))
```

For a Ninja build, the corresponding documented command is:

```bash
ninja -j $(($(nproc) - 1))
```

The README does not specify compiler flags, minimum hardware, platform support, or individual dependency discovery settings. It directs developers to `CMakeLists.txt` and the CMake manual page for those details.

## Running MLT tests before installation

MLT provides a way to run its tools and tests without first installing the newly built version. This avoids confusion with an existing system installation. From inside `build/`, source the repository's `setenv` script, which places the current build environment ahead of the installed one for that shell, then run the CTest suite.

Run the following from `build/`:

```bash
source ../setenv
ctest --output-on-failure
```

The `setenv` effect applies only to the current shell. The command also assumes `bash` or a Bourne-compatible shell. Since it uses a relative `../setenv` path, running it from the repository root would address the wrong file. This is a small but real operational constraint.

The README includes a commented parallel form of the test command, but it does not state that parallel testing is required. The explicit command above is the documented default. A failed test should be treated as unresolved rather than hidden by an install, because installing shared libraries and command-line tools does not remove the cause of the failure.

After installation, Linux systems may also require `sudo ldconfig` if the installation prefix is not already visible to the system linker. That step refreshes the shared library cache. It does not replace `source ../setenv` for testing an uninstalled build, because the test setup serves a narrower purpose.

## Installing MLT and running a first melt operation

After configuration, compilation, and testing, installation is initiated from the build directory. The README states that this installs generated files without modifying the source tree.

From `build/`, run:

```bash
sudo cmake --install .
```

If the linker cannot locate newly installed shared libraries and the selected installation prefix is not already configured in the Linux linker path, the README says some systems may require:

```bash
sudo ldconfig
```

The project's command-line media tool is named `melt` in the hardware-access example. The documented first invocation uses an existing `video.mp4`:

```bash
SDL_AUDIODRIVER=alsa melt video.mp4
```

This command is specifically documented as a temporary way to select the ALSA audio driver from the CLI. It is not described as a complete rendering command, encoding recipe, or proof that `melt` can open every codec. The README does not specify the expected output for this invocation or define an output file.

The summary documents the complete source-build sequence:

```bash
mkdir build
cd build
cmake ..
cmake --build .
source ../setenv
ctest --output-on-failure
sudo cmake --install .
```

The README does not supply a separate minimal `melt` project for rendering an edited sequence. Developers needing that workflow should inspect `demo/` and the usage documentation under `docs/`.

## Development container hardware access and its trade-off

The repository includes a Development Containers environment compatible with VS Code, CLion, DevPod, and other compatible IDEs. Its documented prerequisites are Docker or Podman and an IDE with Dev Container support. By default, the container runs in a restricted, secure or headless mode. Audio is sent to a `dummy` driver, and GPU access may be limited to software rendering.

Enabling physical audio and DRI requires changes to `devcontainer.json`. The README instructs developers to uncomment `--ipc=host` and `--privileged` inside `runArgs`, then recreate the container. It associates shared memory access with high-performance video frames and privileged execution with direct access to GPU nodes and sound cards.

```json
"--ipc=host",
"--privileged"
```

After recreation, the Dockerfile's default `SDL_AUDIODRIVER=dummy` must be overridden by the MLT consumer or changed permanently in `.devcontainer/Dockerfile` to `alsa` or `pulseaudio`. The documented temporary form is the `melt` command shown earlier.

This is the clearest documented limitation. Hardware playback does not follow from using the development container. It requires privileged access, reducing isolation between the container and host. The README explicitly warns against using that mode unless real-time hardware playback is needed during development. Teams with strict container security policies should evaluate that boundary before adopting the hardware-enabled setup.

## Maintenance, upgrades, and LGPL considerations

The repository is not archived. Its last push was on 2026-10-16, two days after release v7.42.0 on 2026-10-03. Earlier releases include v7.40.0 on 2026-06-25 and v7.38.0 on 2026-04-22. These dates establish recent repository activity, but the README does not define a release support window, long-term-support branch, migration policy, or compatibility matrix.

The documented build design lowers source-tree upgrade cost. Removing `build/` removes generated files, while a subsequent configuration creates a new build state. Application developers still need to review changes between framework releases and rebuild against their own integration. The README does not document an upgrade tutorial or state that moving to one MLT release is source-compatible for every consumer.

The repository license is LGPL-2.1. That designation matters when deciding how MLT will be linked, distributed, and modified, but this review does not provide legal advice. The repository also contains files named `GPL` and `GPLv3`; the README does not explain their purpose or establish which components they cover. License review should therefore start with `COPYING`, any component-specific license files in the full repository, and the notices attached to separately distributed components. The stated LGPL-2.1 license is confirmed at repository level, while component-specific licensing remains a separate verification item.

## Choosing MLT instead of a specialized media tool

MLT is the better fit when an application needs a general editing framework and can integrate media, transitions, audio processing, and effects. Its repository structure and demo names support that interpretation. It gives developers a place to assemble multimedia behavior without treating `melt` as the entire product.

A specialized command-line transcoder is a different approach. Such a tool normally accepts inputs and encoding options, then produces output through a narrower path. The MLT README does not document a complete transcoding CLI with codec selection, bitrate flags, or output naming, so `melt` should not be presented as a drop-in replacement for that category.

Likewise, a media playback library has a smaller responsibility. MLT's editing-oriented demos and framework positioning indicate a broader abstraction, but that breadth means more decisions for adopters: module availability, graph semantics, consumer integration, and release compatibility. The API is not documented in the README. Engineers can confirm the build path there, but they must consult `docs/` and the demos before validating application architecture.

## Conclusion

Application developers should evaluate MLT when they need a shared layer for video editing, audio, effects, and media integrations rather than a single-purpose playback library or encoder. Integrators should first verify codec, GPU, and audio support in the target operating environment. Projects unwilling to review LGPL compliance should exclude it before implementation begins. For source builds, the first project-specific check is a successful CMake configuration and `ctest` run from `build/`, followed by a `melt` operation using the media formats and transitions required by the application.

## FAQ

### How do I build MLT Framework from the source repository?

Create and enter a `build/` directory, run `cmake ..`, and compile with `cmake --build .`. Ninja is also supported when CMake is configured with `cmake -G Ninja ..`.

### How can I test an MLT Framework build before installing it?

From inside `build/`, run `source ../setenv` and then `ctest --output-on-failure`. The environment applies to the current shell and requires `bash` or a Bourne-compatible shell.

### Why does MLT development-container playback have no audio or limited GPU access?

The container defaults to restricted mode, where audio uses a `dummy` driver and GPU access may be limited to software rendering. Physical access requires changing `devcontainer.json`, recreating the container, and selecting a real audio driver, with reduced host isolation from `--privileged`.

## Sources

- [License: LGPL-2.1](https://github.com/mltframework/mlt/blob/master/LICENSE)
- [mltframework/mlt on GitHub](https://github.com/mltframework/mlt)
- [Project website](https://www.mltframework.org)
- [README](https://github.com/mltframework/mlt/blob/master/README.md)
- [Releases](https://github.com/mltframework/mlt/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mltframework-mlt