Edconv: a desktop front end for FFmpeg conversion jobs

What Edconv does and how it relates to FFmpeg

Edconv is a user-friendly interface that simplifies the power of FFmpeg, designed for fast and efficient conversion of video and audio files. It is written in Kotlin, and the repository layout shows a Gradle project with a composeApp module, build.gradle.kts and settings.gradle.kts, which is the Compose Multiplatform arrangement.

The important thing to understand is that Edconv is not a converter. It is a front end. FFmpeg does the work, and Edconv builds the command, runs it, shows the output and keeps track of the job.

That division shows in the requirements. FFmpeg must be installed and accessible on the system, the project also publishes GPL-licensed binaries in its releases, and the README recommends version 7.1 or higher. On first launch, Edconv prompts you to select your local FFmpeg binary, so the application is agnostic about where FFmpeg comes from.

The feature list in the README is short. Convert video and audio with FFmpeg. Queue multiple jobs and watch them process in real time. Pass custom FFmpeg arguments for full control. Still see all the logs, so you know exactly what is happening. See all the media information. And run VMAF, PSNR and SSIM analysis inside the app.

Two of those are the differentiators. The log visibility is what keeps the tool trustworthy, since a GUI that hides its output is a GUI you cannot debug when a conversion goes wrong. And the built-in quality metrics turn a comparison task that normally means finding a script into a button, with a caveat the README calls out clearly: VMAF has to be enabled in the FFmpeg binaries, so a stock build may not have it.

Installing the Flatpak, AppImage and Debian packages

The primary route is the Releases page, where each platform has its own artefact. On Windows you run the installer as administrator and follow the steps, and on macOS you run the installer and follow the steps.

The Flatpak is where the interesting constraint lives. The README warns that the Flatpak version of the application does not have access to system libraries, and that as a result FFmpeg and FFprobe binaries must be compiled with static libraries to work correctly within the sandbox environment. That is a real constraint rather than a formality, since a normal dynamically linked FFmpeg will not resolve its libraries inside the sandbox.

Installing and running it is two commands.

flatpak --user install Edconv-x.x.x-x86_64.flatpak

flatpak run io.github.edneyosf.edconv

The user install is per-account rather than system-wide, and the application id is io.github.edneyosf.edconv.

The AppImage needs execution permissions before it will run.

chmod +x Edconv-x.x.x-x86_64.AppImage

./Edconv-x.x.x-x86_64.AppImage

For Debian-based systems it is a local package install.

sudo apt install ./Edconv-x.x.x-x86_64.deb

Note the x.x.x in every filename, which is a placeholder for the version, so a literal copy of the command will not work. The build badges in the README show separate Linux, Windows and macOS workflows, so the three platforms are built in CI rather than by hand.

The job queue and the log view as the core of the tool

The two features that make Edconv a queue tool rather than a single-shot dialog are the job queue and the log stream.

Queuing matters because the alternative to a GUI here is a shell loop, and the point of the application is that a person can drop several files in, start once, and walk away. The README describes the queue as something you can watch process in real time, which is the combination that makes it usable: the jobs are visible, and the progress is visible while they run.

The log view is the honesty mechanism. The feature list says you still see all the logs, so you know exactly what is happening, and the phrase still is doing work there, because it implies that other GUIs hide this output. FFmpeg's stderr is where the actual diagnostic information lives, so a front end that swallows it is a front end that cannot be debugged. Edconv passes it through.

Custom arguments close the loop. The README lists passing custom FFmpeg arguments if you want full control, which means the application does not have to model every option in the UI. A user can reach for a flag the interface does not expose, and the log will show exactly what was run, so an unusual conversion is reproducible and debuggable rather than a black box.

Where Edconv is the wrong choice

The first limitation is that the custom argument field is a pass-through, not a settings model. A GUI with proper controls per codec and per filter is comfortable for casual use, and Edconv is not that. It is a queue, a log and an escape hatch, which means the work of deciding the flags is still yours. If your workflow needs a specific set of parameters applied consistently to hundreds of files, you are writing the flags by hand each time or scripting around the application.

The second is the VMAF dependency. The README states plainly that to use VMAF it must be enabled in the FFmpeg binaries, so on a stock FFmpeg build the headline quality metric is unavailable, and on a build that has it, the result depends on which build you happened to install. The project does publish GPL-licensed binaries in its releases, which may or may not have it enabled, and the README does not say which.

The third is the Flatpak's static binary requirement. Requiring a statically linked FFmpeg and FFprobe to run inside the sandbox is a legitimate engineering constraint, but it is also a barrier to adoption for the users most likely to try the Flatpak, because the packaged FFmpeg on a normal desktop is dynamically linked. Anyone taking the Flatpak route is committing to sourcing their own static build.

The fourth is that Edconv is still shaped by its own design opinions. The README describes it as designed for fast and efficient conversion, and there is no description of a batch configuration file, of a profile system, or of scripting. A power user with a fixed pipeline will end up using FFmpeg directly, and Edconv will serve the person with an occasional task.

The fifth is a mild inconsistency in the README itself, since the feature list repeats the line about converting video and audio using FFmpeg twice. It is a small thing, but it tells you the feature list is maintained by hand rather than generated.

Licence, maintenance and what a GPL GUI means for you

Edconv is under the GPL-3.0 licence, with the LICENSE file at the root of the repository. For a desktop application that people install rather than modify, the practical effect is on redistribution, but it is worth noting that the project also ships GPL-licensed FFmpeg binaries in its releases, so the download is GPL in two places.

The repository is not archived and the last push was on 2026-09-21, so the application is being worked on. The release history is regular, with 1.5.3 in May 2026, 1.5.2 in April 2026 and 1.5.1 earlier in the same month, so the version numbers move with the features. The default branch is main.

The build system is the standard modern Kotlin one, a Gradle wrapper with gradlew and gradlew.bat, Kotlin DSL build files, and a composeApp module that is the shape of a Compose Multiplatform project. There is a .env file at the top level, a scripts/ directory and a gradle.properties, and the CI workflows are named for the platform they build, linux-build, windows-build and macos-build.

The cost of using it is small in dependencies, because FFmpeg is a system requirement rather than a bundled library, and small in maintenance, because the application is a self-contained desktop program. The cost that is easy to miss is the API key equivalent, which here is the FFmpeg binary itself. Edconv asks you to select it on first launch and then depends on it, so a machine with several FFmpeg builds, or none, is a setup decision the user has to make before anything else works.

Editorial conclusion

Edconv suits someone who converts media regularly and finds the FFmpeg command line slow, since the job queue, the log view and the one-click quality metrics cover the work that would otherwise mean writing and rereading commands. It does not suit a user who needs a specific exotic codec configuration, because the custom argument field is a pass-through rather than a full settings model. Verify your FFmpeg version first, since the README recommends 7.1 or higher, and check whether the Flatpak route is viable for you, because it needs statically linked FFmpeg and FFprobe.

Frequently asked questions

Official sources

1. edneyosf/Edconv on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases