# GPAC and MP4Box: an LGPL multimedia framework for packaging, streaming and inspecting media

> GPAC is a C multimedia framework built around a filter engine, with MP4Box as its command line front end for MP4 and ISOBMFF work. It suits broadcast, DASH and HLS packaging pipelines, but the breadth of the filter graph is also its main cost.

**gpac/gpac** — GPAC Ultramedia OSS for Video Streaming & Next-Gen Multimedia Transcoding, Packaging & Delivery

- Repository: https://github.com/gpac/gpac
- Website: https://gpac.io
- Stars: 3,311 · Forks: 602
- Language: C
- License: LGPL-2.1
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/gpac-gpac

## What GPAC solves, and who ends up using it

GPAC is a framework for processing, inspecting, packaging, streaming, playing back and interacting with media. The content it handles is not limited to audio and video: the README lists subtitles, metadata, scalable graphics, encrypted media, 2D and 3D graphics, and ECMAScript. That scope explains the audience. The README says GPAC is popular among video enthusiasts, academic researchers, standardization bodies and professional broadcasters, which is a fair description of who needs MP4/ISOBMFF work done correctly rather than quickly.

The concrete problems it addresses are the ones that show up when media has to move between formats and delivery systems. Importing an elementary stream into an MP4 container, segmenting a file for MPEG-DASH, applying CENC encryption, converting between container formats, hinting for RTP, or inspecting the box structure of a file that will not play. MP4Box covers several of these directly. The gpac application exposes the underlying filter engine for combinations that MP4Box does not offer.

If your work is one narrow conversion, GPAC is more machinery than you need. If your work is a chain of container, packaging and encryption steps that all have to agree on the same standards, the breadth is the reason to pick it.

## The filter engine behind both gpac and MP4Box

GPAC's architecture is a filter graph. The README describes features as encapsulated in processing modules called filters, and states that the gpac application is a direct interface to the filter engine, allowing any combination of filters not enabled by other applications. MP4Box is not a separate codebase with its own logic; the README points to a wiki post on the rearchitecture and notes that the filter engine is used by most applications in GPAC, including MP4Box.

That design has a practical consequence. The command line is a way of describing a graph: sources, sinks and transformations connected in order. When a task does not map onto an MP4Box subcommand, you are not stuck, because the same engine is reachable through gpac with a different filter arrangement. When something goes wrong, the failure is usually in the graph rather than in a single function, and reading the filter list is the first diagnostic step.

The README gives the discovery command for the full feature list: run gpac -h filters, or consult the filters wiki page. Playback features have a separate wiki page. The libgpac library underneath is documented at doxygen.gpac.io, including the JS, Python and NodeJS APIs, so the same engine can be embedded rather than only driven from a shell.

## Installing GPAC and inspecting a first file

The README points to gpac.io/downloads for stable and nightly installers covering Windows, Linux, OSX, Android and iOS. Compiling from source is documented in the build section of the wiki rather than in the README, so the build steps are not reproduced here.

Once installed, the first useful action is to confirm which filters your build actually contains. The README names this command explicitly, and its output is the list of processing modules available in your binary:

```bash
gpac -h filters
```

For container inspection, MP4Box is the entry point. The README describes it as a multi-purpose MP4 file manipulation tool for the prompt, with media importing and extracting, file inspection, DASH segmentation and RTP hinting among its functions. Help is available from the binary itself as well as from the manual page:

```bash
MP4Box -h
man MP4Box
```

The README also documents the general help path for the filter engine application and its filter manual page:

```bash
man gpac
man gpac-filters
```

A note on scope: the README does not document a specific command for every listed feature. It directs readers to the wiki HowTos and the filter list for the details, and that is where a first real task should be looked up rather than guessed.

## Where GPAC is the wrong tool

The LGPL v2.1 licence is the first boundary. The README states GPAC is distributed under LGPL v2.1 or later, and that most of it is also available under a commercial license through a linked page. For a team that cannot accept LGPL obligations in the way it links or distributes software, that is a decision point before any technical evaluation, and the project's own answer is the commercial option rather than a permissive relicensing.

The second boundary is the learning curve. A filter graph is expressive, and expressiveness costs clarity. Someone who wants to remux one file has to find the right MP4Box subcommand among many, and someone who wants a pipeline has to understand how filters connect. The README's answer to both is the wiki and the help output, which means the documentation is the interface. There is no short built-in tutorial in the README itself.

The third boundary is build weight. The top-level Makefile drives src, applications and modules, and the repository carries a configure script, a flake.nix, debian packaging, a spec file and installer scripts. That is the footprint of a project meant to be packaged and distributed across platforms, not a single-file utility you vendor into a script. If you want one C file with no build system, this is not it.

## Compared with FFmpeg's approach

The natural comparison is FFmpeg, and the difference is architectural rather than a matter of which one is better. FFmpeg is organized around a command line whose options describe inputs, outputs, codecs and muxers, with libav* libraries underneath. GPAC is organized around a filter engine that the command line applications expose, with libgpac underneath.

In practice that means FFmpeg users tend to think in terms of a single invocation with many flags, while GPAC users think in terms of a graph they assemble. For transcoding-heavy work, the FFmpeg model is familiar and direct. For container and packaging work, GPAC's emphasis is visible in the README's own framing: it says GPAC is best known for its wide MP4/ISOBMFF capabilities, and MP4Box exists as a dedicated tool for that family of formats.

The overlap is real. Both handle common audio and video codecs and common containers. The divergence shows in the delivery side, where GPAC lists MPEG-DASH, Apple HLS, ATSC 3.0 ROUTE, MPEG-2 Transport Stream, RTP and RTSP among its streaming features, and in encryption, where it lists CENC, PIFF, ISMA and OMA. If your problem sits in that area, the filter engine is the reason to look here. If your problem is a straightforward transcode, the extra abstraction buys you little.

## Maintenance, releases and what upgrading costs

The repository is not archived, and the last push was on 2026-09-23. Recent release tags are v26.07.0 on 2026-07-24 and v26.02.0 on 2026-02-05, following v2.4.0 on 2024-04-17. The jump in version numbering between v2.4.0 and the v26.x tags is visible in the release list; the README states the current version as 26.08-DEV and lists the latest release as 26.08-DEV, which is the development line rather than a tagged release.

That release cadence matters for upgrade planning. Two tagged releases in 2026 plus a development line means the project ships often enough that pinning a version is a deliberate choice rather than a default. The repository includes a Changelog and a change_version.sh script, and the Makefile derives the version string from git describe against v* tags, writing it into include/gpac/revision.h. A build from a checkout therefore embeds the revision it was built from, which helps when a bug has to be matched to a specific state of the tree.

Testing is separate. The README states the test suite lives in a separate repository, github.com/gpac/testsuite, and is available as a submodule of the main repository, initialized with git submodule update --init. Per-commit build and test results are published at buildbot.gpac.io and tests.gpac.io. If you build from source, initializing that submodule is the difference between compiling the code and being able to run the project's own tests against it.

On licensing, the practical point is that LGPL v2.1 and the commercial option coexist. Whether your integration triggers the LGPL obligations depends on how you link and distribute, which is a question for your own counsel, not something the README resolves.

## Scripting, bindings and embedding libgpac

GPAC is not only a set of command line tools. The README states that tools are mostly wrappers around libgpac, which can be embedded in your projects, and the developer documentation at doxygen.gpac.io covers the JS, Python and NodeJS APIs. For a team that wants GPAC's container handling inside a larger service, that is the relevant path, not shelling out to MP4Box.

Scripting is built in as well. The README lists JS scripting through QuickJS for SVG, BIFS and VRML, and for extending GPAC framework tools. It also lists Python and NodeJS bindings. The presentation formats are a distinct area: MPEG-4 BIFS, SVG Tiny 1.2 and VRML/X3D, with 3D support for 360 videos and WebGL JS filters, and inputs from microphone, camera and desktop grabbing.

This is the part of GPAC that is easiest to underestimate from the README alone. A reader skimming the feature list may file the graphics and scripting items as legacy, but the README treats them as first-class features of the same engine that does MP4 packaging. If your interest is purely container work, that surface area is something you carry without using.

## Conclusion

Adopt GPAC if your pipeline needs MP4/ISOBMFF manipulation, DASH or HLS segmentation, or CENC encryption and you are willing to learn the filter graph rather than expect a single-purpose CLI. Do not adopt it if you need a small, narrowly scoped tool with a short manual, or if LGPL v2.1 linking does not fit how you ship your own product. Before committing, verify three things: that the filter you depend on is listed by gpac -h filters on your build, that your target platform has an installer on gpac.io/downloads or a working build path from the wiki build section, and that the commercial licensing page is relevant to your case, since the README states most of GPAC is also available under a commercial license.

## FAQ

### What is GPAC and what is MP4Box used for?

GPAC is an open source multimedia framework that processes, inspects, packages, streams, plays back and interacts with media content, distributed under LGPL v2.1 or later. MP4Box is its multi-purpose MP4 file manipulation tool for the prompt, covering media importing and extracting, file inspection, DASH segmentation and RTP hinting.

### How do I install GPAC on Windows, Linux or macOS?

The README states that stable and nightly build installers for Windows, Linux, OSX, Android and iOS are available on gpac.io/downloads. If you want to compile GPAC yourself, the README directs you to the build section of the wiki at wiki.gpac.io.

### Which filters are available in my GPAC build?

The README gives the command gpac -h filters to get the full list of available features, and points to the filters wiki page as an alternative. Playback features are listed on a separate wiki page.

### Can I use libgpac in my own project, and what about the licence?

The README says GPAC tools are mostly wrappers around libgpac, which can easily be embedded in your projects, with developer documentation at doxygen.gpac.io covering the JS, Python and NodeJS APIs. GPAC is distributed under LGPL v2.1 or later and is also available, for most of it, under a commercial license.

### How do I run the GPAC test suite?

The README states the test suite is in a separate repository, github.com/gpac/testsuite, and is available as a submodule of the main repository, initialized with git submodule update --init. Per-commit build and test results are published at buildbot.gpac.io and tests.gpac.io.

## Sources

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

---

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