MPC-QT: the Media Player Classic interface rebuilt on libmpv

The same window, a different engine underneath

Media Player Classic Home Cinema is, in the README's phrase, considered by many to be the quintessential media player for the Windows desktop. Its options dialog is a piece of shared muscle memory: dozens of tabs, every codec and filter and subtitle setting exposed, arranged in a way that people learned by muscle rather than by reading.

MPC-QT, Media Player Classic Qute Theater, reproduces most of that interface and functionality while using libmpv to play video instead of DirectShow. That single substitution is what makes the project possible on other systems. DirectShow is a Windows filter framework, and building a player on it means a Windows player. libmpv is a library interface to the mpv media player, and it is cross-platform, so the same interface can be compiled elsewhere.

The consequence for a user is that playback capability now comes from mpv rather than from the filters MPC-HC shipped with, which means the set of things libmpv can decode and render is the set of things the player can do. The interface stays, the engine changes, and that trade is the reason the project exists at all.

The audience is therefore two groups. Windows users who liked MPC-HC and want it to stay familiar while its playback core moves to mpv, and Unix users who have seen the MPC-HC interface on a colleague's machine and want that. The topics list says as much with its entries for mpv, qt, media-player-classic and cross-platform, and the project homepage is mpc-qt.github.io with a gallery of screenshots.

The code is C++ with a Qt6 interface, and the repository root has the expected shape for a desktop application: a CMakeLists.txt, a src directory, a data directory for resources, a res directory, packaging and scripts directories, a translations directory, a binaries directory, an mpv-dev directory for the bundled headers, and a DOCS directory.

What the project adds beyond a faithful copy

The README's feature section separates a clone from the improvements, and the improvements are the part worth reading.

Multiple playlists are the headline. Each playlist keeps track of the last played file for itself, so a backlog of shows can be split across separate lists without losing your place in any of them. The README frames it as eliminating the need to keep track of progress in a spreadsheet.

Quick queuing brings out-of-order playback in the same style as xmms and qmmp, which is a small feature with a real use case: a compilation album in a playlist where you want only some of the rock tracks for a while, without destroying the playlist order.

There is video preview on the seekbar, a thumbnail of the frame under the cursor. Playlist searching is multi-threaded, so finding a track in a large library does not block the interface. Screenshot templates let you take a screenshot with a custom filename containing only the fields you want. Custom metadata lets the playlist window display extra fields, the encoder used being the example given.

One feature reaches outside the local file system: the player can play online videos with yt-dlp. The in-app custom styling support is described as race inspired cosmetic enhancements, with the promise that a custom theme makes the app go faster, which is a joke about themed software rather than a performance claim.

One item is explicitly not implemented: encoding support like VirtualDub, which would mean writing an encoder-oriented backend. The README is clear that it is a wishlist item subject to the developer's time, and it is the largest functional gap between MPC-QT and the tool it imitates.

Release builds, development builds and the hidden options

Packages are published for various systems, with release builds for Windows and Linux on the release page, and the versioning scheme is time-based, so 17.07 corresponds to July 2017. The recent tags follow that pattern with v26.07 published on 2026-07-09, v26.01 on 2026-01-08 and v25.07 on 2025-07-05.

Development builds exist for Windows and Linux, and for Linux they come as an AppImage, a Flatpak and a native build. That matters because the README explicitly recommends the master branch over any release, telling everyone to increase their computer-fu by compiling from source, and the reason it gives is the ability to use the latest and pre-release software regardless of where it comes from. It also mentions that distributions may carry packages, with the Arch User Repository and FreeBSD ports named as examples.

The most revealing line about the project's philosophy is the note on the options dialog. Unimplemented features in the options dialog are hidden, and where that is not possible they are disabled, and the stated reason is to preserve the familiar options layout from MPC-HC in the meantime. So a settings window that looks like MPC-HC will have some tabs with fewer controls than expected, or with a few greyed-out ones, and the project is candid that this is a temporary state rather than a design decision.

For a user coming from MPC-HC that is a relief, because the layout is where the familiarity lives. For a new user it is a strange first impression, an options dialog with silent gaps. The documentation does not list which features are missing, so discovering that is a matter of looking through the dialog.

Building on Linux: Qt6, libmpv and two CMake routes

The prerequisites are a Qt6 SDK and a recent edition of libmpv, which the README defines precisely as either a build from git head or at least version 0.37.0. On Ubuntu the required libraries and tools are listed as build-essential, cmake, qt6-base-dev, qt6-l10n-tools, libqt6svg6-dev and libmpv-dev, with libboost-stacktrace-dev as an optional extra for stack traces in crashes.

The simple route is a plain in-tree CMake build, and the README walks through it for people who do not know git, starting from creating a source directory and cloning the repository:

git clone https://github.com/mpc-qt/mpc-qt.git
cd mpc-qt
cmake .
make -j`nproc`
sudo make install

The uninstall counterpart is sudo make uninstall, and a later git pull origin master from inside the source directory brings in new changes before rebuilding.

The route the README prefers for developers is CMake with Ninja in a subdirectory, which keeps the source tree clean and adds a translation step:

cmake -B build -G Ninja
cmake --build build -t update_translations
cmake --build build
sudo cmake --install build

The update_translations target is the part that is specific to this project, since the player is translated, and it is invoked before the real build so that the translation files match the source. The uninstall and clean steps have their own targets, sudo cmake --build build -t uninstall and cmake --build build -t clean.

The failure mode the README names is worth repeating before you start. Some distributions ship an ancient version of mpv, and the fix is to build libmpv following the instructions in the mpv-build repository. If the compiler or linker complains about libmpv symbols, the version in your package manager is the first thing to check.

Windows builds go through MSYS2, and the local libmpv switch

The project says plainly that while it is meant to be Unix, it is possible to compile it on Windows with MSYS2, and that MSVC is not supported because of the nature of the build process, though it may work in theory with enough stubbornness.

The Windows path starts from a fresh MSYS2 installation in a UCRT64 prompt, and the package list is long. The first update is pacman -Syu, followed by a restart of the shell and a second run of the same command, which is the standard MSYS2 procedure for updating its runtime before installing anything else. After that the build dependencies are installed in one copy-and-paste line:

pacman -S git base-devel wget p7zip mingw-w64-ucrt-x86_64-cmake mingw-w64-ucrt-x86_64-ninja

followed by a second group covering the toolchain, Qt 6, Qt Creator, ImageMagick, Boost, mpv, NSIS and the Vulkan loader. The presence of NSIS is what produces the Windows installer, and the Vulkan loader matters because the video output path can be backed by it.

The interesting option is the local libmpv. MPC-QT can be compiled against MSYS2's own ffmpeg-backed libmpv, or against a prebuilt library from a release page on SourceForge. Using the prebuilt one means extracting the archive and rearranging the files, placing the libraries into mpv-dev/lib and the headers into mpv-dev/include/mpv inside the repository, and then compiling with a specific option turned on:

cmake -DENABLE_LOCAL_MPV=ON .

The mpv-dev directory at the repository root is where those files go, and the option is followed by the usual make step.

Because the Windows build is a secondary path maintained alongside a Unix-first project, it is where the friction is highest, and the README's own advice to use the prebuilt library exists to avoid fighting MSYS2's ffmpeg.

Where MPC-QT is the wrong choice

The clearest case is editing. The README's wishlist includes encoding support like VirtualDub, which would let you cut clips without opening a video editor, and it says plainly that this requires writing an encoder-oriented backend. Until that exists, MPC-QT plays and manages media and does not transform it.

The second case is minimalism. MPC-QT's whole premise is reproducing a large, configurable MPC-HC interface, complete with an options dialog that mirrors the original tab for tab. A user who wants a small, quiet player with a short list of settings will find that this one is configured like a workstation. The hidden unimplemented options make that worse rather than better, because the dialog advertises a completeness it does not have.

The third case is platform expectations. The project describes itself as meant to be Unix, with Windows support arriving through MSYS2 rather than through a native toolchain, and MSVC explicitly unsupported. A Windows shop that needs a signed, supported installer will use the release build rather than build it, and the release build is where the newest features lag behind master.

The fourth is the dependency. libmpv is required, at version 0.37.0 or newer, and it is a moving target that arrives with its own ffmpeg. That is a fine dependency for a media player, but it means the player inherits the library's codec coverage and its build friction, and on distributions with old mpv packages the README's advice is to compile libmpv yourself.

There is also the question of what the alternatives are. A player built on libmpv directly would be smaller and would drop the compatibility burden, and a modern native player would not need to maintain a Windows interface from the 2000s. The trade MPC-QT makes is deliberate: familiarity for anyone who already knows MPC-HC, at the cost of carrying that interface forward.

Licence, translations and the state of the fork

The licence is GPL-2.0, with the LICENSE file in the repository root. For a media player that people install and modify, the copyleft terms mean a distributed derivative has to carry the same licence and source. This describes the published terms rather than legal advice.

The project is a reimplementation rather than a fork of MPC-HC's code, and the README says so in its opening line, calling MPC-HC the quintessential media player for the Windows desktop. What it does not describe, and what the topics list hints at with a clone entry, is the licensing situation of the original. That is a question for anyone considering a commercial product that embeds this code, and the README does not answer it.

Translations are handled through Weblate, with a translation status badge in the README, and translators can either work there or submit translations as a pull request. Code contributions are expected to follow the conventions in the code and arrive as a pull request. The build documentation is in the README and the questions and answers live in a wiki, with other pages alongside it.

On maintenance, the signals are healthy. The repository is not archived, the last push was on 2026-10-19, and the release tags show a twice-yearly cadence with v26.07 in July 2026, v26.01 in January and v25.07 in July 2025. The C and C++ CI badge and the MSYS2 CI badge in the README show that both build paths are covered by continuous integration, which for a project that supports two compilers and two platforms is the part that keeps a fork healthy over time.

Editorial conclusion

Adopt MPC-QT if you want the MPC-HC interface on a Unix desktop, or if you are moving from MPC-HC and want the same options layout and shortcuts, because that familiarity is the project's entire purpose. It is the wrong tool if you need to edit or re-encode video, since encoding support is a wishlist item that would require a new encoder-oriented backend, and it is the wrong tool if you want a minimal player rather than a configurable one. Before building from source, check that your distribution ships libmpv at version 0.37.0 or newer, since older copies in distribution repositories are the most common cause of the compiler and linker errors the README describes.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. mpc-qt/mpc-qt on GitHub
3. Project website
4. README
5. Releases