YUView, a YUV player built for looking at what a codec did

A player whose feature list reads like a debugging checklist

The README opens with the claim and then immediately justifies it. YUView is described as a QT based, cross-platform YUV player with an advanced analytic toolset, and the description block says as much more.

The list is worth reading in order because it moves from basic to forensic. You get simple navigation and zooming in the video, support for a wide variety of YUV formats using various subsamplings and bit depths, and support for raw RGB files, image files and image sequences. Then it stops being a player: direct decoding of raw h.265/HEVC bitstreams with visualization of internals like prediction modes and motion vectors, and an interface with visualization for the reference software decoders HM and JEM.

The remaining entries are comparison features rather than playback features. Support for opening almost any file using FFmpeg, image comparison using side-by-side and comparison view, calculation and display of differences in either YUV or RGB colorspace, save and load playlists, and overlaying the video with statistics data.

The two reference decoder integrations are the detail that tells you who this is for. HM and JEM are the HEVC reference software implementations maintained outside the codec specification process, used to validate encoders. A tool with a visualisation interface for them is a tool for people checking whether an encoder did what it was supposed to, which is a much narrower audience than video playback and explains the 2,308 stars and 430 forks sitting on an academic lab repository.

The project comes from IENT at RWTH Aachen, based on the repository owner and the homepage, and further detail lives on a documentation site and in the repository wiki.

Three ways to install, one of them a source build

Precompiled binaries for Windows and macOS are on the releases page, and the README is explicit that all of them are compiled on GitHub Actions rather than by hand. Four artifacts are published: a Windows installer, a Windows zip, a macOS application and a Linux AppImage.

The macOS route has one extra step that trips people up, and the README calls it out. Extract the zip into your Applications folder, then strip the quarantine attribute, because a downloaded application bundle carries a quarantine flag that Gatekeeper uses:

xattr -d com.apple.quarantine /Applications/YUView.app

Linux is covered two ways. On Ubuntu 22.04 or newer it is in the official repository:

sudo apt install yuview

For other distributions it is on Flathub, published under the identifier de.rwth_aachen.ient.YUView, which follows the reverse DNS convention with the university domain first. The wiki carries a page dedicated to YUView on Linux, so the Linux story is treated as a first-class concern rather than an afterthought.

Everything else builds from source, and the README makes a point of how little that requires. The project uses qmake, so on any supported platform you install Qt, run qmake and then make. There are no further dependent libraries. If you would rather not use the terminal, QT Creator is offered as an alternative front end to the same build.

That is a short dependency list for a program that decodes HEVC and links FFmpeg, and it is worth understanding why. FFmpeg comes in as a git submodule rather than a system library, which is what .gitmodules and the submodules/ directory at the repository root indicate, and the Qt code generation is what produces a build with no hand-maintained library list.

A repository laid out as library, application and tests

The tree tells you this is a real Qt project rather than a single main.cpp. YUViewApp/ holds the application, YUViewLib/ holds the library underneath it, and YUViewUnitTest/ is a separate test target, so the analysis code is separable from the user interface in principle even if the shipped binary is one program.

The build definition is YUView.pro with a .qmake.conf alongside it, which is how qmake projects carry project-wide settings, and there is a .clang-format at the root, so the C++ is formatted by a checked-in configuration rather than by whoever last touched the file.

Packaging is thorough enough to name individually. There is a snapcraft.yaml, a deployment/ directory, a packaging/ directory, a YUView.desktop file for freedesktop menu integration, and de.rwth_aachen.ient.YUView.yaml, which is the Flathub manifest matching the application ID used on that storefront. The presence of both snapcraft and Flathub manifests means two Linux packaging routes are maintained in tree rather than one being retrofitted for a store.

Two documentation entries are worth noting. CITATION.cff is a citation metadata file, which is a scholarly repository convention and consistent with a lab origin, and HACKING.md sits at the root next to the README, so there is a written account of how to work on the code. docs/ and tools/ round out the tree.

On licensing, the repository contains a file named LICENSE.GPL3 at the root, but the project metadata does not assert a license identifier, so this article does not state one. Check that file yourself before you have an answer about what you may do with the code.

Three tagged releases, and a develop branch that has moved past them

The release history is short and the gap is the interesting part. The most recent tag is v2.14, published on 2023-09-21, with release notes that are three bullet points: many smaller bugs fixed, new FFmpeg versions supported, and VVC parsing.

The one before it, v2.13 from 2022-04-29, is where the larger refactoring happened. The FFmpeg code was refactored and FFmpeg 5.0 support arrived. The colour mapping dialogs were updated and gained the ability to save and load custom colormaps, which is exactly the kind of change an analysis tool needs and a player does not. The notes also mention a fix for large y4m files, which is a good sign about the memory behaviour of the raw reader.

The third, v2.12.1 from 2021-11-26, is a two-fix hotfix. Selection of the Y, U and V components was broken, and plotting bitrate for AV1 streams was broken. Both are defects you would only find by using the tool for its actual purpose, which is component analysis.

The repository itself was pushed to on 2026-09-21, and the default branch is develop rather than main. Taken together those facts say something specific: work is continuing on the develop branch without new tags. Anyone who wants the packaged binaries gets a build from 2023; anyone who wants the current state builds from source. VVC parsing in the newest release is the tell that this project tracks codec development rather than only playback, since Versatile Video Coding is the next generation after HEVC.

Where YUV actually comes from, and what the questions about it mean for this tool

A YUV file is raw planar video with no container and no compression, which means the only thing that varies between files is the layout: how many planes, in what order, at what bit depth, and how the chroma planes are subsampled relative to the luma plane. That is why a player for this format needs a specification-driven format picker rather than a file association, and why the README leads with support for a wide variety of YUV formats using various subsamplings and bit depths.

The best known of those layouts is YUV 420, where the two chroma planes carry half the width and half the height of the luma plane, giving four luma samples for every one chroma sample in each direction. The consequence for anyone working with these files is that chroma edges are half resolution, so a chroma artifact looks twice as wide and twice as tall as the luma artifact next to it. Tools that show components separately exist so you can see that difference directly, which is exactly what the Y, U and V component selection in YUView is for.

The RGB comparison question comes up constantly with these files, and the honest answer is that neither is better. RGB exists because displays want it, three samples per pixel with no shared information between them. YUV separates a luminance channel from two colour difference channels, which is why video codecs and broadcast standards use it and why it survives lossy compression so much better. Raw YUV is what comes out of a decoder before conversion, and that is the layer at which codec artefacts are still visible. Once a file has been converted to RGB the luma and chroma evidence is gone, which is the strongest argument for looking at YUV rather than at a converted copy of it.

This is the argument for a tool like YUView in one paragraph: conversion to RGB destroys the information you need in order to diagnose a codec, so you look at the YUV, and you need a viewer that will let you isolate components, compare against a reference decoder, and compute the difference between two frames.

Who this is for, and what to check first

YUView is for people who already know what a chroma plane is. That is not a criticism so much as a description of the audience: codec developers validating an encoder, video engineers debugging a pipeline, researchers comparing decoder output, and students who have got past playing a YUV file and want to know what is in it. If your need is to watch an MP4, none of this applies.

The project is at 2,308 stars with 430 forks and 91 open issues, written in C++, on the develop branch, last pushed to on 2026-09-21. The fork count is unusually high relative to the star count, roughly one fork for every five stars, and for a lab project with a student and research audience that is what you would expect from something people build on rather than merely read about.

The practical first step is to decide between a binary and a source build. If v2.14 from 2023 covers what you need, the Windows, macOS or AppImage build is faster and you skip the Qt setup entirely. If you need VVC parsing, recent FFmpeg, or anything developed since that tag, build from develop with qmake and make, which the README states is the whole procedure on top of having Qt installed.

For the analysis work specifically, the features to try first are the ones that change what you can conclude. Component selection to separate Y from U and V, comparison view to put two frames beside each other, difference display to quantify the gap, and the HM and JEM interfaces if you are validating against a reference decoder rather than just watching playback.

Editorial conclusion

YUView sits in a category of one, and the reason is that its feature list is a debugging feature list. Almost everything on it exists to answer a question about a specific frame: which prediction mode did the encoder choose, where did the motion vectors point, does the decoder output match the reference, which component drifted. That is why it ships as a desktop Qt application with 430 forks rather than as a command line tool or a web page, and why the feature list leads with navigation, subsampling and bit depths before it mentions codecs. Two things are worth knowing before you commit. The default branch is develop, not main, and the newest tagged release is v2.14 from 2023-09-21 while the repository was pushed to on 2026-09-21, so you are picking between a three year old binary and a source build against a moving branch. And the Windows, macOS and Linux binaries are all built by GitHub Actions rather than by the maintainers, which is a good sign for reproducibility and a reason to read a release note before you trust a build. Build it with qmake and make if the packaged version is behind, because that is the route the project expects.

Frequently asked questions

Official sources

1. IENT/YUView on GitHub
2. Issues
3. Project website
4. README
5. Releases