# Constrict: compressing videos to a target file size on Linux > Constrict is a GNOME application that re-encodes a video to hit a file size you choose, calculating the bitrate, resolution, framerate and audio quality for you, and offering H.264, HEVC, AV1 and VP9 output. It is a Flatpak, it does everything locally, and it is credited as a reimplementation of Matthew Baggett's 8mb project. **Wartybix/Constrict** — Read-only mirror of https://gitlab.gnome.org/World/Constrict - Repository: https://github.com/Wartybix/Constrict - Website: https://apps.gnome.org/Constrict - Stars: 786 · Forks: 47 - Language: Python - License: GPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/wartybix-constrict ## The problem Constrict solves Constrict compresses videos to your chosen file size, and the README is explicit about why that is useful. It is for uploading to services with specific file size limits, and it exists so that you do not have to rely on online services for video compression, or on the manual trial and error of re-encoding at various bitrates yourself. That is a narrow, real problem. A file size limit is a hard constraint that most encoding tools do not address directly, because an encoder normally works the other way round, you give it a bitrate and it produces a file. The calculation Constrict performs inverts that. It takes the target size, works out the average bitrate, and then decides the resolution, the framerate and the audio quality that fit within it, which are the three levers a transcoder actually has. The feature list spells this out. Automatic calculation of average bitrate, resolution, framerate and audio quality each video is re-encoded with to meet the target file size. Bulk compression of multiple videos to one output directory. Customisation of framerate limits, to ensure a clearer or smoother image. And a choice of codecs to encode output files with, including H.264, HEVC, AV1 and VP9. The last item is worth pausing on. AV1 and VP9 in a desktop application are not the default choice for a simple utility, and offering them puts Constrict in the same family as the serious transcoding tools rather than the small one-trick wrappers. ## The trade-off the README admits Most of the README's About section is a careful statement of limits, and it is worth reading because the tool's usefulness depends on it. The app attempts to retain as much audiovisual quality as possible for the file size given. However, extremely steep reductions in file size can cause significant loss of quality in the output file, and sometimes compression may not be possible at all. All processing is done locally, and as such, compression speeds are only as fast as your hardware allows. Three claims in three sentences, and the third one is the most important for planning. Constrict is not a cloud service, so your video never leaves the machine, and the cost of that privacy is that the encode takes as long as your processor takes. For a two hour video encoded to AV1 on a laptop, that is a long evening, and the README sets the expectation plainly rather than leaving you to discover it. The second claim is the one that decides whether the tool can help you at all. Sometimes compression may not be possible, and that follows from the arithmetic. A file size limit that is very small relative to the source's duration and resolution may not be reachable at a quality that is worth having, and the tool says so rather than producing a technically compliant but unusable file. The ability to set framerate limits is partly the answer to that, since dropping the frame rate is the fastest way to buy bitrate, at the cost of motion, which the README describes as the difference between a clearer and a smoother image. So the design is a set of prioritisation rules under a hard constraint, and understanding that it prioritises is what lets you use it sensibly. ## Where the code lives and what is a mirror The repository description says it in one line: read-only mirror of the project at gitlab.gnome.org. That matters for anyone who wants to contribute. The canonical source is the GNOME GitLab instance, and this GitHub repository is a mirror of it, so issues and pull requests here are not where the work happens. The homepage in the repository metadata is the GNOME apps page for Constrict, and the app is published through Flathub as a Flatpak. The repository layout is the standard GNOME application layout and it is a good way to see how the project is put together. There is a meson.build at the root with a meson_options.txt, a build-aux/ directory, data/ for the application data including the icons, po/ for the translations, src/ for the source, subprojects/ for the vendored dependencies, a screenshots/ directory, and a Constrict.doap file, which is the GNOME metadata document describing the release. There is also a .gitlab-ci.yml, which is the continuous integration configuration for the GitLab side, and a flatpak_local_install.sh script for running a local build as a Flatpak without going through Flathub, which is the script a contributor needs when testing a change before it is published. The repository has a .mailmap file, which is the standard mechanism for mapping the many spellings of contributors' names and addresses onto single identities in the git history. The primary language is listed as Python, and the topic tags name the stack: GTK, GTK4, libadwaita, Linux, compressor, video-compressor. ## Installing it and the Flatpak requirement Constrict is officially published as a Flatpak through Flathub, and the README asks you to ensure you are using an up-to-date version of that Flatpak when filing any new bug reports. That request is not boilerplate. A Flatpak pins the runtime and the libraries, so an old Flatpak is running an old stack against a new application, and the resulting report is about the combination rather than about Constrict. The same reasoning applies to a developer building from source, which is why the repository has a local install script. The GNOME ecosystem convention is also visible in the acknowledgements and the community sections. The project follows GNOME's Code of Conduct, and the README points a new contributor at the GNOME contribution guide for Constrict, describing it as covering how to file new issues efficiently, test pre-release versions of the app, and submit translations and code contributions. The lineage is stated as well. The project thanks Matthew Baggett for creating the original 8mb repository, which this project used as its foundation. That is a useful fact for anyone evaluating the code, because 8mb was a single-purpose command line tool and Constrict is a graphical application built on it, which tells you the hard part, the bitrate arithmetic, was inherited rather than reinvented. The recent releases are 25.12.1 from 2025-12-27, 25.12 from 2025-12-04 and 25.10 from 2025-10-29, which is the GNOME calendar versioning scheme where the numbers are the year and month of the release. ## Where Constrict is the wrong tool The first limitation is that it makes the decisions for you. The average bitrate, the resolution, the framerate and the audio quality are all computed automatically, and the only tuning the README describes is the framerate limit. If you want to spend your bitrate on resolution rather than smoothness, or pin a codec and a quality mode and let the size land where it lands, this is not the tool for it, and a full transcoder front end is. The second is the quality floor. The README says extremely steep reductions can cause significant loss of quality, and sometimes compression may not be possible at all. A service that enforces a very small limit, or a very long source video, is the case where the tool has least to offer, and the arithmetic does not improve with a better encoder. The third is the speed, which follows from doing the work locally. AV1 encoding of a long video is a heavy CPU job, and the README is candid that compression speeds are only as fast as the hardware allows. The alternative of a hosted service is faster for a single file and costs you the upload and the privacy. The fourth is the platform. This is a GNOME application, packaged as a Flatpak for Linux, so it is not available on Windows or macOS, and the interface is a GTK4 and libadwaita application, which on a non-Linux desktop means you would be running a Linux virtual machine for a file conversion. The fifth is the scope. It is a compressor and nothing else. It does not trim, does not convert containers beyond what the codecs imply, does not batch with a template of per-file settings, and does not produce anything other than video files with a target size. If you need a general media suite, this is one tool in a category rather than the category. ## Constrict compared with HandBrake and with an online compressor The comparison with HandBrake is the closest one, and the difference in approach is the direction of the constraint. HandBrake asks you to set a preset, a resolution and a quality target, and it tells you the resulting file size as an estimate. Constrict asks for the size and works out the parameters. For a fixed size limit, the second is the one that saves you the iteration loop that the README describes as manual trial and error. The cost of that inversion is control. HandBrake exposes far more of the encoder's decision surface, and for a delivery pipeline where you know exactly what you want and want to verify it frame by frame, that matters. Constrict is for the case where you know the constraint and not the parameters. The comparison with an online compression service is about the file rather than the settings. An online service is faster for a single file because the work happens on their hardware, and it is a bad idea for anything you would not want uploaded, and it may itself have a file size limit, which is the constraint you were trying to satisfy in the first place. Constrict's whole pitch is doing it on your machine, and the README is clear that this is a deliberate trade rather than an accident. The third comparison is with a command line encoder such as ffmpeg, and the difference in approach is the bitrate calculation. Using ffmpeg directly means you either work out the bitrate yourself or use two passes to hit a target size, and either way you are doing the arithmetic that Constrict exists to do for you. The command line route is more flexible and more work. ## Licence, maintenance and what to check before you compress The licence field on the repository records GPL-3.0, with a LICENSE file at the root. GPL-3.0 is the standard licence for GNOME applications, and it carries the reciprocal obligation on distribution that a copyleft licence is meant to have. The project is not archived and the last push was on 2026-10-06, so the code is being worked on, and the recent releases are 25.12.1 from 2025-12-27, 25.12 from 2025-12-04 and 25.10 from 2025-10-29. The GNOME calendar versioning means the release names tell you exactly when a build was cut, which is a convenience for a project that ships through Flathub on its own schedule. Because the canonical repository is on GNOME GitLab and this one is a read-only mirror, an issue filed here is filed in the wrong place. That is the first thing to check before reporting anything. Three things to check before you rely on it for a batch of videos. That your Flatpak is current, which the README asks for explicitly when filing a bug and which also determines whether the codec list matches what you expect, since AV1 and VP9 support in a transcoder depends on the runtime libraries available. What happens at the extremes. Compress one short sample at the size limit you actually have to hit, look at the result, and find out whether the quality is acceptable before you queue the whole shoot. The README's warning about steep reductions and about compression not being possible at all is a real boundary, and one test file tells you where it is for your material. And whether the codec choice matters to your downstream. If the service you are uploading to needs H.264 in an MP4, picking AV1 because it compresses better will produce a file that is rejected on upload, so the codec choice has to match the target, not your preferences. ## Conclusion Constrict suits someone who has to fit a video into a size limit set by a service and does not want to work out a bitrate by trial and error, and who would rather not upload the video to an online compressor. It is the wrong tool if you want the highest quality at a given size, since it picks the parameters for you and gives you limited control over the result, and the README is clear that very steep reductions can lose significant quality or fail outright. Before filing a bug, use an up-to-date Flatpak, because the README asks for that specifically, and note that all processing is local, so compression speed is bounded by your own hardware. ## FAQ ### What does Constrict do? It compresses videos to a chosen file size, which is useful for uploading to services with specific file size limits. It calculates the average bitrate, resolution, framerate and audio quality needed to reach the target, and it supports bulk compression of multiple videos to one output directory. ### Which video codecs does Constrict support? H.264, HEVC, AV1 and VP9. The README also notes that you can customise framerate limits to get a clearer or a smoother image, and that the app attempts to retain as much audiovisual quality as possible for the size given. ### How do I install Constrict? It is officially published as a Flatpak through Flathub. The README asks that you ensure you are using an up-to-date version of that Flatpak when filing any new bug reports, and the repository includes a local install script for running a build from source. ### Does Constrict upload my videos anywhere? No. All processing is done locally, and the README notes that as a consequence compression speeds are only as fast as your hardware allows. That is the trade against the online services the project was written to avoid. ### Where is the canonical source code for Constrict? This GitHub repository is a read-only mirror of the project hosted on GNOME GitLab at gitlab.gnome.org/World/Constrict, so issues and pull requests should be made there. The app is listed on apps.gnome.org as Constrict. ### What licence is Constrict released under? GPL-3.0, with the terms in the LICENSE file at the root of the repository. The project also follows GNOME's Code of Conduct and credits Matthew Baggett's 8mb project as its foundation. ## Sources - [License: GPL-3.0](https://github.com/Wartybix/Constrict/blob/main/LICENSE) - [Project website](https://apps.gnome.org/Constrict) - [README](https://github.com/Wartybix/Constrict/blob/main/README.md) - [Releases](https://github.com/Wartybix/Constrict/releases) - [Wartybix/Constrict on GitHub](https://github.com/Wartybix/Constrict) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wartybix-constrict